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