The current localization in MyRobotLab for the InMoov is based on "language packs". In an effort to make sure that users from all around the world that speak many languages can understand how to use MyRobotLab, we support having different translations for certain info , error, and status types of messages in myrobotlab.
For the inmoov this was managed though sets of files that are keyed of the "locale" or language. These files are dictionaries that key off so in the python code like
The new version will look like this:
And that would look up the string to use for "BATTERYLEVEL" in the current language (locale) that the bot is set to operate in.
This wasn't a very generic approach to this problem, so as we were looking at things to clean up for the nixie release, there's a new way of doing this.
Here are a couple key design points:
- Language specific strings are stored per service by default in the resource/ServiceType/localization directory. (replace "ServiceType" with the type of service InMoov2 for example.
- The files with the localized (translated) strings will be in standard java properties format. key=value (one per line, with comments starting with a # sign.)
- The 2 digit language code is used for the language specific filenames. for example: en.properties, or fr.properties
- Runtime defines the locale / language for MyRobotLab. Example: runtime.setLocale("en-US")
- Looking up the string will be using the "localize" method on services. Example: i01.localize("BATTERYLEVEL")
- If a translated label isn't found on the service, it will fallback to see if there's a match for that label defined for the Runtime service.
- If a language specific match for the label can't be found, we will fallback and return the english localized version (and potentailly we should log a message asking someone to help us translate that label.)
So, a few changes.. one other item to change is that there is only a single localization file per language. This is a change from the current inmoov which splits up these files amongst a few different .lang files. These will all be consolidated into a single file named "en.properties" in the resource/InMoov2/localization folder.
More details to come.. This work hasn't been done yet, but this is a heads up on how it will work going forward.
More details on lookup fallback:
Matching Precidence could/should be as follows:
- Match Service with current Locale of the Runtime service
- Match Runtime with current Locale of the Runtime service.
- Match Runtime with Default (english) Locale
Some additional comments about the keys used in the properties files.. they should be:
- alpha numeric only.
- no white space characters
- case insensitive
- should not contain an equals sign in the key
- generally, easy to read/understand as a human