What are the pro and cons of having localization files vs hard coded variables in source code?

Question

Definitions:

Files:

Having the localization phrases stored in a physical file that gets read at application start-up and the phrases are stored in the memory to be accessed via util-methods. The phrases are stored in key-value format. One file per language.

Variables:

The localization texts are stored as hard code variables in the application's source code. The variables are complex data types and depending on the current language, the appropriate phrase is returned.

Background:

The application is a Java Servlet and the developers use Eclipse as their primary IDE.

Some brief pro and cons:

Since Eclipse is use, tracking and finding unused localizations are easier when they are saved as variables, compared to having them in a file. However the application's source code becomes bigger and bloated.

What are the pro and cons of having localization text in files versus hard coded varibles in source code? What do you do and why?

Update 1: In my specific case, recompiling and deploying is not an issue, since it is done since we have test-phases that gives us a chance to find typos, etc. Because of that we rarely need to change the phrases once the application is on production.

Answer 1

Having the localization of app in its source code has many disadvantages - probably the biggest being, that when you want to fix/add/remove some localization, you have to recompile it and redistribute a new version. With separate files, the updates are more flexible, faster and easier to maintain and of course others can add localization to your app without the need to have access to the code.

So i would recommend going with the separate files option, not hardcoding it into the app.

Answer 2

If your project will be used by hundreds of people, localization is worth it because odds are some of them are more familiar with another language. If this project is only for internal use, then hardcoded variables are okay. If the number of users is below 100, the tasks of finding translators and maintaining each localization file are too cumbersome.

Answer 3

I think there is no choice between "Files" and "Variables". Because it should be always "Files".

pros:

a) Easy to maintain - The entire localization is in a single file.

b) No recompile required when there is a change.

c) Easy to introduce another language.

1. Usually translators are non-technical people.

2. Not necessary to change in multiple places.

Answer 4

If you are going to have localized versions of your program, then most likely you'll need a translator at some point. If you do not have localization files, you have to give the translator access to every source file with string resources (do you even know which they are?) and then you'll need to modify the source manually, which is prone for error.

Answer 5

For large software companies, the localization process has traditionally been performed by a separate group from the development team (often in a different country). The localization group would often work with binaries - hence the requirement for resource bundles to be separate artefacts. One of the goals of the process is to not let translators break source code; another is to not let programmers break strings.

From your comments, it sounds like you have tools to do some alternative form of automated String extraction and insertion. This might be a viable alternative if done right.

Questions I'd be asking about your translation process:

• Do you have tools to automate resource extraction and file rewriting?
  • Any cutting and pasting of strings (especially strings you can't understand) is likely to be a vector for bugs.
  • Can these tools distinguish between resource strings and untranslatable strings?
• Are you giving translators a standard file format they have the tools to work with?
• Do you have tools/processes for String recovery from previous versions?
• Is the size of the source code increasing significantly because you're adding translations?
  • When it comes to application logic, the strings are clutter you don't want to see and there's something to be said for separating logic and presentation data
• Is this approach going to scale if you add more languages?
• Are you introducing any encoding, keyboard or font issues?
  • There's not much point hard-coding strings if your editors break them
  • You can overcome the lack of character support using \uXXXX escaping

Long-lived products can accumulate unused resources, but I've never seen it become a practical problem. If you feel strongly about it, you can probably detect unused keys by scanning the sources.