Cross-platform I18N support

[davebaol]

Internationalization / localization is a very important aspect of many apps, not least games.
I'm working on a cross-platform I18N package for my libgdx apps.
My work is heavily inspired to ResourceBundle + Control class from java.util which is something all Java developers are used to.
Unlike java.util.ResourceBundle, it works for Android 2.2 too (Control class has been introduced in API level 9).
It provides all the main features of java.util.ResourceBundle but I've removed some less common stuff:

• ListResourceBundle aren't supported anymore. But who cares. Be honest, have you ever used it? :)
• you can't specify the ClassLoader anymore, which is something needed only by servlet containers and stuff like that, I guess. This should help to make it gwt compatible, but I'm a noob with gwt so it's just speculation.

Then I've implemented a FileControl class that can work with any gdx FileType and any encoding. If you don't specify any control when creating a bundle a default control is used, i.e. a FileControl with FileType.Internal and ISO-8859-1 encoding.
Users can also implement their own control class to support other sources (e.g. http instead of file system) and formats (e.g. xml instead of properties).

When it's finished - it works already for desktop and adroid platforms but some code cleanup is needed - I'll do a pull request if you're interested in.
In this case I'll need your help to support the gwt backend too.
What do you think? Suggestions, ideas?

[MobiDevelop]

This would be an extension?

[davebaol]

Well, if it will work on gwt too why not just a gdx package like math, scene2d and so on?
At the moment there are only 4 classes in my code.

[MobiDevelop]

To me this feels like an extension, not a core package. Maybe others won't
feel the same way.

[davebaol]

If you guys feel like that, it's ok for me. I just thought that an extension having only 4 classes is a bit ridicolous, but still. :)

[warmwaffles]

Yea, you think it's only going to be 4 classes, but I will be willing to bet that it's going to grow a bit.

[gjroelofs]

Depends I guess; not much more to expand on an already existing and defined
spec.
On the other hand, with Gradle now it won't be that much of a hassle anyway.

On Mon, Apr 21, 2014 at 10:51 PM, Matthew Johnston <notifications@github.com

wrote:

Yea, you think it's only going to be 4 classes, but I will be willing to
bet that it's going to grow a bit.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1741#issuecomment-40975805
.

[davebaol]

I have to agree with @methius since java ResourceBundle is well defined and rather full featured.
Sure, you can think of a handful of additional control classes supporting different transports and formats, but nothing more IMO.

[nooone]

I have dealt with this problem myself as well and found that the only real problem here is the GWT backend, which doesn't even have Locale. I solved the GWT translations with JSON files and my own "MessageBundle", which I load via the language/country code instead of the Locale. I think something like this would fit well into the libgdx core as it probably will be small and many people might need it, but only if it supports all backends. Otherwise people will still need to come up with their own I18N systems...

[davebaol]

@nooone I fully agree with you about making it a core package and supporting all backends.
Also I briefly discussed gwt implementation with @MobiDevelop and looks like the right path is to leverage GWT's preexisting localization, which supports both compile-time conversion of java property files and the search strategy implemented by java ResourceBundle.
See http://www.gwtproject.org/doc/latest/DevGuideClientBundle.html

BTW expect a PR for the Java version very soon.
I think the GWT version will come after discussing and approving the Java implementation. :)