Re: [L10N] Kickoff of translation for Git 2.10.0 round 1
2016-08-20 10:01 GMT-06:00 Jean-Noël AVILA : > 2. in sequencer.c, there is a mistake in the original string to translate > "Cannot revert during a another revert" There's also "In both case" in git-rebase--interactive.sh. -Alex -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [L10N] Kickoff of translation for Git 2.10.0 round 1
On mardi 23 août 2016 08:58:55 CEST Junio C Hamano wrote: > > Let's cut it like this : first ten are literally translated, the following > > ones fall back to a general rule. > > I actually once wrote "It is rare to squash dozens of commits into > one, so the first ten or dozen messages that spell the ordinals out > may be a good thing for readability", in the message you are > responding to, before realizing that the messages actually say > "1st", "2nd", etc., not "first", "second", etc., and scrapped that > part of the response. I do not really see much point in forcing the > first ten to be translated differently. In fact, taking some advance on the patch, I made the translations and used full words in the translated language. By majority of repliers, let's just use a single sentence for each case "use" or "skip". Will rerun the patch set. JN -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [L10N] Kickoff of translation for Git 2.10.0 round 1
Jean-Noël AVILA writes: >> > 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). > ... >> 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. I actually once wrote "It is rare to squash dozens of commits into one, so the first ten or dozen messages that spell the ordinals out may be a good thing for readability", in the message you are responding to, before realizing that the messages actually say "1st", "2nd", etc., not "first", "second", etc., and scrapped that part of the response. I do not really see much point in forcing the first ten to be translated differently. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [L10N] Kickoff of translation for Git 2.10.0 round 1
2016-08-21 2:38 GMT+08:00 Jean-Noël AVILA :
> On samedi 20 août 2016 11:03:00 CEST Junio C Hamano wrote:
>> Jean-Noël AVILA 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [L10N] Kickoff of translation for Git 2.10.0 round 1
On samedi 20 août 2016 11:03:00 CEST Junio C Hamano wrote:
> Jean-Noël AVILA 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [L10N] Kickoff of translation for Git 2.10.0 round 1
Jean-Noël AVILA 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.
> 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.
> 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
(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().
[Reference]
*1*
https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Plural-forms.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [L10N] Kickoff of translation for Git 2.10.0 round 1
Hi all, Before anyone tries to localize this round, I'd like to make some preliminary comments: 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. 2. in sequencer.c, there is a mistake in the original string to translate "Cannot revert during a another revert" 3. git-rebase--interactive, in this_nth_commit_message and skip_nth_commit_message are not localizable, because the logic of declination of numeral attributes is in the code and is really oriented towards English and doesn't make sense for other languages (with 28 strings to translate !). In this case, I would suggest to step back and just have a single string per function. If translators can quickly agree on these issues and maybe others I haven't seen, I can prepare a patch for review this weekend. BR Jean-Noël (french translation) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
