Question

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?

Answer 1

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.