Coding

Localization Sin #1


Never, ever, ever assume you can pluralize something by adding an “s” to the end of it.

Not only does this not remain true in every language, but you will grow lax and start doing silly things like:

    var text = "You have " + swordQuantity + " sword" +
        (1 === swordQuantity ? "" : "s") + ".";

And when you do that once, you’re likely to do it all over the place. Then, instead of simple text replacement during localization, you have to rewrite whole swaths of code to handle how different languages pluralize.

Just a friendly tip.

Coding
Gulp.js – an AMAZING build system!
Coding
Rage-quit support for fish shell
Coding
Code faster with simple Sublime Text improvements
  • Geoff

    GeoffGeoff

    Author

    The point about pluralization is good, but you’re still assuming a lot about the grammar and putting the raw text into your code, both of which will make localization difficult.

    Wouldn’t it be better to have a language stringtable file, and refer to the language-independent string name in code, to be replaced (with appropriate substitution) the localized text?

    The string would be looked up in the table, and any substitutions would then be done at runtime, according to substitution flags or markers in the imported string.

    Preferably the strings would be as close to complete statements as possible, so that relevant grammar doesn’t need to be assumed by code… Though even that is problematic since there are so many different ways languages can handle different numbers of objects (single, two, many) and gender (neuter, male, female) that can make it necessary to have multiple versions of each statement, depending what languages you want to easily support.

    Anyway, assuming reasonably limited grammar support, a separate file localization involves replacing a single non-code file, instead of editing all your UI code. Maybe that distinction is less useful in PHP land, but in C++ it’s quite important.


  • Dan Hulton

    Dan HultonDan Hulton

    Author

    Yup, I agree with everything you said there, except the part where you assumed what I was assuming. In a perfect world, I’d do pretty much as you suggested (I particularly love the way the Komodo framework handles localiation). The code in my article was an example of exactly what NOT to do.