I've been doing some JSP work the last few months. We use struts. It's not too bad I've found.
One thing struts does pretty well is supporting translation to different languages through the use of keys [aka tokens] into a properties file. This generally works well for the programmer and we generally don't have to worry a whole lot about translation of the user interface screens to different languages.
A challenge can occur when developing a new screen or adding a section to an existing screen. The developer wants to focus on getting the JSP, JavaScript and HTML right. He will typically just hard code the labels right on the JSP and leave it to later when things are working to cycle back and convert the hard coded labels in the GUI to proper keys which have been added or already exist in the .properties file.
The problem can be that under tight deadlines the developer can forget to do this or miss a label or two, especially when there is conditional processing and everything doesn't necessarily appear every time. This can be a big problem because if the test team doesn't specifically test for this then the application can be in the field before the problem is detected. That could cause an expensive patch into the field.
One thing the developer can to do deal with this is to not use the true labels during the screen development when hard coding them. What I use is the prefix "zz". So Name, Address, Number becomes zzName, zzAddress, zzNumber in the hard coded development stage GUI. That way it's obvious looking at the screen I'm not using the tokenized labels and it's a reminder to fix it before shipping. For the programmer you can be sure you have everything by doing a search in Eclipse on "zz" in your code base and it will be obvious if you've missed anything.
For the test team, this can be a somewhat difficult problem to detect. One test case the test team can do is open up the tokens .properties file and prepend "zz" to every single label - this is pretty fast to do using a macro or script. Then restart the app and go through all the screens, including the dropdown lists. If you see anything appear on the new GUI without the zz prefix you know it's a raw, untokenized GUI element, a defect. This is important to test especially in screens where some elements may only occur under certain conditions, or when the screen content can be generated dynamically. Also error messages are a common source of untokenized GUI labels.
