Re: [L10N] Kickoff of translation for Git 2.10.0 round 1

[Jiang Xin <worldhello.net@gmail.com>]

2016-08-21 2:38 GMT+08:00 Jean-Noël AVILA <jn.avila@free.fr>:
> On samedi 20 août 2016 11:03:00 CEST Junio C Hamano wrote:
>> Jean-Noël AVILA <jn.avila@free.fr> writes:
>> > 1.  In config.c, the changes to the function die_bad_number tried to
>> > flatten the translated strings (no message building logic). I think it
>> > went too far, and the reason of the failure can be factorized so that we
>> > don't have to retranslate each time. I might be wrong on this one, but I
>> > have no example of language where we would need differentiated error
>> > reasons.
>>
>> I do not have a strong opinion on this one.  I think it is an
>> attempt to avoid language-lego.
>
> No problem with the changes for blob, files, command line. It's just about
> dividing by two the number of strings to translate by factorizing "out of
> range" and "invalid unit", which are invariable anyway.

I agree with you.  It maybe not a good solution to expanded string "reason"
in commit 1b8132d:

    -       const char *reason = errno == ERANGE ?
    -                            "out of range" :
    -                            "invalid unit";


>> > 3. git-rebase--interactive, in this_nth_commit_message and
>> > skip_nth_commit_message are not localizable,
>>
>> As the "TRANSLATORS" comment alludes to, "This is the Nth thing" can
>> be rephrased to "This is the thing N" or "This is the thing #N"
>> easily, and if that form without ordinal is acceptable for many
>> languages, we should say that it is also OK in C-locale without
>> translation.  So I agree that the recent change was pointless (even
>> though the result may be localizable).
>>
>> In an ideal world, I would imagine that this would be done by using
>> Q_("This is the first thing", "This is the thing #%d", nth) aka
>> ngettext, but
>>
>>     (1) I haven't seen ngettext used from shell scripts; and
>>
> There's a use_ngettext macro
>
>>     (2) I do not think po files are set up to express "for this
>>         message, this language has 4 variants and here are the local
>>         rules to decide which one to use depending on the number,
>>         but the rules apply only to this message".  The Plural-Forms
>>         rule [*1*] seems to be global to a .po file, unfortunately.
>>
>
>
>> so I do not think we cannot do it with ngettext().
>>
>
> Let's cut it like this : first ten are literally translated, the following ones
> fall back to a general rule. All languages are treated equally. With more than
> 10 squashed commit, you no longer really care if the numbering is pedantically
> correct.


It's boring to translate all these 30 messages, I prefer #N like:

    gettext "The commit message #\${n} will be skipped:"
    gettext "This is the commit message #\${n}:"


-- 
Jiang Xin