Skip to content

Add printf-style support for messages #72

wants to merge 2 commits into from

3 participants

maenu commented Oct 17, 2011

I recently ran into the situation, that I wanted to export some parametrized and localized messages to JavaScript. Imagine a text box that only allows a limited amount of characters. A hint like '23 characters left' would be shown, but this should be localized. So I'd add a message 'charactersLeft' to the culture's info like this:

Globalize.addCultureInfo("en", {
    messages: {
        "characterLeft": "%0n characters left"
Globalize.addCultureInfo("de", {
    messages: {
        "characterLeft": "verbliebene Zeichen: %0n"

Note that the format is similar to the Globalize.format function, but the precision and conversion are switched to be closer to the printf style. I could then do this to obtain the localized message:

var localized = Globalize.localize("charactersLeft", [23]);
// en: "23 character left"
// de: "verbliebene Zeichen: 23"

Nice and simple, isn't it?

I added the example 'formatter' witch contains a universal String formatter that behaves similar to C's printf or java.util.Formatter. The replacing happens in a concurrent manner, which means that replacing a specifier with another one won't do any harm. The specifiers support ordinary and argument indexing, precision and conversion (like Globalize.format), but no flags. Its localization is handled by pluging in a so-called Localizer. I added one that uses Globalize to format Dates, Numbers and Strings. The demo page shows the capabilities of the formatter. I've overwritten Globalize.localize in the example to directly integrate the formatter.

I've tested the formatter with jasmine (, the localizer itself and the overwritten Globalize.localize are not tested yet.

Anybody interested in seeing this in Globalize? I'd give you the tests then (they kind of didn't fit into an example folder, so I left them away) or could do other stuff to get this thing merged.

yucca42 commented Oct 20, 2011

An interesting idea. Some quick comments:

Starting numbering from 0 is natural to a programmer, less natural to (normal) human beings. It would be more natural if %1 stood for the first parameter and not for the second.

As translated strings will normally be written by translators - people who know human languages, not usually programming that much -, I wonder how well it would work to tell them to translate "%0n characters left". They areprobably used to working with "%1 characters left", but both the numbering and a format specifier like "b" would complicate things. Perhaps not too much, but they would need to know exactly which constructs are to be kept intact.

Translating patterns like "%1 characters" is tough. Very tough. Even for English, you get a grammatically wrong expression "1 characters" when the value is 1. For, say, Russian, it gets much worse: the form of the noun depends on the number in a relatively complicated manner (41 requires singular nominative, 42 requires singular genitive, for example), and constructing the form requires algorithms of its own, with a fairly large set of rules.

Such issues can be avoided, at the cost of clumsiness of expression, by rewording the entire statement, as in your example "verbliebene Zeichen: %0n" (which probably should have verbleibende, not verbliebene). But without extra logic that handles at least the special case of 1, this would be the right move even for English!

So I think it's better to suggest that the design of texts to be generated tries to avoid the issue of generating things like "n characters" with variable n, by trying to "factorize" sentences so that numeric data appears as standalone, outside sentence context - until we can address the issue of translating such expressions properly.

jQuery Foundation member

There are a ton of issues with the implementation here, I don't see this PR ever getting merged. On the other hand, we need more discussion about the actual issue, so I created a followup ticket for that, see #100.

@jzaefferer jzaefferer closed this May 7, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.