If new strings will appears automagically after adding in code and they will have original English context (like in Gettext or XLIFF) it would be OK for me.
The main problem I've found in practice with (traditional) gettext is that it won't allow context-dependent translations. So if the same English word or short string is used in an entirely different context, you cannot have two distinct translations. It appears that GNU's version of gettext has a
pgettext() macro which allows the user to distinguish between contexts so maybe that's acceptable. It might cause portability problems, though, since it's not "standard" (for example, my NetBSD system does not have it (all BSD systems use
Citrus gettext), nor would a Solaris system (it uses a proprietary Sun implementation), but it's probably possible to link OpenXCOM against GNU gettext on all these systems). I also don't know how many of the GUI frontends for gettext support contexts. Another problem with gettext is the way translations are done using C printf-format strings; it's sometimes difficult to see exactly which placeholder corresponds to what variable. This can be solved using position-swapping and xgettext comments, but it feels a bit kludgy and requires great care on the part of the programmer, to assist the translators as much as he can.
I'm not familiar with XLIFF
at all, but from afar it sounds like a slightly better format (with support for translation status; translated, not translated, needs review), at the disadvantage of being a bit newer, so the tool support may be somewhat less mature. OTOH, there's
Pootle and
Virtaal, both of which support multiple formats. And the
GetLocalisation tool you mentioned supports both formats as well, and it sounds very good; integration with Github is very nice. If you use XLIFF, I guess you'll need to start looking for a library that can use the format, whereas gettext is a format and library rolled into one.
If you're going to overhaul the translation strings, it would be great if you could start using more placeholders/templates. For example, STR_WE_CAN_NOW_RESEARCH should probably use a placeholder for the thing to research, so it can be translated to Dutch as "Onderzoek naar %s is nu mogelijk". Note that this is not inherent to the technical translation system in use, but to the way the code constructs "sentences" out of translatable strings; it's always better to work with larger preconstructed "template" strings which can be translated as a whole rather than assembling them together in code. I think this has already improved, since I saw a few old assembled strings while I was translating to Dutch, which had been since replaced by better preconstructed template strings.
Finally, there
are some problems with grammatical gender of words, which may cause trouble in other languages than Dutch and English, and of course, pluralisation can cause issues even in English if not handled carefully (gettext has some
pluralisation facilities which may be of help here). These are fundamental problems with the current translation system, which any new system should address if it's worth overhauling the code for.
