1236562 - Support plural forms for products (in .properties files)

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Pontoon, defect, P3)

Description

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

Few days ago a reached l10n of string remoteAllowAll (in mail/chrome/messenger/messenger.properties) and noticed the string has to be translated as a regular string instead of getting offered three (for Czech) plural forms.

IMO, it would be great to have adequate plural forms offered for translation separately, maybe even with the information about each form count, so it won't be necessary to visit http://developer.mozilla.org/en/Localization_and_Plurals for unexperienced localizers.

Comment 1

[Matjaz Horvat [:mathjazz]]

I've been thinking about this and apparently never came as far as filing a bug, so thank you. ;)

Sadly, implementation is not as simple as for the .po file format though. The plurals support in the .properties file format is non-standard and varies between projects. There are (at least) two different variants:

1. Firefox & Friends (your example). Plural forms are defined as semicolon-separated list. To display appropriate plural tabs, we also need to read (and store) plural rule used by the locale, because it's not always the same as the CLDR rule (which we already keep in the DB).

2. Firefox OS (e.g. http://hg.mozilla.org/gaia-l10n/en-US/file/bf8d33988633/apps/settings/settings.properties#l273). All locales use all plural forms as separate entities with CLDR plural form specified in square brackets.

There's also a question if this is worth implementing or should we wait for the switch to .l20n format instead (at least for #2).

Comment 2

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

You're right, I completely forgot on the case #2. But they're slightly different, if I understand how exactly does it work.

#1 All the forms are in one string separated by semicolon. Semicolon formatting is the key here - very important and the localizer has to take care of it (copy&paste&edit the translation different number of times depending on his/her locale).

#2 Each form has its own string and thus not squashed. On the other hand, they are not indicated as belonging together.

To sum up:
For #1, the string has to be split into pieces and those offered to the localizer the right number of times according to the locale.
For #2, the strings are already split into pieces, but has to be grouped in the UI. And offered to the localizer the right number of times according to the locale.
For both would be nice to have the information about locale dependent forms. Now the MDN link is shown, but only if it's in the properties file comments.

But if you already know, L20N is almost here, I would suggest to ignore #2.

Comment 3

[Matjaz Horvat [:mathjazz]]

Now that Firefox OS is dead, we're left with option #1 only. But since we'll be porting .properties files to .l20n in Firefox, this issue will be resolved then.