[[Osm:Issues.show.reports/en]] cannot be translated correctly

That's a problem of the validator that does not accept "zero=" clauses if their assigned value is empty (but if this occurs for end of word, e.g. a plural mark, you may still enter "zero= " with a trailing space, and it works. Note that this is not useing the MediaWiki syntax (where "PLURAL:" has a required colon before the numeric value); here the syntax used by such messages in OSM are passnig the numeric value implictly, meaning that if there are different numbers in the same message not taking the same plural mark, it is not possible to correctly translate such message, unless the message is split into a patchwork, a bad practice; the OSM website should use a better i18n library in that case, but it would then require also change the validator rules used in TWN!).

Still there remains the bug that we cannot still assign an empty value to any case branch of the colon-less PLURAL syntax, and with that syntax you cannot add or remove cases (e.g add a "zero=", "one=", "two=", or "few=", "many=" only when needed by target languages, in addition to the final default plural case that cannot be assign an empty value): this is a local TWN bug (due to incorrect simplistic assumptions), and not the fault of OSM's message i18n support code.

Thanks, I'm aware of all that. This is the designated place to report these issues so I'm hoping tw.n staff will eventually notice it.

May be, but I wanted to precise that this is a problem that may have several causes and needing cooperation between what needs to be fixed between TWN and OSM.

You did not provide any link to a sample message and the language where this cause problem, to demonstrate it. However the solution using a space after "one=" may be a workaround in some use cases (note that this space will be part of the extension, it is safe in HTML when used at end of words that are followed by an unconditional space (and not directly by a punctuation; but if this is the case you can move that trailing punctuation inside the "one=" case, and add it also into the last default case).

Such workaround can still be useful even if the problems are fixed later, and they should continue working, while rendering the correct message in the interim. If there are other use cases where there's no clear workaround (without using a "kludge" formulation), it's even more useful to give an example link to the message.

• I think such cases needing more cases will likely occur in Breton, Irish, Slovenian, Slovak, Croatian, Bosnian, Montenegrin, Serbian, Macedonian, Ukrainian, Belarussian, Russian, Hebrew, Arabic, and so on; possibly also in agglutinating languages or languages with complex derivation rules with affixes like Finno-Ugrian languages (Hungarian, Finnish?).
• For many Asian languages that usually don't mark the plural (except by repetition of some words, or by adding some adverb-like or adjective-like word), we also need to be able to remove the "one=" case, even if we keep an empty {{PLURAL}} tag (or a dummy {{PLURAL|word}} that reduces to just that word) somewhere in the message (that will be silently discarded when rendered, or when imported in the target project, but will be there in TWN to mark that this was taken into account, and to avoid generating a warning in the Translate UI and a "!!FUZZY!!" mark in the stored message that would block its export, so that it can still be validated). And for many of these East Asian or South-east Asian languages, the workaround that uses a space cannot be used, notably in the middle of sentences, where there's no space separation between words (that's why this workaround cannot be a general solution for all cases and we need something else to be fixed, here on TWN for the validator, and on the OSM site to implement and use a better i18n function to support the expansion of PLURAL tags themselves)
• The same is true on other websites and application using Gettext, which itself does not support variable placement and expansion of plural markup stored inside translated messages (but only a reduced form with an implicit number, and otherwise needs separate messages to be translated for each contextual plural form needed). A good example of an application not based on MediaWiki is Freecol, which has developed such i18n framework to support plural tags inside messages, and a generic tag that can be used to support many other grammatical forms. Another development is going on for the Multilingual Wikipedia with Wikifunctions, which could take the Freecol as a good example of what may be done. Later, there may be a new solution adopted in CLDR to be documented and supported in various i18n frameworks, describing what a suitable i18n libary should offer. For now, each target platform proposes specific solutions for linguistic text variants and CLDR just describes the few plural forms needed for small fragments of text, but not for complete messages and not for all other linguistic variants (notably the grammatical case and grammatical gender).