Localization string tables

[ErikMcClure]

In order to localize Pony Clicker, the javascript must be decoupled from the HTML (need to merge #26 ) and then it must get it's strings from a string table that can be swapped out. Then a translated HTML page can be provided that loads the javascript with an argument specifying the language. For example, the russian version of Pony Clicker would be accessed at ponyclicker_ru.html and load the "ru" language.

This requires a significant refactoring of code, so it's low priority until after v1.0 release

[SeinopSys]

The best way to do this would be to store language preferences in the user's settings, and dynamically add the language file JS to the DOM. Maintaining 10+ different HTML files would be a nightmare. If only you had a host which supports PHP, this would be a lot easier.

[cburschka]

You can decouple strings from the HTML file just as easily as from the JS, so there's no need to maintain multiple HTML files.

Just have one big object storing all strings, making sure to give them meaningful IDs. Each language defines its own strings object (maybe under languages['en'], languages['de'], languages['ru'], etc.).

Any time a string would be printed in JS, replace it with a call to something like localize(<stringID>), which prints out the correct string.

Any string in HTML is replaced by a <span class="string" data-string="..."></span> tag. (Why a data attribute and not a class or ID? Because they're easy to access from JS, and don't have strict formatting or uniqueness constraints.) For example, Enables animated canvas effects in the background. could be replaced with <span class="string" data-string="options.canvas.label" />

On page load, we simply need to fill all those <span>s with their appropriate values - the best part is that this can be immediately reapplied if the user selects a different language, without reloading or switching pages or anything.

$('span.string').each(function() {
  $(this).html(localize($this).attr('data-string')));
});

Variables in strings are a bit of an issue - each locale object should probably define its own pretty-num function at least, so decimal points and number names can be altered at well...

[ErikMcClure]

Given the amount of string construction going on, it would be far easier to implement a printf()-ish solution, possibly using C#'s notation: "{0} ponies bought for {1} ({2} SPS)". The string tables would then use this and the javascript functions would load up the appropriate string table using printf(lang[cur]['game.SPS'], arg1, arg2) etc.

[cburschka]

Yes, that'd definitely be needed. JS doesn't have a native printf, but it's pretty easy to implement with a regex+function string replace along the lines of:

function printf(string, variables) {
  // allow printf(string, arg1, ..., argN) syntax
  if (typeof variables !== 'object') {
    variables = arguments.slice(1);
  }
  string.replace(/{(\w)}/g, function(match, name) {
    return variables[name];
  });
}

(which also supports named variables, eg. printf("{numponies} bought for {cost} ({sps} SPS)", {numponies: 10, ...}))

With a bit more code, you can add in very primitive format specifiers, for example:

string.replace(/{(?:(\w):)?(\w)}/g, function(match, format, name) {
  return format ? formatters[format](variables[name]) : variables[name];
});

Which would allow automatically running the variable through a specific formatter, such as pretty-num (which could then turn "2000000" into "2,000,000"/"2 millions" in English, or "2.000.000"/"2 Millionen" in German, etc.)

Then you could have the string "{numponies} bought for {pretty-num:cost} ({pretty-num:sps} SPS)" or something.

(Of course, that formatting part could also be done in the places that call printf in the first place; adding it here just might save some code duplication.)