the devil's in the i18n details
when i start into making an application i18n, the normal course of discussion opens with a statement from the client on they had done such a [insert adjective here] job concerning seperation of text from code and from text presentation. the reality's usually nowhere near as good or bad as they make it out to be. i recently got involved in a "port and improve" project where the same sort of claims had been made but to my surprise the original developers had actually done a super-terrific, bang-up job completely seperating text from code and presentation. they had moved all the app's text into an include file, just ripe for localization. and in case you're wondering yes it scales pretty good--while this is an admin application and speed/loading's not such a big deal, it did handle the modest load tests i tossed at it. swell. but the fly in this ointment was the way they had chosen to handle this--rather than human understandable labels they used array locations (this is a straight port to CF from the original JSP): <input type="button" name="startButton" value="#textList[59]#" onclick="startChecked()"> ok, you can probably guess that this label has something to do with starting something or other but at 2:00 am that kind of detective work gets old real fast. also imagine re-visiting this app in 2 years time--its the sort of thing that makes you want to put your forehead thru the monitor. a real maintainence nightmare. so, i'm in the process of retro-fitting these into something more "sustainable" using a structure to hold the text labels (say from textList[59] to textLabels.startMapServiceButton, yes i like verbose labels). the devil is in the details after all.
posted by Paul Hastings @ 12:24 AM
0 Comments:
Post a Comment
<< Home