i18n

[zoogie]

It's time we started thinking about how we are going to handle internationalization.

On Windows, the project currently uses string resources (albeit without any other languages). This solution, however, is not portable.

Options:

1. Transition to a portable library such as GNU gettext. This is less work than it sounds since almost all string lookups are done via a utility function. This has the advantage that both Windows and Linux contributors can (relatively) easily submit changes in a single feature-rich format and we can make use of open source coverage tools to pinpoint what needs translating.
2. Use a portable library only for the Linux build, and have a script extract the string resources, similar to what we do with the version info but on a much bigger scale. We'll probably miss out on the more advanced features provided by gettext (and the like) due to incompatible ways of handling them.

I personally don't think we currently have enough strings to justify any time savings from the second option, but there's an out-of-the-box solution already available, we should still consider the option.

(Setting component to "Build System" since this is mostly build-time work that affects all parts of the project).

[zoogie]

Looks like our best bet is to just bite the bullet and go straight-up gettext. I'll start things rolling by cleaning up unused strings in the string table.

[ryan]

I would agree with gettext, I think that's the better way to approach this. A lot of strings are loaded with MR_LoadString(), so theoretically that could just be modified to use gettext and that could take care of a lot of compatibility problems.

[zoogie]

Update (what's left to do):

• Linux: Add an Automake bit (or maybe a script) to "install" the generated .gmo files into share/locale for testing. I've got a few different options for doing this; I just need to decide which way to go.
• Win32: Set the thread language, not just the env var (otherwise the code page won't get set properly... I think). This involves converting the env var (in ISO abbreviated format) to an LCID. I have a very rough idea of how to do this based on MSDN docs. Hopefully I won't have to end up making a huge lookup table ;)

[zoogie]

Another update: Win32 side is settled and translations are underway. It's stable enough that I definitely think it'll be ready for 1.24.

New issues to solve:

• Translate menu entries.
• Figure out how to handle charset issues with the in-window text. It's currently stored as a static pre-rendered bitmap of characters. Keeping in mind that we'll be moving to a new engine-specific solution for 2.0, we can go with a dirty hack for this.

[zoogie]

[414] Shows the general strategy for dealing with i18n-ized HUD text. StaticText::SetText() is actually pretty fast, just not fast enough to be done every frame. It could be faster, but I'm not too keen on super-optimizing something we're just going to replace in 2.0 anyway :)

This just leaves the menu entries...

[zoogie]

... and [416] handles the menu. That's it, as far as architecture goes.

All that's left to do is make the remaining dialogs i18n-capable, and that's outside the scope of this ticket. I'm ready to move on to the next big thing :)