Giant Localization Leap Backwards
"All of the strings are embedded in the code."
There was a time when I welcomed - or at least was not very much surprised by - sentences like this one. They came from engineers in response to my questions about the readiness of their software strings to be localized. Strings embedded in code, of course, are more or less inaccessible to localization techniques, since nobody wants to hand off an entire code base to a translator, and no translator wants to wade through an entire code base trying to find strings to translate.
So, when one of my client's engineers said it to me yesterday in reference to an application in a larger product we plan to localize, I briefly welcomed it. It means more work.
But then I realized that combing all of the strings out of the code and into separate, accessible files will require a great deal of time and effort (not mine). Engineers don't usually enjoy working on this kind of task, so it will fall to the bottom of the priority stack, and the product manager won't go to bat for it, and so this particular application will stick out like a sore thumb as a non-localized component in an otherwise localized product suite.
"Is there a phased approach we could take to enabling this app for localization?" the engineer asked.
I appreciated his attempt to save the game, but a partially localized product is rather ugly. We could enable and translate the menu and dialog strings for this release, and go back for the error messages in the next release, but the mongrel product is not very appealing to users in the meantime.
This is disappointing, because we've made such long localization-strides elsewhere in the product suite, and dealing with this newly acquired app feels like such a giant leap backwards. I guess I'll work up some estimates on the time required to enable the application, then make my case to the product manager and development lead to generate some interest and start the process from the beginning.
Isn't that why we localization project managers and international product managers were sent here?
What do you do in your company when engineers tell you that all the strings are embedded in the code?
There was a time when I welcomed - or at least was not very much surprised by - sentences like this one. They came from engineers in response to my questions about the readiness of their software strings to be localized. Strings embedded in code, of course, are more or less inaccessible to localization techniques, since nobody wants to hand off an entire code base to a translator, and no translator wants to wade through an entire code base trying to find strings to translate.
So, when one of my client's engineers said it to me yesterday in reference to an application in a larger product we plan to localize, I briefly welcomed it. It means more work.
But then I realized that combing all of the strings out of the code and into separate, accessible files will require a great deal of time and effort (not mine). Engineers don't usually enjoy working on this kind of task, so it will fall to the bottom of the priority stack, and the product manager won't go to bat for it, and so this particular application will stick out like a sore thumb as a non-localized component in an otherwise localized product suite.
"Is there a phased approach we could take to enabling this app for localization?" the engineer asked.
I appreciated his attempt to save the game, but a partially localized product is rather ugly. We could enable and translate the menu and dialog strings for this release, and go back for the error messages in the next release, but the mongrel product is not very appealing to users in the meantime.
This is disappointing, because we've made such long localization-strides elsewhere in the product suite, and dealing with this newly acquired app feels like such a giant leap backwards. I guess I'll work up some estimates on the time required to enable the application, then make my case to the product manager and development lead to generate some interest and start the process from the beginning.
Isn't that why we localization project managers and international product managers were sent here?
What do you do in your company when engineers tell you that all the strings are embedded in the code?
Labels: hard-coded strings, I18n, international product manager, internationalization, localization manager, new to localization, product manager, string localization
posted by John White, Localization Guy at
17:15
2 Comments:
Strings externalization is needed. Ask the engineer to simulate the process to translate the embedded or hard-coded strings, then s/he will learn how hard they way to translate those strings. If there is a chance to show her/him a Best Practice which all strings were externalized, s/he will be surprised how easy the translation process will be. But still, once the engineer start to think what's the impact to her/his coding process and the changes to be taken, s/he might be struggling with that.
By
arithmandar, at 04:40
In those cases you need to pitch to the the importance of it to the sales folks. If You have created the worlds greatest application but unfortunately but unless you have it globalablized, it will only ever have limited reach say only 20% of world wide users rather than 95% percent. Increase your product reach 400% should be enought motive.:-)
By
slyi, at 11:22
Post a Comment
<< Home