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.
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 pack().
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.
Related
Let me describe the problem. A lot of suppliers send us data files in various formats (with various headers). We do not have any control on the data format (what columns the suppliers send us). Then this data needs to be converted to our standard transactions (this standard is constant and defined by us).
The challenge here is that we do not have any control on what columns suppliers send us in their files. The destination standard is constant. Now I have been asked to develop a framework through which the end users can define their own data transformation rules through UI. (say field A in destination transaction is equal to columnX+columnY or first 3 characters of columnZ from input file). There will be many such data transformation rules.
The goal is that the users should be able to add all these supplier files (and convert all their data to my company data from front end UI with minimum code change). Please suggest me some frameworks for this (preferably java based).
Worked in a similar field before. Not sure if I would trust customers/suppliers to use such a tool correctly and design 100% bulletproof transformations. Mapping columns is one thing, but how about formatting problems in dates, monetary values and the likes? You'd probably need to manually check their creations anyway or you'll end up with some really nasty data consistency issues. Errors caused by faulty data transformation are little beasts hiding in the dark and jumping at you when you need them the least.
If all you need is a relatively simple, graphical way to design data conversations, check out something like Talend Open Studio (just google it). It calls itself an ETL tool, but we used for all kinds of stuff.
I'm currently in the process of designing some desktop software and I've always wanted to implement an intuitive search function. For example, I need to write an algorithm that parses a search query like "next monday between 2 and 3pm" or "anytime after 2 on friday", or even "how do I use ". So the context can be very different but be asking the same thing, which is what gets me.
Should I be tokenizing the query (which I'm doing so far), or should I treat the string as a whole pattern and compare to a library of some sort?
I'm not sure if SO is the right place for this so if necessary point me in the right direction. Basically I would just like some advice as to the approach I should be taking.
Thanks.
Temporal Extraction (i.e. Extract date/time entities from free form text) - How? might give you some pointers.
"Entity extraction" is the process of extracting human recognizable entities (names, places, dates, etc.) from unstructured text. That article deals specifically with temporal entities but reading up on "entity extraction" in general is a good place to start.
Entity extraction has to be done per-language though, so expect difficulty when you're trying to internationalize your product to other locales. For Google Calendar, we spent a lot of time on temporal entity extraction and on expression recurrence relations in human readable form ("every last Friday in November") and each of the 40 locales that we operate in have their own quirks.
If you are planning to use a predefined grammar, you should consider using a state machine. There is for example the Ragel State Machine Compiler, which lets you use simple regular expressions to define a state machine and allows you to generate the actual source code for various target languages.
Here is a simple parser that I wrote to get all table names from an SQL select query. You could do something similar (https://gist.github.com/1524986).
I have written an application which outputs data as XML. However, it would be nice to allow the user to completely customize the output format so they can more easily integrate it into their applications.
What would be the best way to approach this problem? My initial thoughts are to define a grammar and write a parser from the ground up.
Are there any free Java libraries that can assist in parsing custom scripting(formatting?) languages?
Since I already have the XML, would it be a better approach to just 'convert' this with a search & replace algorithm?
I should specify here that 'users' are other programmers so defining a simple language would be fine, and that the output is potentially recursive (imagine outputting the contents of a directory to XML).
Just looking for general advice in this area before I set off down the wrong track.
EDIT: To clarify... My situation is a bit unique. The application outputs coordinates and other data to be loaded into a game engine. Everybody seems to use a different, completely custom format in their own engine. Most people do not want to implement a JSON parser and would rather use what they already have working. In other words, it is in the interests of my users to have full control over the output, asking them to implement a different parser is not an option.
Have you considered just using a templating engine like Velocity or FreeMarker.
I would have created a result bean as a POJO.
Then I would have different classes working on the result bean. That way you can easily extend with new formats if needed.
E.g
Result result = logic.getResult();
XMLOutputter.output(result, "myXMLFile.xml");
Format1Outputter.output(result, "myFormat1File.fo1");
Format2Outputter.output(result, "myFormat2File.fo2");
If you are planning to provide this as an API to multiple parties, I would advise against allowing over-customization, it will add unnecessary complexity to your product and provide just one more place for bugs to be introduced.
Second, it will increase the complexity of your documentation and as a side affect likely cause your documentation to fall out of sync with the api in general.
The biggest thing I would suggest considering, in terms of making your stream easier to digest, is making the output available in JSON format, which just about every modern language has good support for (I use Gson for Java, myself).
For my university's debate club, I was asked to create an application to assign debate sessions and I'm having some difficulties as to come up with a good design for it. I will do it in Java. Here's what's needed:
What you need to know about BP debates: There are four teams of 2 debaters each and a judge. The four groups are assigned a specific position: gov1, gov2, op1, op2. There is no significance to the order within a team.
The goal of the application is to get as input the debaters who are present (for example, if there are 20 people, we will hold 2 debates) and assign them to teams and roles with regards to the history of each debater so that:
Each debater should debate with (be on the same team) as many people as possible.
Each debater should uniformly debate in different positions.
The debate should be fair - debaters have different levels of experience and this should be as even as possible - i.e., there shouldn't be a team of two very experienced debaters and a team of junior debaters.
There should be an option for the user to restrict the assignment in various ways, such as:
Specifying that two people should debate together, in a specific position or not.
Specifying that a single debater should be in a specific position, regardless of the partner.
If anyone can try to give me some pointers for a design for this application, I'll be so thankful!
Also, I've never implemented a GUI before, so I'd appreciate some pointers on that as well, but it's not the major issue right now.
Also, there is the issue of keeping Debater information in file, which I also never implemented in Java, and would like some tips on that as well.
This seems like a textbook constraint problem. GUI notwithstanding, it'd be perfect for a technology like Prolog (ECLiPSe prolog has a couple of different Java integration libraries that ship with it).
But, since you want this in Java why not store the debaters' history in a sql database, and use the SQL language to structure the constraints. You can then wrap those SQL queries as Java methods.
There are two parts (three if you count entering and/or saving the data), the underlying algorithm and the UI.
For the UI, I'm weird. I use this technique (there is a link to my sourceforge project). A Java version would have to be done, which would not be too hard. It's weird because very few people have ever used it, but it saves an order of magnitude coding effort.
For the algorithm, the problem looks small enough that I would approach it with a simple tree search. I would have a scoring algorithm and just report the schedule with the best score.
That's a bird's-eye overview of how I would approach it.
Are there any good ways to work with blocks of text (Strings) within Java source code? Many other languages have heredoc syntax available to them, but Java does not. This makes it pretty inconvenient to work with things like tag libraries which output a lot of static markup, and unit tests where you need to assert comparisons against blocks of XML.
How do other people work around this? Is it even possible? Or do I just have to put up with it?
If the text is static, or can be parameterized, a possible solution would be to store it in an external file and then import it. However, this creates file I/O which may be unnecessary or have a performance impact. Using this solution would need to involve caching the file contents to reduce the number of file reads.
The closes option in Java to HereDoc is java.text.MessageFormat.
You can not embed logic. It a simple value escape utility. There are no variables used. You have to use zero based indexing. Just follow the javadoc.
http://download.oracle.com/javase/1,5.0/docs/api/java/text/MessageFormat.html
While you could use certain formatters to convert and embed any text file or long literal
as a Java string (e.g., with newline breaks, the necessary escapes, etc.), I can't really think of frequent situations where you would need these capabilities.
The trend in software is generally to separate code from the data it operates on. Large text sections, even if meant just for display or comparison, are data, and are thus typically stored externally. The cost of reading a file (or even caching the result in memory) is fairly low. Internationalization is easier. Changing is easier. Version control is easier. Other tools (e.g., spell checkers) can easily be used.
I agree that in the case of unit tests where you want to compare things against a mock you would need large scale text comparisons. However, when you deal with such large files you will typically have tests that can work on several different large inputs to produce several large outputs, so why not just have your test load the appropriate files rather than inline it ?
Same goes with XML. In fact, for XML I would argue that in many cases you would want to read the XML and build a DOM tree which you would then compare rather than do a text compare that can be affected by whitespaces. And manually creating an XML tree in your unit test is ugly.