Relatively simple question. I need to translate/localize a legacy Java application.
Our company, with newer applications uses
.properties files in Java for localizing their strings, and this concept is very similar to
.resx files in C# (which we also have products using that).
The problem is this is a legacy product that was around before we started thinking about localization. It is full of hard coded strings and also various forms of hard-coded string concatenation/formatting.
As far as I am aware I have a very daunting task of pulling all our strings and formatting into
.properties files in the product and then referencing those in the code.
Personally I have no huge issue doing this work, but I want to make sure I am not missing something.
So I have a couple general questions.
Is there a faster way of converting my product to use the
.properties files? Off the top of my head I could write a script that would automate maybe 30-40% of the work...
Are there any "gotchas" I should be worried about specific to converting a legacy product (I am not looking for general localization "gotchas" which I can google for, but anything specific to this scenario)?
- Finally, are there any completely different strategies I am overlooking for localization? This is just how we translate our existing products, but because this is a legacy product (and on the agenda to be re-written) this is essentially throw-away code and I could do pretty much whatever I want. Including just finding the cheapest dirtiest fastest way possible, although I am obviously leaning toward doing the job properly.
Any thoughts, people?
As a guideline I would say try to keep answers focused on the questions being asked, but any informational contributions or questions are always welcome in comments.
Best How To :
No, there is no faster way. You have to go through the code line by line.
There are plenty of gotchas, since internationalization is about more than just string constants.
You may already know that number formats and date formats need to be localized, but you'll need to be on the lookout for numbers and dates being embedded into strings via concatenation or StringBuilder.append calls. You'll also need to be on the lookout for implicit toString() calls, such as when a Number or Date is supplied as a Swing model value (for example, returning a Number from the TableModel.getValueAt method), or when a JSP or JSF EL expression refers to such a value directly instead of formatting it.
Similarly, keep an eye out for enum constants directly displayed to the user, implicitly invoking their toString() method.
Creating sentences through string concatenation is a problem not only because of the formatting of numbers, dates, and enums, but also because other languages may have different ordering of sentence structure. Such string concatenation should be replaced with localized MessageFormats.
Keystrokes need to be localized, including all mnemonics (and accelerators if it's a desktop app).
Layouts are an issue. Places where the application assumes left-to-right orientation are something you'll want to address; even if you're only planning to localize for other left-to-right languages, you probably know that putting off good i18n practices is asking for trouble later down the line.
If your app is a Swing application, you'll want to convert LEFT/WEST and RIGHT/EAST layout constraints to LINE_START and LINE_END. If your app is a web application, you'll need to factor out margin-left, margin-right, padding-left, padding-right, border-left, and border-right (and probably many others I'm forgetting) into lang-specific CSS blocks.
Swing apps also need to call applyComponentOrientation after building each window, usually right before calling
Some programmers like to store parts of a UI in a database. I'm not talking about user content (which you shouldn't localize); I'm talking about label text, window titles, layout constraints, and so on. I have a hearty dislike for that practice, personally, but people do it. If your app is doing that, I guess either the database table needs a locale column, or the practice of storing the UI in the database needs to be removed entirely.
To answer your final question, if there are any better strategies than stepping through the code, I've never heard of them. You could just search for double-quote characters in the code, of course. I suppose the choice depends on how professional and polished your superiors want the application to look.
One thing I've learned is that throw-away code often isn't. Don't be surprised if that rewrite ends up trying to salvage large swaths of code from the legacy version.