Re: [PATCH 04/13] revert: Propogate errors upwards from do_pick_commit

> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Jun 21, 2011 at 12:19:47PM -0700, Junio C Hamano wrote:
>>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>>>> +  if (res < 0)
>>>>> +          die(_("%s failed"), me);
>>>>> +  return 0;
>>>>
>>>> Should the "revert" or "cherry-pick" here be part of the message
>>>> marked for translation?  A translator might want to paraphrase to
>>>>
>>>>     fatal: failed to cherry-pick
>>>>
>>>> if that is more natural in the language at hand.
>>>
>>> Wouldn't such a message file simply say
>>>
>>>      msgid "%s failed"
>>>         msgstr "failed to %s"
>>>
>>> IOW, I am not sure what problem you are seeing.
>>
>> Ah, sorry for the lack of clarity.  What I meant is that the noun
>> and verb will be different words in many languages.  There can also be
>> problems of subject/verb agreement.  Also "me" is used elsewhere to
>> hold the command name as typed on the command line even when LANG
>> points to a language other than English if I remember correctly.
>
> Yes, "me" is the name of the command as the user types, so to whatever
> language you are translating, it can only be usable as the name of the
> command in the message.  Even if your language has a single verb to
> express the act of "running the cherry-pick command", say, "distim", you
> cannot translate the message to "failed to distim".  Your message has to
> say something like "Sorry, I got a failure while running the 'cherry-pick'
> command", and in English (which is msgid is in) "%s failed" would be good
> enough to convey that meaning.

> BUT.
>
>> If the message were in revert_or_cherry_pick instead of having two
>> identical copies in cmd_revert and cmd_cherry_pick, it would have been
>> less striking (but still a potential problem).
>
> The effort by Ævar to switch among totally different message strings
> depending on "action" was going in the direction to actually allow you to
> translate one of these messages to "failed to distim", and it was lost
> earlier in this patch (error-dirty-index). We may want to fix that in
> addition to this one.