Re: Is there any interest in localizing term delimiters in git messages?

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 19, 2023, 17:52 UTC
Message-ID: <xmqqcyxaxzxw.fsf@gitster.g>
In-Reply-To: <CANYiYbEqTH975j9E0GTbSbexrw3MLhKwBCw7mibfnWbxZ+-_yw@mail.gmail.com>

Jiang Xin <worldhello.net@gmail.com> writes:

Show 8 quoted lines

> 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.