The Potential Benefits of a Standard File Format for Video Game Localization

General information about game localization is not too difficult to come by these days. However, while the general aspects of our industry are well covered, technical topics are rarely covered. As a former developer myself, I have a great interest in file formats, which is why I initially wrote this article. I can't help but feel we need standards to simplify the localization process.

For more articles about localization, check out the IGDA Localization SIG group page.

For translators, game localization comes in all flavors. All developers seem to have their own way to present strings they need us to translate. While Excel files are common, their organization can greatly vary from a client to another. Some will use different numbers of columns displayed in a different order, others will enable all sorts of macros or use some color coding. Sometimes everything is gathered in a random order in a unique file and single tab, sometimes you end up with hundreds of small files with dozens of tabs.

Translators will either have to adapt and work in such files, or convert the strings into a format they can use in their everyday translation tool. Either way, these extra steps are a huge source of human errors, which can in turn cause major problems and much of stress when deadlines are looming.

Back to the other side of the process, implementing the strings back into the game can also require a number of steps, depending on how well the developer prepared for implementation. Again, these extra actions can take a lot of time from people who never have enough of it.

How can we solve or at least alleviate these problems? The best way to handle the situation would be to define a standard for game localization strings. Here are some advantages of such a solution, for both developers and translators.

Standard format = Everybody works towards the same goals

The main source of the problems mentioned above is that you will hardly find two developers handling localization the same way. Some existing methods are reasonably good, but none of them is fully optimized or offered with the tools needed to cover the whole process.

A common format means everybody can share their best practices and scripts for handling localization files properly. It would offer professionals of the industry a great chance to work together towards simplification of the localization process. We could quickly see automated tools for analysis, conversion, quality checks, etc. of localization files appear for the benefit of all.

The Developers' point of view

Consistency and predictability: With a standard format, no need to think about how you will handle strings. Everything is documented and the process is the same for every project. Once again, if everybody uses the same format, chances that automated tools will be available to generate source files from the game's code without any extra effort. No need to work on ad-hoc solutions and tweak them for every new project.

Seamless implementation: With a well-defined standard and the proper tools, implementation doesn't have to be more complex than a copy/paste of the files you get from your translators.

Traceability: It's great to highlight Excel cells in yellow, orange or pink when you make changes to your strings or add some, but it's tedious and leaves too much room to human errors. With a proper standard and related tools, it becomes much easier to see what has changed from a file to another and obtain meaningful analysis data.

This is also true for translators who need to perform word counts to figure how much they have to charge. Anybody will tell you that it's not particularly fun to manually look for highlighted strings in a huge Excel file and copy/paste them somewhere else to do a word count...

Where Translators benefit from a standard format

Flexibility: Excel files have their advantages and are always a useful reference when you need extra information about a string. However, many translators will prefer working with their own tools. The problem is that, to make it possible at all, we need to prepare the files to be able to open them with our software of choice. It can take quite some time (especially when it comes to updates) and be a source of mistakes.

With a standard format, however, it is possible to set up translation tools in the way they can open these files without any further modification. This one-time configuration can save hours of work down the road if developers stick to that format.

And of course you can use conversion tools if you want to, say, have a file in the original format for translation and one that Excel can open to display meta data (comments, specific instructions, etc.) in a more visual way.

Reduction of human errors: Translators hate playing with files and formats. I witnessed it first hand in one of my previous lives, and it wasn't a beautiful sight. The more steps a translator has to follow to prepare a source file or generate a target file, the more likely you are to end up with something unusable. If translators can directly open and save files in the proper format, you can (almost?) say goodbye to missing strings, broken tags and the like.

Conclusion: What are we waiting for?

On paper, a common standard could only offer advantages to everybody involved, and one may wonder what everybody is waiting for.

The video game industry is large and growing, with actors ranging from one-man studios to large corporations. Gathering everybody around the same table to discuss an issue still overlooked by many is a bit of a utopia.

Ideally, we would need a core of experts to work on the subject together with interested parties, create a format that works for all, produce the tools to make its implementation easy, and finally actively promote the package among developers of all over the world, regardless of their size, through every possible channel.

Industry experts, it's time to make it happen!