From: Jeff Hostetler <git@jeffhostetler.com>
Date: Thu, 19 Oct 2023 18:07:16 GMT
Subject: Re: Is there any interest in localizing term delimiters in git messages?
Message-ID: <573f1142-d1de-b379-2f8b-07396c1249ec@jeffhostetler.com>
In-Reply-To: <xmqqcyxaxzxw.fsf@gitster.g>



On 10/19/23 1:52 PM, Junio C Hamano wrote:
> Jiang Xin <worldhello.net@gmail.com> 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(_()).
...


Yeah, I think it should be an untranslated trace2 message rather
than an error.  You're right, the user cannot do anything with
that information -- and by emitting a "trivial" result, we fall
back to the normal behavior and cause the client to a regular
scan. So there is no reason to scare the user.

Jeff