Better i18n plural support

[jfirebaugh]

Multiselect produces translations like "Deleted {n} objects", which we're currently translating without real plural form support.

[jfirebaugh]

Doesn't seem to be critical.

[althio]

I would like to see this re-assessed, and maybe flagged "help wanted" from someone fluent in internationalization stuff.

[bhousel]

Sure @althio we can reopen and ask for help. I agree that it's not critical, but if somebody wants to work on it, I'd accept a PR for it.

In some places we support pluralization just by having multiple translation strings: https://github.com/openstreetmap/iD/blob/c8e89b7a0542a6ebf1c07f7d1cccbb01e7a52152/data/core.yaml#L80-L103

[althio]

Thanks @bhousel

In some places we support pluralization just by having multiple translation strings:

There are shortcomings with this simple approach and maybe a systematic approach would be better (but more complex). From what I read, plural rules are different depending on languages and lots of work and thoughts already on the subject. https://stackoverflow.com/questions/14326653/java-internationalization-i18n-with-proper-plurals#14327683 http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html

[bhousel]

There are shortcomings with this simple approach and maybe a systematic approach would be better (but more complex).

Thats fine, but I'd strongly prefer "simple" over "perfect".. If we need to redo all of our translations and the code to produce them to get to "perfect", lets not do that.

[1ec5]

Some of the supported languages pluralize according to more complex rules that couldn’t be accommodated by adding a few extra strings for translation. For example, some languages have a different plural form for numbers ending in 1. I think it would be a reasonable goal to support each of iD’s languages as a first-class citizen, but doing so by adding strings would unnecessarily increase the workload for all translators. For example, a Spanish translator shouldn’t have to translate redundant strings because Russian has a dual form.

The good news is that Transifex supports alternatives to the YAML format that explicitly handle pluralization. (I’m familiar with .stringsdict from iOS development, but there are others.) We could supplement the existing YAML file with another file containing a few override strings for which pluralization matters. For languages like Chinese that have no plural forms, there would only be one set of strings to translate. Back here in this repository, iD could depend on one of several libraries that support the CLDR plural format.

[1ec5]

The good news is that Transifex supports alternatives to the YAML format that explicitly handle pluralization.

Turns out Transifex supports plurals in YAML as well, as subkeys of what would normally be a single string. To enable Transifex pluralization for a particular message, we need to turn something like:

https://github.com/openstreetmap/iD/blob/d60c423ac0775f6759196ea4ef57dac6aecfff2c/data/core.yaml#L295

into:

    changes:
      one: "1 Change"
      other: "%{count} Changes"

That’ll cause Transifex to display a tabbed interface for this message. Some languages will see a different set of tabs than the one and other defined in the YAML file; it all depends on the language’s definition in CLDR.

To use the pluralized translations, we’d need a library such as the Plural module of globalize.js – there are several alternatives – to determine which rule (one, few, many, etc.) to use for count, then modify t() to look one level deeper:

https://github.com/openstreetmap/iD/blob/d60c423ac0775f6759196ea4ef57dac6aecfff2c/modules/util/locale.js#L36

Someday we’ll be able to use Intl.PluralRules, but that API is very new.

It’s unclear to me how or whether this Rails-style YAML format supports pluralizing multiple placeholders within a single message, as gettext and stringsdict can. This is the only message that currently contains multiple pluralized words:

https://github.com/openstreetmap/iD/blob/d60c423ac0775f6759196ea4ef57dac6aecfff2c/data/core.yaml#L570

I think we could break it up into multiple messages as a workaround.

[1ec5]

4964 implements this enhancement.