CODEWITHSUNDEEP
javainternationalization
thejh
thejh

Reputation: 45568

Should I use english messages or message names in the code for internationalization?

A friend and me are starting a new software project (in Java), and we're thinking about how to do internationalization for the GUI. While I'd prefer to have english strings with placeholders in the code like this:

gettext("$name invites you to join $room", invitation.whose, invitation.roomname)

, my friend would prefer to only have an identifier, like invitation_message, in the code. My argument is that when the english string changes, the meaning might have changed somewhat, too, so the old translations shouldn't be valid anymore. However, he thinks the messages should be seperated from the code.

So, which method would you prefer and why? Or do you even have entirely different suggestions?

Upvotes: 2

Views: 214

Answers (4)

Tomasz Nurkiewicz
Tomasz Nurkiewicz

Reputation: 340743

Your friend is right. If your messages are hard-coded in Java sources, how do you want to implement ? In code you should only have placeholders:

gettext("invitation_message", invitation.whose, invitation.roomname)

and you should have separate translation files somewhere outside of the codebase:

  • messages_en.properties:

    invitation_message=$name invites you to join $room

  • messages_pl.properties:

    invitation_message=$name zaprasza cię do wstąpienia do $room

See also official Internationalization tutorial.

Upvotes: 0

Jörn Horstmann
Jörn Horstmann

Reputation: 34014

I prefer the gettext approach, my reasons are listed on the github page of my own i18n library, under the heading "Why use gettext instead of property bundles":

  • The need to invent a key for each message interrupts the programmers flow. Sometimes it is already pretty hard to think of meaningful variable names, having to think about something totally unrelated to the code, like translation further distracts the programmer.

  • The plural handling in gettext is superior for some languages having more than two plural forms. For simple cases pluralization can be done using ChoiceFormat, but languages like Polish require more complicated rules. Additionally, the syntax for ChoiceFormat is probably to complicated for non-developers.

  • There are specialized editors for editing gettext files, which are also usable by non-programmers. These editors have extensive features to support the translator, like remembering already translated string or containing a terminology database.

Upvotes: 1

Paweł Dyda
Paweł Dyda

Reputation: 18662

It depends. There are many things in your question, and I am not sure if I understand it correctly.

  1. Your friend want to separate programming logic from the translatable strings. Well, that's how Java's standard I18n resources (via ResourceBundle) works. If you want to use standard tools or commands (for example Externalize Strings in Eclipse), frankly it's the only way to go.
    However, some people think having keys in source files and a lot of rb.getString(key) poisons the code. Certainly, the code containing English strings is more readable. And you already have them, so you are not risking that you will see keys instead of real messages. With all pros and cons of this situation.
    If you stick to gettext, some tools might report these strings as hardcoded...

  2. I wonder what you mean by "While I'd prefer to have english strings with placeholders in the code like this"... Do your friend prefer not to use placeholders? That wouldn't be a good idea. Due to target language's grammar rules, people might actually need to re-order the sentence during translations, so in your example "$room" may come before "$name".

Going back to code - translatable strings separation, standard i18n Java programming guideline is to have translatable strings completely separated from programming logic. And you should follow guidelines unless you have good reason not to.

Upvotes: 2

Michael Borgwardt
Michael Borgwardt

Reputation: 346317

In the Java ecosystem, GNU gettext is not widely used; it has its own i18n mechanisms based on the ResourceBundle class, which is somewhat abstracted and encompasses not just text.

The most common way to define resource bundles for text is in properties files, and the keys in those can't contain whitespace which basically rules out your preferred style.

I actually like the GNU gettext style, but it's not worth not using the platform standard.

Upvotes: 1

Related Questions