On 10/19/23 1:52 PM, Junio C Hamano wrote:
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(_()).
... 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
