Re: [PATCH v3 24/39] i18n: bisect: enable l10n of bisect terms in messages

From: Vasco Almeida <vascomalmeida@sapo.pt>
Date: Jun 3, 2016, 12:32 UTC
Message-ID: <575178D4.5@sapo.pt>
In-Reply-To: <xmqqbn3jv6ka.fsf@gitster.mtv.corp.google.com>

Às 17:33 de 02-06-2016, Junio C Hamano escreveu:

Show 18 quoted lines

> Vasco Almeida <vascomalmeida@sapo.pt> writes:
> 
>> Às 17:38 de 01-06-2016, Junio C Hamano escreveu:
>>> Vasco Almeida <vascomalmeida@sapo.pt> 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.

Show 17 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 11 quoted lines

> 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.