[openstreetmap/openstreetmap-website] Separate translations for "zero" and "zero like numbers" (Issue #3997)

[Philippe Verdy]

And there are otherproblems: there are languages that need more than 2 forms, and the syntax using CLDR-like labels maps them differently for different values depending on locales (that may need up to 6 forms, adding also "two=", "few=", and "many=", in addition to "zero=" which may be distinguished; all these 5 labeled forms should defautt to the last unlabelled form; but some languages have different fallbacks for these forms before using the last unlabelled form)
Not all European languages consider zero being a plural, for example French maps "zero=" to a singular, so that it fallbacks first to the "one=" label. Many East Asian and Southeast languages do not have an distringuished grammatical form (instead, translations may contextually use some other features, such as repeating a noun, but not adjectives, or adding some other word in the sentence such as some adverb.

So if you want to specialize the case "0" for expressing a negation or absence (including with a completely diferent sentence or presentation, e.g. with different colors, or some emphasizing suggesting an error or warning, it makes senses to provide a separate translation. But live then the "zero", "one", "two", "few", "many" and unlabelled default follow the normal CLDR rules according to each language.

With the Mediawiki syntax of "PLURAL:" (not "PLURAL" without the colon), we don't have such problem: we can specialize the 0 form by labelling it not with "zero=" but by "0=" with a decimal numeric value (which always takes precedence to labelled forms and to the default form, where the value matches.

As well the MediaWiki "PLURAL:" passes the value to match explictly, and so it allows different plural forms to be used ni the same message containing different values. This is not the case with the i18n library that jsut passes it explicitly and this causes problems because it can only support opluralization on parts of the message, and requires then creating "patchwork" messages; if the application does not care, and just appends mulmtiple substrings, the result may not be correct due to incorrect assumptions on the placement of plural forms within a complete sentence (for example the plural may need to be marked simultaneously on different places, or the logical order of the sentence may need to be changed. Passing the value explicitly allows placing one or more "PLURAL:" selectors in the Mediawiki syntax. As well it is possible to drop it in translations (though we can use an empty ```{{PLURAL:$1|}}``` to avoid the TWN warning that suggest that it was forgotten and marks the message as "fuzzy".

Such empty ```{{PLURAL:$1|}}``` tags present in TWN translated messages may be exported and discarded automatically in the imported message to the project's code repository for building the final app to be released and deployed (it could as well reduce ```{{PLURAL:$1|word}}``` tags to jsut the "word" when there's a single form listed). Such cleanup can be part of the import/export tools used between the OSM project and TWN. These marks are still useful in the message sources, to document what is supported and where plural forms can be used, because the app may be able to pass the effective numeric value, even if it is not used in the final translated message. As well these import/export tools implementing such automatic filters/cleanups could jsut use in TWN the Mediawiki syntax, making the conversion themselves. But adding some small i18n function in the OSM project to do that conversion would not be a huge development, even if OSM does not use the Mediawiki parser. This just requires basic regexps on messages and take into account the values passed in parameters inside a small associative array for variable names "n" used in ```{{PLURAL:$n|...}}}```. What you do with the regexp matchs is then trivial code.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/3997#issuecomment-1493296372
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/3997/1493296372 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20230402/7c47dab5/attachment-0001.htm>