Typos in diagnostics

[Roland Illig]

Hi,

I am a member of the German translation team for gawk, and I have read
through the gawk.pot file. I noticed a few small issues:

"PEBKAC error" sounds like an insult, and there is no proof that the
error is indeed with the user. Therefore the word PEBKAC should be removed.

"can not" should probably be "cannot".

The "first argument not an array" occurs in several messages. For me as
a translator this is boring work, and having very similar function names
makes the translation error-prone to copy-and-paste mistakes. Therefore
I'd prefer if the function names were %s placeholders. This would reduce
the amount of work for the translators, and at the same time, prevent
any mismatches in the function names.

Same for "POSIX does not allow operator `**'" and for "operator `^=' is
not supported in old awk". For more information, see
https://github.com/gcc-mirror/gcc/blob/2a4c59d9aa6b/contrib/check-internal-format-escaping.py#L208.
When you add another line "normalized = re.sub('^\w+:', '%s',
normalized)" to that code and run it against gawk.pot, it will show
several messages that could be merged.

"last arg of" should be "last argument of". Using whole words instead of
abbreviations was one of the large changes between GCC 9 and GCC 10, and
it improves the readability of the diagnostics. For more information,
see gcc/gcc/c-family/c-format, function check_plain.

Do you have strict guidelines when to use punctuation at the end of a
message? "shadow_funcs() called twice!" and "there were shadowed
variables." and "function name `%s' previously defined" all differ,
which makes it hard to see the common pattern.

In "%s: close failed (%s)", I would have preferred the form used by most
other projects: "%s: close failed: %s". But that's probably a matter of
personal preference.

Do you have strict guidelines when to use "can not", "cannot" and
"can't"? GCC 10 has switched to using "cannot" only.

In "fatal: arg count with `$' must be > 0", is the "count" really a
count? It seems more like a 1-based index to me.

In "info: invalid option - \"%s\"", should the nested quotes better be
`%s', like in most other places?

In "continue [COUNT] - continue program being debugged.", what is the
purpose of the period at the end of the message? What would happen if it
were omitted?

Starting with "Current frame: ", is there a good reason that the
debugger messages are capitalized?

The exclamation marks in "Can't find rule!!!\n" seem exaggerated to me.
It could as well be an untranslated string prefixed with "internal error".

In "\t------[Enter] to continue or q [Enter] to quit------", I found it
rather strange to see the key "q" translated as well. I haven't seen
this often. In Germany the shortcuts for working with the clipboard are
Ctrl+C, Ctrl+V and Ctrl+X as well, and not Ctrl+K (kopieren), Ctrl+E
(einfügen) and Ctrl+A (ausschneiden). The vi commands are also not
translated, otherwise it would be :b! instead of :q!. For consistency I
would leave the q where it is, even in translations. I'm not sure how
that would work in languages with other scripts, like Arabic or
Japanese, though.

In "fill_stat_element: could not create array", as a gawk user I'd
prefer to see the cause of this failure, which can only be "memory
exhausted". Having the extra "fill_stat_element: could not create array"
does not provide me with much information. Same for the few messages
directly below that one.

In "fts: bad first parameter", the warning message should say what data
type was expected instead of just saying "bad". Same for "ord: called
with inappropriate argument(s)".

In "fts: clear_array() failed\n", I wondered how clearing an array could
ever fail. By looking at the code, it can only fail as the result of a
programming mistake. This should rather be caught using assertions
instead of forcing the caller of that function to check whether they
made a mistake. This message should never reach the gawk user, therefore
it should not reach the i18n translator as well.

In "do_writea: argument 0 is not a string\n", is "argument 0" the same
as the "first argument" in the other messages? That would be confusing.

In "the placeholder indicates", there is no placeholder anymore. Also,
the "--help output 5 (end)" confused me since the other help sections
are not numbered.

In "Examples:\n", shouldn't the program name be a placeholder. gawk can
probably be installed as gnu-awk by specifying a --program-prefix.

All in all, I really like how much effort you did put into the language
overall and into the debugger, and the linter and the several other
parts of gawk.

Best,
Roland

array.c:825: same pattern for 'asorti: second argument not an array' and 
'asort: second argument not an array' in array.c:824
array.c:832: same pattern for 'asort: first argument not an array' and 'adump: 
first argument not an array' in array.c:782
array.c:833: same pattern for 'asorti: first argument not an array' and 'adump: 
first argument not an array' in array.c:782
array.c:838: same pattern for 'asorti: first argument cannot be SYMTAB' and 
'asort: first argument cannot be SYMTAB' in array.c:837
array.c:842: same pattern for 'asorti: first argument cannot be FUNCTAB' and 
'asort: first argument cannot be FUNCTAB' in array.c:841
array.c:849: same pattern for 'asorti: cannot use a subarray of first arg for 
second arg' and 'asort: cannot use a subarray of first arg for second arg' in 
array.c:848
array.c:855: same pattern for 'asorti: cannot use a subarray of second arg for 
first arg' and 'asort: cannot use a subarray of second arg for first arg' in 
array.c:854
awkgram.y:2499: same pattern for 'fatal: ' and 'warning: ' in awkgram.y:2481
builtin.c:493: same pattern for 'int: received non-numeric argument' and 'exp: 
received non-numeric argument' in builtin.c:163
builtin.c:583: same pattern for 'log: received non-numeric argument' and 'exp: 
received non-numeric argument' in builtin.c:163
builtin.c:1730: same pattern for 'printf: no arguments' and 'sprintf: no 
arguments' in builtin.c:1707
builtin.c:1797: same pattern for 'sqrt: received non-numeric argument' and 
'exp: received non-numeric argument' in builtin.c:163
builtin.c:2034: same pattern for 'strftime: received non-string first argument' 
and 'index: received non-string first argument' in builtin.c:378
builtin.c:2124: same pattern for 'mktime: received non-string argument' and 
'length: received non-string argument' in builtin.c:554
builtin.c:2182: same pattern for 'system: received non-string argument' and 
'length: received non-string argument' in builtin.c:554
builtin.c:2251: same pattern for 'print: attempt to write to closed write end 
of two-way pipe' and 'printf: attempt to write to closed write end of two-way 
pipe' in builtin.c:1756
builtin.c:2434: same pattern for 'tolower: received non-string argument' and 
'length: received non-string argument' in builtin.c:554
builtin.c:2465: same pattern for 'toupper: received non-string argument' and 
'length: received non-string argument' in builtin.c:554
builtin.c:2500: same pattern for 'atan2: received non-numeric second argument' 
and 'strftime: received non-numeric second argument' in builtin.c:2008
builtin.c:2519: same pattern for 'sin: received non-numeric argument' and 'exp: 
received non-numeric argument' in builtin.c:163
builtin.c:2535: same pattern for 'cos: received non-numeric argument' and 'exp: 
received non-numeric argument' in builtin.c:163
builtin.c:2649: same pattern for 'srand: received non-numeric argument' and 
'exp: received non-numeric argument' in builtin.c:163
builtin.c:3436: same pattern for 'lshift: received non-numeric first argument' 
and 'atan2: received non-numeric first argument' in builtin.c:2498
builtin.c:3438: same pattern for 'lshift: received non-numeric second argument' 
and 'strftime: received non-numeric second argument' in builtin.c:2008
builtin.c:3475: same pattern for 'rshift: received non-numeric first argument' 
and 'atan2: received non-numeric first argument' in builtin.c:2498
builtin.c:3477: same pattern for 'rshift: received non-numeric second argument' 
and 'strftime: received non-numeric second argument' in builtin.c:2008
builtin.c:3544: same pattern for 'or: called with less than two arguments' and 
'and: called with less than two arguments' in builtin.c:3513
builtin.c:3549: same pattern for 'or: argument %d is non-numeric' and 'and: 
argument %d is non-numeric' in builtin.c:3518
builtin.c:3553: same pattern for 'or: argument %d negative value %g is not 
allowed' and 'and: argument %d negative value %g is not allowed' in 
builtin.c:3522
builtin.c:3574: same pattern for 'xor: called with less than two arguments' and 
'and: called with less than two arguments' in builtin.c:3513
builtin.c:3580: same pattern for 'xor: argument %d is non-numeric' and 'and: 
argument %d is non-numeric' in builtin.c:3518
builtin.c:3584: same pattern for 'xor: argument %d negative value %g is not 
allowed' and 'and: argument %d negative value %g is not allowed' in 
builtin.c:3522
builtin.c:3606: same pattern for 'compl: received non-numeric argument' and 
'exp: received non-numeric argument' in builtin.c:163
builtin.c:4022: same pattern for 'intdiv: third argument is not an array' and 
'match: third argument is not an array' in builtin.c:2680
builtin.c:4030: same pattern for 'intdiv: received non-numeric first argument' 
and 'atan2: received non-numeric first argument' in builtin.c:2498
builtin.c:4032: same pattern for 'intdiv: received non-numeric second argument' 
and 'strftime: received non-numeric second argument' in builtin.c:2008
command.y:375: same pattern for 'trace: invalid option - "%s"' and 'info: 
invalid option - "%s"' in command.y:297
command.y:533: same pattern for 'enable: invalid option - "%s"' and 'info: 
invalid option - "%s"' in command.y:297
command.y:1016: same pattern for 'error: ' and 'warning: ' in awkgram.y:2481
extension/filefuncs.c:649: same pattern for 'fill_path_element: could not set 
element' and 'fill_stat_element: could not set element' in 
extension/filefuncs.c:634
extension/filefuncs.c:665: same pattern for 'fill_error_element: could not set 
element' and 'fill_stat_element: could not set element' in 
extension/filefuncs.c:634
extension/ordchr.c:99: same pattern for 'chr: called with inappropriate 
argument(s)' and 'ord: called with inappropriate argument(s)' in 
extension/ordchr.c:72
extension/rwarray.c:172: same pattern for 'write_array: could not flatten 
array\n' and 'fts: could not flatten array\n' in extension/filefuncs.c:863
extension/rwarray.c:292: same pattern for 'do_reada: argument 0 is not a 
string\n' and 'do_writea: argument 0 is not a string\n' in 
extension/rwarray.c:119
extension/rwarray.c:298: same pattern for 'do_reada: argument 1 is not an 
array\n' and 'do_writea: argument 1 is not an array\n' in 
extension/rwarray.c:125
extension/time.c:202: same pattern for 'sleep: not supported on this platform' 
and 'gettimeofday: not supported on this platform' in extension/time.c:141
field.c:978: same pattern for 'split: second argument is not an array' and 
'typeof: second argument is not an array' in builtin.c:4080
field.c:1061: same pattern for 'patsplit: fourth argument is not an array' and 
'split: fourth argument is not an array' in field.c:968
field.c:1066: same pattern for 'patsplit: second argument is not an array' and 
'typeof: second argument is not an array' in builtin.c:4080
field.c:1079: same pattern for 'patsplit: cannot use the same array for second 
and fourth args' and 'split: cannot use the same array for second and fourth 
args' in field.c:982
field.c:1084: same pattern for 'patsplit: cannot use a subarray of second arg 
for fourth arg' and 'split: cannot use a subarray of second arg for fourth arg' 
in field.c:987
field.c:1087: same pattern for 'patsplit: cannot use a subarray of fourth arg 
for second arg' and 'split: cannot use a subarray of fourth arg for second arg' 
in field.c:990
gawkapi.c:1318: same pattern for 'api_get_mpfr: MPFR not supported' and 
'awk_value_to_node: MPFR not supported' in gawkapi.c:183
io.c:1221: same pattern for "close: `%.*s' is not an open file, pipe or 
co-process" and "fflush: `%.*s' is not an open file, pipe or co-process" in 
builtin.c:271
io.c:3193: same pattern for 'register_output_wrapper: received NULL pointer' 
and 'register_input_parser: received NULL pointer' in io.c:3138
io.c:3249: same pattern for 'register_output_processor: received NULL pointer' 
and 'register_input_parser: received NULL pointer' in io.c:3138

summary: