Jonathan Nieder [off-list ref] writes:
Jun 21, 2011 at 12:19:47PM -0700, Junio C Hamano wrote:
quoted
Jonathan Nieder [off-list ref] writes:
quoted
quoted
quoted
+ 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.
Hi Junio and Jonathan,
Junio C Hamano writes:
Jonathan Nieder [off-list ref] writes:
quoted
Jun 21, 2011 at 12:19:47PM -0700, Junio C Hamano wrote:
quoted
Jonathan Nieder [off-list ref] writes:
quoted
quoted
quoted
+ 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.
Right.
BUT.
quoted
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.
But why is it required here? I already know what "me" is depending on
whether I'm in cmd_cherry_pick or cmd_revert and there are two
different translation strings anyway. I fixed the problem I
introduced in error-dirty-index earlier in this patch.
-- Ram