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:

iD/data/core.yaml

Lines 80 to 103 in c8e89b7

	delete:
	title: Delete
	description:
	single: Delete this feature permanently.
	multiple: Delete these features permanently.
	annotation:
	point: Deleted a point.
	vertex: Deleted a node from a way.
	line: Deleted a line.
	area: Deleted an area.
	relation: Deleted a relation.
	multiple: "Deleted {n} features."
	too_large:
	single: This feature can't be deleted because not enough of it is currently visible.
	multiple: These features can't be deleted because not enough of them are currently visible.
	incomplete_relation:
	single: This feature can't be deleted because it hasn't been fully downloaded.
	multiple: These features can't be deleted because they haven't been fully downloaded.
	part_of_relation:
	single: This feature can't be deleted because it is part of a larger relation. You must remove it from the relation first.
	multiple: These features can't be deleted because they are part of larger relations. You must remove them from the relations first.
	connected_to_hidden:
	single: This feature can't be deleted because it is connected to a hidden feature.
	multiple: These features can't be deleted because some are connected to hidden features.

[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:

iD/data/core.yaml

Line 295 in d60c423

changes: "{count} Changes"

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:

iD/modules/util/locale.js

Line 36 in d60c423

var rep = translations[loc];

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:

iD/data/core.yaml

Line 570 in d60c423

many_deletions: "You're deleting {n} features: {p} nodes, {l} lines, {a} areas, {r} relations. Are you sure you want to do this? This will delete them from the map that everyone else sees on openstreetmap.org."

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

[1ec5]

#4964 implements this enhancement.