Localization Project Management Log

I said it a few months ago and I’ll say it again: Nobody needs Lua resource files.

Just when CAT tools, parsers and SaaS implementations give us new features and functionality to simplify life for translators, new formats like this creep up to bite us. This is particularly true in mobile apps, since that is the new frontier in software development.

So when a mobile apps client decided to change the format for resource files from XML to a roll-your-own format designed for the Lua scripting language, I foresaw difficulties between unsophisticated translators and the format and advised the engineers on a plugin that would smooth the process of getting translatable strings into a format translators could use.

The client hasn’t yet released the plugin for its development platform, but it’s coming shortly. It takes this:

ModRsc {
--
 name  ="IDS_EXITCONFIRM_HDRSTR",
 id    =1800,
 type  = 1,
 data  =EncStringRscData(0x03, "Exit Application?"),
}
ModRsc {
--
 name  ="IDS_EXITCOFIRM_BODYTXT",
 id    = 1801,
 type  = 1,
 data  =EncStringRscData(0xff, "Are you sure you want to exit?"),
}
ModRsc {
--
 name  ="IDS_PRIVACY_POLICY",
 id    = 1802,
 type  = 1,
 data  =EncStringRscData(0x03, "Privacy Policy"),
}
ModRsc {
--
 name  ="IDS_RATINGSINFO_HDR",
 id    = 1807,
 type  = 1,
 data  =EncStringRscData(0xff, "Ratings Info"),
}
ModRsc {
--
 name  ="IDS_THANKYOUFREE_TXT",
 id    = 1808,
 type  = 1,
 data  =EncStringRscData(0xff, "Thanks for your download!"),
}

- which you really don’t want to hand off to a translator and which could be parsed if an engineer wrote a good enough regular expression for it – and turns it into this:

Not a very big deal for five strings, but quite a time-saver once you reach 50, 100, 200 strings.

You hand this .xlsx file off to translators, they translate into column D, they send it back to you, and the plugin takes the translation and round-trips it into the Lua resource format. That’s a great deal more accessible to translators, and it’s important to make them happy; otherwise, they can’t localize your software.

So, why am I still not content?

I’m not content because it takes a lot of software to perform this conversion:

• Microsoft Visual Studio
• Visual Studio Office Runtime
• software development kit for this mobile app platform
• .NET Framework

You may find these on the computers of software developers, but not likely on the computers of most of the people who would normally be tasked with handing off strings to translators: program managers, QA leads, tech writers, even localization project managers. And few translators would invest in all of this, let alone be interested in configuring it as needed.

Still, it’s inherent to the beast. Since this industry began, tools have been tying the Gordian knot between the necessary complexity of making text display in software and the necessary simplicity of letting translators perform their work.

If there were a solution located right in the middle of these two extremes, we’d have come up with it by now.

John White of venTAJA Marketing is a localization project manager and consultant. He is also a marketing communications writer for technology and language companies.

photo credit: David Kitching / CC BY-SA 2.0

One client’s team of extremely enthusiastic engineers has moved its product off of XML-formatted resource files and onto Lua files.

Perhaps this proves once again that XML is not exactly the promised land; something lies beyond it.

There is some organizational momentum toward Lua. The client is in the business of making mobile software – à la “There’s an app for that” (client is not Apple, before you ask) – and Lua is a darling of the mobile gaming community because it is a lightweight, high-performance language. In fact, World of Warcraft uses Lua.

Still, when it comes to handing the resource files off for translation, as it has in the last couple of days, Lua looks like yet another format in a world that we thought had room for no more.

The strings look like this:

--[[Standard Strings--]]
ModRsc {
	name="IDS_CLEAR",
	type=1,
	id=1110,
	data =EncStringRscData(0x03, "Clear")
}
--[[noneuse 'none' to indicate no URL or specify URL (e.g. http://www.johnwhitepaper.com/)--]]
ModRsc {
	name="IDS_START_URL",
	type=1,
	id=1111,
	data =EncStringRscData(0x03, "none")
}

The strings are similar to those of a typical value-pair resource file, like a .rc or a .properties file, and they even support comments, wherein one could pack context for translators.

But the CAT tool parsers don’t like it. Both the string ID and the string itself appear in quotation marks, so even if you created a rule to isolate all quoted text, you’d end up with the string names and the strings. The tools have evolved so far that it’s frustrating to see them grab elements we don’t need, then have to tell the translator to ignore those.

Last year, I posted on the issue of unsophisticated translators and file formats. At the time, the client’s India development center was working on a way of extracting these strings to .xls files. Sadly, there has been no progress worth announcing, so here we are with tweezers, pulling out the strings for translation.

I don’t see an easy way around it. Do you?

John White of venTAJA Marketing is a localization project manager and consultant.

photo credit:http://www.flickr.com/photos/cursedthing/ / CC BY-ND 2.0

“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?

In localization, “Catalyst” is a tool from Alchemy Software. Among other things, it allows you to localize UI elements within software resource files, sometimes without the need to rebuild the software manually into binary format.

Since software binaries come from text files, part of Catalyst’s value lies in straddling the divide between allowing the translator to change strings in the these text files (say, from English to Japanese) and displaying them in the binary, run-time format in which the user will see them on screen.

Last month a vendor returned some resource files to me which we had them localize from English to Japanese. I rebuilt the binaries (language-resource DLLs) and ran them. Unfortunately, a number of items were suddenly missing from the Japanese menus, so I had to troubleshoot the problem.

My first thought was that either a person or a tool (or a person using a tool) had modified something that should not be affected by the localization process. I had handed off a resource file containing these lines:

32777 MENU DISCARDABLE
BEGIN
POPUP “&Tools”
BEGIN
MENUITEM “Serial P&ort Settings…”, ID_TOOLS_SERIALPORTSETTINGS
MENUITEM “&Network Settings…”, ID_TOOLS_NETWORK
MENUITEM “&Battery Settings…”, ID_TOOLS_BATTERYSETTINGS
END
END

32779 MENU DISCARDABLE
BEGIN
POPUP “&File”
END

They returned to me a resource file containing these strings:

9 MENU DISCARDABLE
BEGIN
POPUP “???(&T)”
BEGIN
MENUITEM “??????????(&O)…”, ID_TOOLS_SERIALPORTSETTINGS
MENUITEM “????????(&N)…”, ID_TOOLS_NETWORK
MENUITEM “???????(&B)…”, ID_TOOLS_BATTERYSETTINGS
END
END

11 MENU DISCARDABLE
BEGIN
POPUP “????(&F)”
END

There was nothing wrong with the translation, and the string IDs were intact. The product has long been “double-byte clean,” so I knew that the software was not gagging on the Japanese characters.

The problem lay in the menu ID numbers, which are 32777 and 32779 in the English, but which came back in the Japanese files as 9 and 11. The vendor believes that Catalyst changed them, since they had used it to for resizing and QA.

Normally, this renumbering has no effect on how the binary functions. In this case, however, it has a profound effect on how the binary functions, because there is code somewhere in the software that is looking for “32777″ and “32779″ and when it doesn’t find those ID’s, it cannot complete the menu. This is poor internationalization in the code base which I have discussed with Engineering, to no avail, so I need to police the resource files in each round of localization.

How is Catalyst working for you? Have you seen similar problems?

Interested in this topic? You might enjoy another article I’ve written called “Localized Binaries – The Plot Thickens“

Have you ever stumbled onto something in the course of localizing a product that was private, or maybe even a bit compromising? Here’s a news item from telecoms.com that falls into that category:

This time round, Apple is supposedly prepping its iPhone to be a portable gaming machine, wading into a market already dominated by the likes of Nintendo and, to a lesser degree, Sony.

Although the ‘official’ iPhone applications market is noticeably void of any games at the moment – mainly due to the fact that Apple has banned third party apps from running natively on the device – some hackers claim to have found tell tale signs that games are indeed on the way.

Apparently, the iTunes localisation code makes some reference to a string asking the user if they want to remove the games in question. Naturally, this gave way to rumours that Apple has had a games developer partner lined up for some time and plans to offer gaming products via iTunes. [emphasis mine]

Some alert hacker (or maybe even a translator) must have lobbed a note about this string into the blogosphere, or otherwise publicly asked the question, “Why would they want to remove games?”

Who says there’s nothing proprietary or confidential in software resource files?

It’s a thrill for the gearhead in me to build my own localized binaries.

Most projects in the wide world don’t require this of the localization manager, of course. A staff engineer, or at least a release engineer, is usually tasked with building the binaries that house the localized software resources. There’s some delay involved in that, though, since the engineers don’t often place very high priority on building these infernal things, let alone building them as often as the localization QA cycles require.

The localizers are able to preview the localized resources in their localization environment (Alchemy, Visual Studio, etc.), but our engineers have an arcane build environment and procedure that I don’t care to impose on even my least liked localization vendor, simply because it’s an open invitation to failure. Instead, I persuaded the engineer who created the entire scheme to spend three hours duplicating the environment with me so that I could document it and reproduce it on a quick turnaround.

“Why are you going to all this trouble?” the engineer asked me.

“I’m trying to drive you crazy this one time so that I don’t drive you crazy eight or nine times over the next few weeks. The translators will find new things to change as they continue localizing the rest of the product, and they’ll change the resource files. If I have to bug you with each one of these changes, you may come to view localization as something, well, inconvenient.”

“Good. Thanks for sparing me that.”

That was for version 2.0.0 of this software. I was able to save precious days by doing my own builds and turning the binaries around to the localizers promptly. I also saved myself all of the credibility and Brownie points I’d have had to mortgage by running to the engineers all the time.

Now that we’re localizing version 2.0.1, however, the procedure is changed. The engineers have pulled the rug out from under me, and nothing that used to work, works. Time to bug the engineer again and get the updated Rosetta Stone so that I can build these things.

I like the way in which InstallShield does what it does. It’s too bad they won’t give me my own copy of the software, though.

It took me several iterations, but I’ve successfully navigated the areas in the InstallShield UI that do and do not support wide characters. (I thought there was a time when I could put anything anywhere and have it display properly, but suddenly I was getting corrupted characters in some screens in Asian installers. So much for the ailing memory of the noble localization project manager…)

Your mileage may certainly vary, but I found that, anytime we used double-byte characters in the strings labeled “(ASCII only)”, they became corrupted. My hunch is that there’s some other variable or setting required to support such characters in those places, but I figured I could give the release engineers only so much grief before I suffered backlash.

If you’re a double-byte InstallShield expert, by all means reply with the better localization way.