The Rephrase work flow

After finally announcing Rephrase, I’ve been having some conversations about what it actually does and how it would benefit a game team. As usual with this sort of thing, I’ve had my head in this for long enough that the application seems obvious to me but to the rest of the world a few things need explaining. So I’ve knocked up a couple of diagrams that hopefully will explain why Rephrase is a good thing for the developer. Publishers and translators have different requirements in the localization process, but for developers the aim is to remove all the pain points that are associated with using generic tools ( or no tools at all ) to manage the large amount of data that localizing a modern game can generate.

Flow chart of localization work flow for a typical game

A typical work flow for localization of a game

Typical work flow

In the first diagram is what I think to be a example of a typical work flow when creating a game that is translated into multiple languages.

We start with the developer, who creates source data and adds it to the Master Spreadsheet. This is my major assumption, that most developers use a spreadsheet as their primary storage for localisation data ( at least text data ). This assumption seems to be borne out by the discussions that I’ve been having with developers.

Once the source data has been created someone divides up the master spreadsheet into separate sets suitable for each translator or agency. The translators do their work and the translations are entered into the new smaller spreadsheets and then returned to the developer. Someone back at the developer recombines the new translations into the master spreadsheet.

After the translations are made ( or as they are coming in ) an export process is run to convert the master spreadsheet into data that the game can use at run-time. Often this Export process is simply a VBAscript in the spreadsheet that converts the spreadsheet data into either a text or binary file which can be loaded by the game, or possibly it is converted into a source code file which is then compiled into the game directly.

Once the game is in test the real fun starts. If ( when ) the QA team find bugs in the localized data they submit these back to the development team who will flag the offending parts of the localized text as a bug ( and offer some description of what the bug is if it isn’t obvious ). Then, once a round of bug testing is complete the translation cycle begins again. This time not all of the assets need to be sent for translation, only those with bugs. Someone at the developer extracts the incorrect data from the master spreadsheet, along with description of the bug and then sends it off for translation. Once this data starts coming back in, the developer enters ‘Merge Hell’, multiple spreadsheets arrive, each with different languages and data, and must be merged into the master spreadsheet without introducing any new errors, or overwriting any previous bug fixes. Let’s hope, too, that none of the source data has been changed by the development team in the meantime. This is usually where we all start feeling sorry for the team member who is in charge of the localization.

Finally after many hours work, and lots of spreadsheet wrangling, all the bugs are fixed the data is re-exported one last time and the game ships. Hooray!

A flow chart showing the localization process using Rephrase

Work flow for localizing a game using Rephrase

Rephrase work flow

In the second diagram is the same work flow, only this time at the centre of the process is the Rephrase server. Hopefully it is clear from the diagram alone that this process is designed to be simpler and more straightforward, because Rephrase does a lot of the developer’s work for them.

We start with the developer again. They create the source data and add it through the web interface or via file import to the Rephrase server. Once the data is in the server and marked as ready to be translated it is made available to the translators next time they sign in to Rephrase. They take the source data and translate it adding the translations back to the server via the web interface or through a file import. Whilst the assets are marked as ready to translate, the developers can’t change the source so that we can be sure that when the data gets back from the translator, it is a translation of the correct source.

Exports can be made into a number of different formats, hopefully one that you can use directly in your game. If not, a post-export step can be applied to convert the data into the format you required.

The game is nearly finished now, and QA are battering it 24/7. Of course they find bugs in the localized content, but this time, instead of passing the bugs on to the development team to mark up, the QA department can simply re-open the flawed translation and mark it with a comment detailing what the bug is. Next time the translator signs in, the bug appears in their to-do list and gets fixed, with no intervention by the developers at all. If the QA team have the necessary skills and permissions, they could simply fix the issue themselves without even requiring the round-trip to the translator.

Of course all these actions are logged and browsable so the producers can see what activity is occurring and who is making changes.

Finally the last bug is fixed, the final export is made and the game is ready to ship. Hooray again!

Hopefully, this post makes it a little clearer how Rephrase can help game developers localize their games more easily and cut out on that Merge Hell.

Leave a Reply

Your email address will not be published. Required fields are marked *