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

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

> 
> > 2.  in sequencer.c, there is a mistake in the original string to translate
> > "Cannot revert during a another revert"
> 
> This should be corrected. Thanks for spotting.

I also spotted a missing capitals. Will propose a patch.

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

> [Reference]
> 
> *1*
> https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Plural-> forms.html