Jiang Xin <worldhello.net@xxxxxxxxx> writes:
> I tried to find similar patterns in `po/bg.po` using:
>
> $ git grep -h -B5 '([a-zA-Z_\.]*_[a-zA-Z_\.]\+)' po/bg.po
>
> And find other translated variable names in Bulgarian as follows:
> ...
> I suppose it would be better to keep those variable names
> unchanged.
To me, all of them refer to names given to variables, functions, and
mechanisms used internally as implementation details, and they are
meant to help developers diagnose when end-users hit these errors.
I agree with you that translating these would be counter-productive
for that purpose.
Having said that, I have to wonder if in an ideal world these should
be written in terms that are more end-user facing.
> * cookie_result in builtin/fsmonitor--daemon.c:
>
> error(_("fsmonitor: cookie_result '%d' != SEEN"),
[jch: cc'ed JeffH for area expertise]
For example, what does it mean to the end user when the
cookie->result we retrieve is different from FCIR_SEEN? We lost
sync with the fsmonitor daemon backend and to avoid yielding
incorrect data we will be giving the "trivial" response only? It is
not obvious from the code and b05880d3 (fsmonitor--daemon: use a
cookie file to sync with file system, 2022-03-25) that added it why
the end-user might even want to be shown this message [*]. I wonder
if this should be an untranslated trace2_* message that are meant
for debugging.
Side note: and isn't the significance of the event
"warning", not "error"? As far as the end-user is
concerned, after emitting this message
Also some of them might better be a BUG(), instead of die(_()).
> * crlf_action in convert.c:
>
> warning(_("illegal crlf_action %d"), (int)crlf_action);
[jch: cc'ed Torsten for area expertise].
For example, can convert.c::output_eol() be called with an illegal
crlf_action that is not covered by the switch() statement due to
data error, not a programming error? From my quick scan, it looks
like that the error should never happen no matter what end-user
mistakes (e.g., misspelt attribute and configuration variable names
in their files) are fed to convert_attrs(), and can come only from a
bug in that function (e.g., long and convoluted if/else cascade fails
to assign any value to ca->crlf_action and leaves an undefined and
"illegal" value there).
Thanks.
