Lua Resource Files – Nobody Needs These
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
Hi,
We would use the Regular Expression File Filter in SDL Trados Suite/Studio to handle these files. This filter allows you to specify the text to be translated using regular expressions.
You’ll have to set up the following opening pattern , ” and closing pattern “. This way you don’t get the name value.
HTH
Thomas
Thomas: Good idea, and thanks.
But I still say it’s a dodgy way to structure a resource file…
I agree with Thomas. Trados Studio 2009 can easily handle 99% of the plain text file you throw at him that meet as long as the file is consistently formatted (cf. my other comment on your related article).
In such case, one can derive a set of regex that will define as precisely as possible the bounderies of the text to translate and clean up any remaining code by using inline patterns.
I do that on a daily basis with our 100+ casual games developers pumping out games in a vast array of formats and my worst nightwares have only involved files where establishing a pattern was really hard such as developers who use file based rather than line based parsers (ie. odd line for ID followed on even lines by the text).
But even in a case such as above, you can always rely on given semi-standards to clean out your files of variables and other non translatables, all you need are anchors you can hold onto, such as underscores, single words with no upper case, backslashes, square brackets and such.