AGS Localization needs and proposals

[Potajito]

Hi!
We were recently talking on Discord about the way current AGS games handle localization and how that could be improved, so I have compiled a list of things that could be changed/improved upon and how it would ideally work. I’ve worked in the gaming localization industry for... many years now, having been a localization project manager for triple A titles, and I’ll try to mimic some of the things that work here too, minding the differences.

Currently, one of the biggest issues that the current AGS format has is the lack of string IDs and how easy is to break the .tra files. Also, they are hard to read in order to check if something is not right.

These 2 issues, readability and lack of unique ID, can be solved by adopting a cell based format, be it .ods, xls or, less ideally, csv. This is a standard format that all localization tools support and work well with, it’s easy to implement macros and the like, and can be expanded with comments or any other column that the developer needs. These files would be per language, as .tra works now, but in this format it would be trivial for the dev to compile a master file with all the languages needed one next to the other, in order to check for errors. These files would work by having at least 3 columns: String ID, Source Language and Target Language. String ID and Source Language should never change in translation.

Another issue is the lack of context/order. This one I believe is not straightforward to solve, but right now I don’t believe it is a problem thanks to the plugin Speech Center. That way we can export the dialogs and send those to the translators so they can look up the context. Is not ideal, but it’s good enough, and not a bad compromise.

This solves the lack of context for *most* of the text, but UI and items and, well, everything that is not dialog. On most games this would be a non/minor issue, but one way to solve this would be to have customized IDs, so instead of generated unique ID, string IDs could be customized, so, for example string “Back” could have the ID “back_button” so the translator/developer knows it’s a gui, and not the character’s back, for example. These kinds of issues are also easily solved by the dev adding a comment column to the AGS translation file, so I wouldn’t consider this a priority in any way.

This is all I can think of right now. I’m sure there would be more ideas and suggestions to come, but this is the bare minimum for a good localization pipeline, a major improvement over the current one and the base for a system that could be expanded.