Although I speak only English, I am generally in favor of localizing software. It’s a noble goal to spread the wealth so that everyone on Earth can benefit, even if we are only talking about a game. On the other hand, as a software engineer I do know the costs.
Each piece of UI text would have to be read from a file, or database table, to populate each window. I would have to write the code to do that, which is a huge task considering how much UI there is in Aurora.
To be fair, there are libraries you can lean on; it’s not like you’re the first person ever to localize a program. At most you just have to call a function that does all that work for you, and returns the localized string. And of course you then have to move the text into the default English localization.
Although I do not regularly program in C#, I recommend a library called [Fluent.Net](
https://github.com/blushingpenguin/Fluent.Net). It is a port of [Project Fluent](
https://projectfluent.org/) to C#. I’ve used Fluent localization before, and found it to be significantly better than the alternatives. The way it handles the complexities of date/time formatting, plurals, grammatical cases, and other nuances that are specific to individual languages without adding complexity to the core implementation or to other localizations is a breath of fresh air. My primary purpose for writing this post was to make this recommendation, both to you Steve as well as to everyone else who happens to read it. Project Fluent is the way to go.
But of course, no matter what library you use there is still the long, tedious, and error–prone process of actually converting hardcoded text into localizable text. There’s just no getting around that.
Also, the translated version might not fit into the same amount of space as the English version, so the UI would have to be able to cope with fields potentially being moved around to handle that, or someone would have decide on suitable abbreviations to fit the space (and to do that I would have to provide the space allowed for every single translated field or column).
Yes, or redesign the UI to be much more flexible. Since the size of almost every UI element can now vary, the position of every UI element must be recalculated based on how much space the previous elements are taking up. I’m not sure exactly how the code is written, but I do know that .net has a number of tools you can use to do this without writing the code to measure everything and reposition every element by hand.
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/layout?view=netdesktop-8.0, for example.
- Likely, Steve would also have to write a lot of error checking/handling for the translations. Checking if a translation is complete before loading it, checking if a translation is the right length for the UI, etc. This kind of error checking is possibly the most tedious task of all since it is very difficult to abstract such things.
- Any translations would have to be provided by fans. Similar to the open-source debate, this would put Steve in a role as a project manager instead of a hobbyist programmer which he has no interest in doing.
If you really want a translation, probably the best approach would be to look at something like AuroraPatch, which may let you access these things at the code level or at least give an idea how you could develop a translation mod.
There are ways we can limit the pain though. For example, incomplete localizations are usually handled by falling back to the English text, which is assumed to be complete. When a new feature is added to the game, the translations will not have been updated yet, so that feature’s text will get displayed in English. On the one hand that is a little suboptimal for the user of the translation, but on the other hand those translations are provided by volunteers who cannot reasonably held to any specific shipping schedule.
Most localization systems these days come with a web–based editor that can be used by volunteers to contribute localized text. There’s no reason to make Steve spend his own time hosting it, or even to make him include the translations in the Aurora download. He could just direct players who want translations to download them separately, same as is currently done with mods.
It would be interesting to see how far we could get with AuroraPatch before we tore our hair out; I suspect it would add an extra layer of tedium to the task.
There is no getting around the fact that there would be a lot of work that realistically only Steve can do. As Steve has always said, he is writing the software primarily for himself, and judges all work to be done based on how much he personally will benefit from it. It is easy to see that when judged on that metric, localization must rank pretty low on the list. Maybe one day Steve will be especially bored and have no other ideas to implement, but I doubt it.