Re: Localization and plural rules revisited
Re: Localization and plural rules revisited
- Subject: Re: Localization and plural rules revisited
- From: RICKY SHARP <email@hidden>
- Date: Tue, 20 May 2008 04:25:28 -0700
On Tuesday, May 20, 2008, at 04:54AM, "Horst Hoesel" <email@hidden> wrote:
>
>Am 20.05.2008 um 05:02 schrieb Ricky Sharp:
>
>> There was a very short thread on NSLocalizedString regarding plural
>> rules:
>>
>> [snip]
>
>> In Russian (which has three plural rules), they kind of "cheated"
>> by still only having two strings:
>>
>> 1 song
>> songs: %d
>>
>Well, I guess they had no other choice, if the software uses just two
>forms, the localizer/translator can't add additional forms for her
>language, so he needs to cheat to get something that's not blatantly
>wrong in her language. These days most US software seems to use this
>reduced kind of a model, though some add a case for 0. "0 songs" is
>preferably a item by itself, so translators/localizers are able to
>use a textual representation of 0. For e.g. German that could be "0
>songs" = "Keine Titel" or some such. I believe that even in English
>(I'm a non-native speaker, which you probably guessed) "No songs" is
>superior to "0 songs".
I agree that "no songs" would be superior.
>>
>> Is this really the common practice? To basically force all
>> languages to just use two strings?
>>
>>
>> I thought of doing the following instead:
>>
>> Figure out plural rules for given locale. This rule theoretically
>> could be an entry in the .strings file itself that could be parsed
>> to denote a function. Such a function would return the ordinal
>> "plural rule" value given some quantity "n". The ordinal value
>> would then get appended to the base key.
>>
>> So, in languages with two rules, you'd have something like this:
>>
>> "%d song_0" = "%d song";
>> "%d song_1" = "%d songs";
>>
>> In languages with 5 plural rules, you'd then have 5 keys ("%d
>> song_0" .. "%d song_4").
>>
>> Has anyone else tackled this problem?
>>
>I think this concept is valid, but believe it would be easier to have
>these keys statically for all languages. It is easier and probably
>less expensive to have translators/localizers translate those 5
>entries into each language than make sure they get proper
>instructions how to add keys to the localizable.strings file. (If you
>consider how AppleGlot works, they'll have to add back their special
>keys with every loc cycle as AppleGlot blows away additional keys
>from localized strings files) So I'd just add these 5 lines statically:
>
>"0 songs" = "No songs";
>"1 song" = "1 song";
>"2 songs" = "2 songs";
>"3 songs" = "3 songs";
>"%d songs" = "%d songs"; // 4 or more
This technical works only for certain languages. Plural rules for Polish, Russian and Arabic get really complex. For example, I've seen the following expression to figure out the rule for Russian (0, 1 or 2):
n % 10 == 1 && n % 100 != 11 ? 0 : n % 10 >= 2 && n % 10 <=4 &&
(n % 100 < 10 || n % 100 >= 20) ? 1 : 2
Each key can thus represent a set of specific values (and such values may not represent a continuous range). I could statically put in n keys (where n is the maximum number of plural rules I need). But the problem becomes that each individual rule drastically changes from language to language. Although, there would probably be a separate translator for each language, and instructions could be provided as to what rule each key represents for that specific language.
>
>This will not be enough in cases where you have something like:
>
>"iSounds could not transfer all items to your iGadget. %@ could not
>be transfered."
>
>If you replace %@ by one of the items (except the first ;) in the
>list above you will give localizers a hard time, because some
>languages reflect singular/plural in verbs and adjectives. So you
>will have to create a list for that, too.
Thank you Horst, this is all very good info.
--
Rick Sharp
Instant Interactive(tm)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden