Às 17:33 de 02-06-2016, Junio C Hamano escreveu:
> Vasco Almeida <vascomalmeida@xxxxxxx> writes:
>
>> Às 17:38 de 01-06-2016, Junio C Hamano escreveu:
>>> Vasco Almeida <vascomalmeida@xxxxxxx> writes:
>>>
>>>> @@ -739,7 +748,7 @@ static void handle_bad_merge_base(void)
>>>> fprintf(stderr, _("The merge base %s is %s.\n"
>>>> "This means the first '%s' commit is "
>>>> "between %s and [%s].\n"),
>>>> - bad_hex, term_bad, term_good, bad_hex, good_hex);
>>>> + bad_hex, _(term_bad), _(term_good), bad_hex, good_hex);
>
> But this translation still does not make much sense to me.
>
> If the user did not change term_bad and term_good from the default
> ones (i.e. the four words above), the flow of control would not come
> here; one of the above two !strcmp() lines you changed would trigger.
>
Hence, marking _(term_bad) and _(term_good) in this instance is both
futile and wrong. Because, at this point of flow, these term were likely
defined by the user, therefore must not be translated.
> On the other hand, if the user did change term_bad and term_good by
> using --term-old=velho --term-new=novo earlier (which is stored in
> BISECT_TERMS and read into these two variables), these are strings
> that Git encounters at runtime; you cannot expect _(term_bad) aka
> _("novo") to be translated by *.po files for the locale.
>
> And even if it were somehow translatable, you do not want to.
>
> Imagine a case where there is a Portuguese word the user used in
> place of 'novo' in the example above, and there is an English word
> with the same spelling with a totally different meaning. And
> further imagine that English word is used elsewhere in Git and has
> translation to Portuguese in your *.po file. _(term_bad) would
> become a translation of that English word into Portuguese, which
> would be a word totally unrelated to the word the user used
> originally when she did --term-old=<that word in portuguese>.
>
I thought about this after sending my last email about this topic. It is
something that can happen indeed.
> So I do not think _(term_bad) and _(term_good) is a good idea in the
> last hunk quoted above (it is not just "not a good idea", but
> actually would be harmful), which would make term_names[] and "enum
> term" unnecessary.
>
I agree with you. I'm going to drop this patch in the next re-roll.
Leaving the previous patch, [PATCH v3 23/39] i18n: bisect: mark strings
for translation, unchanged which just masks the strings for translation
but not anything else.
> There is a case where one of the default four words could seep
> through to the last else clause. Is that what you are trying to
> address?
>
No. I was trying to replace the English terms by their translation in
those messages. But we have arrive to conclusion it is a bad idea to pursue.
> That is, when term_bad is left as "bad" but term_good is customized
> to "super", neither "term_bad is 'bad' and term_good is 'good'" nor
> "term_bad is 'new' and term_good is 'old" is true, and we would say
>
> Merge base is BAD. This means the first SUPER commit is ...
>
> With your change to mark _(term_bad) and _(term_good), the message
> would translate term_bad to whatever word it is in your language,
> and term_good that comes from the end user will be left as SUPER as
> the user typed. I am not sure if it is a good thing to translate
> only BAD while leaving SUPER as-is in such a case.
I think this may be confusing for some users. I am positive it is a bad
thing.
If I had thought more about this, I hadn't proposed this patch. I'm
sorry for wasting your time with such nonsense. I'm going to drop it in
the next re-roll.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html