Page MenuHomePhabricator

Localization of numbers should be done via {{FORMATNUM|$n}} when used with {{PLURAL}}
Closed, DeclinedPublic

Description

Author: gangleri

Description:
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]]


Version: unspecified
Severity: normal
URL: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/Language.php?r1=15054&r2=15155&sortby=date

Details

Reference
bz6492

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:22 PM
bzimport set Reference to bz6492.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

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.

broken.arrow wrote:

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

Attached:

(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.

robchur wrote:

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.

{{PLURAL:}} should handle localized numbers now.