keturn
New Member
Qualities to look for in an internationalization system include:
Anyone embarking on a project to change our i18n API should make sure they’re informed on what the current state of the art is, and what the pros and cons of adopting an existing third-party implementation might be.
As a starting place:
JDK
Ever since its early versions, Java has had some APIs for internationalization. The Internationalization Tutorial written for Java 8 is still relevant as those interfaces haven’t changed much in recent versions.
#4045 was a previous attempt to add support for variable substitution by using JDK’s MessageFormat class with Terasology’s existing APIs and language files.
The JDK’s interface for pluralization, ChoiceFormat, has known shortcomings.
Android
Android’s internationalization support is the best I’ve seen so far. It’s thoroughly documented: this guide on how to support different languages and cultures is one starting place.
Android libraries are, at some level, Java-compatible, but their handling of internationalized string resources involves some compile-time code generation, and we don’t know if it’s at all practical to use for a project that runs on OpenJDK without Android Studio.
moko resources
Moko resources is a more recent addition to the space. It’s focused on mobile platforms but there is an active pull request to support i18n resources on the JVM.
gettext
Many software projects use GNU gettext; it’s an interface with a free implementation that’s been around since the ‘90s. There are bindings or ports for it available it many languages, but it may not be something that’s had much use in the Java ecosystem.
See also:
- reporting where your application has hardcoded non-translatable text
- reporting which translations are out of date
- variable substitution, as in
- Congratulations to [PlayerName]! [Pronoun] just set a new record of [number] meters!
- pluralization. e.g. “one rock” vs “two rocks”
- comments on strings to provide additional context or instructions to translators
- a file format that works with existing translation tools. e.g. web portals for crowdsourcing translations, or Computer Aided Translation software.
- don’t forget about escaping! Different systems have different rules about which characters need to be escaped and how.
Anyone embarking on a project to change our i18n API should make sure they’re informed on what the current state of the art is, and what the pros and cons of adopting an existing third-party implementation might be.
As a starting place:
JDK
Ever since its early versions, Java has had some APIs for internationalization. The Internationalization Tutorial written for Java 8 is still relevant as those interfaces haven’t changed much in recent versions.
#4045 was a previous attempt to add support for variable substitution by using JDK’s MessageFormat class with Terasology’s existing APIs and language files.
The JDK’s interface for pluralization, ChoiceFormat, has known shortcomings.
Android
Android’s internationalization support is the best I’ve seen so far. It’s thoroughly documented: this guide on how to support different languages and cultures is one starting place.
Android libraries are, at some level, Java-compatible, but their handling of internationalized string resources involves some compile-time code generation, and we don’t know if it’s at all practical to use for a project that runs on OpenJDK without Android Studio.
moko resources
Moko resources is a more recent addition to the space. It’s focused on mobile platforms but there is an active pull request to support i18n resources on the JVM.
gettext
Many software projects use GNU gettext; it’s an interface with a free implementation that’s been around since the ‘90s. There are bindings or ports for it available it many languages, but it may not be something that’s had much use in the Java ecosystem.
See also:
- the current card on the GSoC Ideas List for Internationalization and Localization
- an earlier forum thread