Localization

[Xpktro]

As Ingress is a global-scale game, some of their players are not fluent enough in the english language, so a localization option could be something interesting to implement an would help new (and non-native-english-speaking) players something to feel more familiar with :)

It wouldn't be so hard to implement I guess, I can even gladly contribute with the localization basecode and the first set of Spanish translations.

[jonatkins]

I don't see this as an urgent requirement, but at the same time I don't see why not.

Any thoughts on the best way of doing this?

• there is existing localisation code online that we can use to help
• localisation helper functions should be in IITC core, but plugin localisations themselves should be part of the plugin

Some stats on languages, based on website visitors:

• English is, by far, the most common language - over 50%
• German is also very common - nearly 20%
• Russian, Italian, French and Chinese are the next most common visitors - in the 5% to 2% range
• Czech, Spanish, Japanese, Polish, Dutch, Portuguese - 2% to 1%
• many other languages below the 1% mark - I won't list them all

[vita10gy]

The easiest way is probably just to collect all the english in something like /lang/en.js

localize.map_status.pause_during_interaction = 'paused during interaction';
localize.ok = 'ok';
localize.full = 'full';
//or group things like
localize.chat.full = 'full';
localize.chat.public = 'public';

And so on. Then just translate that file, and probably incorporate that as an option at build time.

Probably be best to include the english file always, then include the second language which will override whatever is defined. That way you get kind of a "cheap" fallback to english if the translation ever gets out of sync.

[Xpktro]

Some generic, OOP solution would be:

• A translation class (that can be a js hash) that would contain members consisting in html element ids associated with their literals (@vita10gy 's idea of grouping them would be valid as well):

Translation.id_public = 'public';
Translation.id_resonator = 'resonator';

• Also, this class will have a member consisting of the ISO 639-1 language code for the translation class:

Translation.language = 'en'

• Then a helper function called translate (that can be part of the translation class) that will iterate over the class members replacing the ids with their respective values. This can be bounded to a simple language combo (in which any new translation can be registered with some other function) that will call the tranlate function of the selected language.

[dreik]

I'm ready to help with russian translation.

[Fragger]

So here is a question, do we want to build the language in at build time, make all of them selectable on the fly or maybe make English the default and do plugins that can override it?

[Xpktro]

Something like an hybrid of that would work. One would have a collection of Translations and one of these would override the "CurrentLanguage", any plugin would be able to search into that collection and patch/add the desired strings, even pushing their own brand new translation object, then the internal machinery of the localization system would patch/add the strings into the current translation if the language code matches.

Also, for any other dynamicly generated string, like chat or system messages, one would be able to get any member of the special CurrentTranslation object (then, for example, apply string formatting), thus we can make language-agnostic code :)

[vita10gy]

I think we might be making this overly complicated. the plugins aren't going to be able to DO their own translations anyway, and there are a lot of reasons to want to pool everything that needs translating into one place.

I still think the easiest way to do this would be to simply have a file somewhere that defines all the strings the program uses

localize.map_status.pause_during_interaction = 'paused during interaction';

Or whatever. Any new stings, including those from plugins, just get added there.

Then the Russian lang plugin simply just overrides

localize.map_status.pause_during_interaction = 'паузу в процессе взаимодействия';

Either way new translations will need to be reactionary, but this way it's a pretty trivial language file comparison to see everything that needs translating. About the only drawback I can think of is that people will need to update iitc for plugin changes, but that's often the case anyway, and it's also not clear it wouldn't be the case with more complex solutions anyway.

[egelmex]

there is a jquery plugin to provide localisation... https://github.com/jquery/globalize