Locale bringup and barriers for entry

[Marcel Schneider via CLDR-Users]

On 25/09/18 10:00 Philippe Verdy wrote:
> 
> The numeric cases tagged as "one", "few", "many", "other" are defined in CLDR in plural rules for each locale.

Italian happens to use it while it isn’t defined in main/it.xml. On the other hand, main/en.xml doesn’t define it neither,
but doesn’t use it, although English could use a case for "eight" as documented in:

https://www.unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules

But it is considered an edge case:

« There is an edge case in English because of the behavior of "a/an".
For example, in changing from 3 to 8:
"a 3rd of a loaf" should result in "an 8th of a loaf", not "a 8th of a loaf"
"a 3 foot stick" should result in "an 8 foot stick", not "a 8 foot stick"
So numbers of the following forms could have a special plural category and special ordinal category: 8(X), 11(X), 18(X), 8x(X), where x is 0..9 and the optional X is 00, 000, 
00000, and so on.
On the other hand, the above constructions are relatively rare in messages constructed using numeric placeholders, so the disruption for implementations currently using CLDR 
plural categories wouldn't be worth the small gain. »

I don’t agree with the conclusion, given displaying messages like “Do you wish a 8 foot stick?” would 
reflect badly on the corporate image of the retailer using a poorly implemented user interface.

> When a message is not translated in a given language and another message is taken from a fallback,
> the plural rules defined for that fallback must then be used instead of the plural rules for the initial target locale.

Agreed, but having untranslated values in a locale is not making that locale particularly well supported in CLDR.

> Plural rules are documented. These are defined as minimal data needed to start any new locale.

That seems to be one of those barriers that Steven is now questioning, or even the main barrier for entry.
For me that would remain a barrier as long as I cannot get clear insight nor see straightforward structures to fill in.

> and note that the "other" rule is used as a fallback if a locale does not define any message for a specific plural form,
> so before looking of for fallback languages, the messages are first looking for a translation in the "other" plural rule in the target locale.

In those cases, implementations may use generic display such as “Your cart ({0})” where {0} is the number of items it contains, much like 
in a mailbox the number of new messages in a folder.

> Once a new locale is being setup, the CLDR survey will ask for translations for each plural form where needed
> (when a message to translate has a placeholder for a variable number), but note that a given message cannot
> be tagged like this if it contains several placeholders with different numeric values: if this happens, it will have
> to be splitted in several parts and the parts will be assembled in another message containing pleholders for each part
> (this would also be needed if there were multiple genders or grammatic cases to handle in the same assembled message).

Got it, thanks. That doesn’t resolve however what I meant when complaining that CLDR does not provide comprehensive 
support for inflected forms. IMO it would be more useful to note that Italian nouns ending in -o must have that -o changed 
to -i when pluralized, and those ending in -a must have the -a replaced with -e. But that only encompasses regular inflection. 
I end up thinking that there is no point for CLDR in providing inflected forms. Wouldn’t it suffice to indicate which numbers 
require plural and which category? 
For support of abbreviated ordinals, CLDR could simply list all ways of constructing an ordinal abbreviation, and relate them 
to number and to gender. It isn’t clear to me how a GPS message could make it into CLDR. I think that one should stick with
the way things are done for date and time.

Regards,

Marcel