Last modified: 2011-03-13 18:04:53 UTC
Hallo! Many of the messages mentioned at bug 5805: {{plural:}} support for counters in some special pages require also localization of numbers. this should be done via the new magic word {{FORMATNUM|$n}}. best regards reinhardt [[user:gangleri]]
No. Most of the code that constructs these pages formats the numbers prior to inserting them into the page output. This would introduce needless brace substitution and is slower and less efficient.
Created attachment 2029 [details] Updates to English messages file (Messages.php) At Gangleri's request: * Wrapped in {{FORMATNUM|$n}} numeric parameters in undelete_short, viewcount, imagelisttext, sitestatstext, nbytes, ncategories, nlinks, nmembers, nrevisions, nviews, watchlistcount, watchdetails, subcategorycount, categoryarticlecount. * Moved to canonical namespace names (from {{ns:x}} syntax) newarticletext, noarticletext, enotif_body, revertpage, exporttext, uploadtext * Updated uploadtext for smoother rendering on RTL wikis * Corrected capitalization in disambiguationspge for consistency with Wiktionaries * Exporttext will now work also at Wiktionaries * Prefaced lines in Monobook.js with space for better presentation
(In reply to comment #1) > No. Most of the code that constructs these pages formats the numbers prior to > inserting them into the page output. This would introduce needless brace > substitution and is slower and less efficient. Most of them already have brace substitution as they use plural. If you have better solution to make {{plural}} actually work, please go ahead. Otherwise performance is not a sensible reason to block proper i18n support.
Plural is a little different. We agree, I think, that pluralisation should be handled in the message, since the alternative is one hell of a lot of mess in the internationalisation files, and a confusing one at that. The point is that where the parameter will always be a number, then the code should be localising it before injecting it into the message; this is a little cheaper, and it's the logical thing to do. I'm not blocking proper i18n support, but I am blocking *needless* extra work.
Plural DOES NOT WORK with localized numbers. You didn't provide solution to that yet.
The penny drops.
{{PLURAL:}} should handle localized numbers now.
