897877 - Global @cldr namespace, @cldr.plural macro

Status: RESOLVED INCOMPLETE

(L20n :: General, defect)

Description

[Axel Hecht [:Pike]]

I'd propose to add another global, to expose cldr data.

Notably, I'd use that namespace to expose the upstream plural forms.

When I hacked the plural forms manually, inbetween($n, $start, $end) was a nice helper. Not sure if there's a good place to host those.

Comment 1

[Staś Małolepszy :stas]

I'm not convinced that exposing this data as a global is the right way to go.

It seems to me that it shouldn't be up to the platform nor the developer to decide to include the cldr data or not.  Instead, the localizers should have the liberty to make use of the cldr LOL files available on github or some other place.  If they want to use them, they copy and import the file in their localization.

This probably means that we should educate localizers to make sure the software they localize displays the Unicode license where appropriate.

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

We discussed this proposal and I'm also leaning against @cldr global.

The reason being that we cannot promise to ship with "all" cldr plurals and that creates unpredictability. Localizer doesn't know if the production will have plural for his locale or not, and even if he knows (we don't ship with silesian for example) he's treated differently as he has to embed his own.

My proposal is that we create a repo with cldr per language and link it in shared/locales/cldr and then localizers can just

@import (shared/locales/cldr/ab-CD.l20n)

if they want to use cldr.

Comment 3

[Staś Małolepszy :stas]

We currently don't support any form of namespacing in the identifier names.  Would we want that? (e.g. <cldr:plural …>) Or can we just go for the standard <cldr_plural …> or <cldrPlural …>?

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

I would go for cldr_plural.

Comment 5

[Staś Małolepszy :stas]

This bug is about the old L20n syntax which was replaced by the FTL syntax in Spring 2016.