Recursive localization for StringTable.Localize

[Jekyll Grim Payne]

Problem:

If you have a LANGUAGE string like:

Code: Select all

TestString = "You got $GOTINVUL"

...calling StringTable.Localize("$TestString") resolves to "You got $GOTINVUL" rather than "You got Invulnerability!"

StringTable.Localize should be able to localize LANGUAGE references placed inside other LANGUAGE-defined strings.

[Graf Zahl]

This makes zero sense. Construction kit text is something you can get away with in English but it won't work in most other languages. Therefore the localization system has (intentionally) no facilities for such a thing. Even the obituaries test the limits of some languages already, according to their translators it was particularly nasty in Czech and Turkish.

[Jekyll Grim Payne]

For context, I've been working in game localization for many years, I'm a professional linguist and translator, my native language isn't English, and I'm currently working on a localization library for GZDoom.

Not only it makes sense, it's an example of basic string concatenation that is in use everywhere right now. Obviously, from a linguistic perspective it won't work as is, because there are noun declensions, word order, plurality rules, gender rules, etc. — I never implied the opposite. This is something that I, like thousands of other people in localization, deal with on a daily basis, because even today 99% of games don't care about that and don't make any concessions for languages with rules different from English. And yes, of course, over-reliance on concatenation is a prime example of making text that is hard to localize. But this is another issue entirely, something that depends on good decisions from the writers and the creative solutions of the translators, and potentially a proper and more robust localization framework. This is not a reason not to have the feature, however.

The framework is something I'm planning, including the possibility of pulling variations of strings to support declensions. We could use something basic at first, though. The switch to .csv was a step in the right direction; improving StringTable.Localize could be another.

If this is a no, I can go ahead and do my own implementation, but this absolutely looks like something that should be available natively to me. The way it is right now, it either deincentivizes people from using LANGUAGE at all, or it makes them use something like "You got %s", then using String.Format to push another LANGUAGE reference into that %s, which has the same potential grammatical issues while involving extra steps.

[Graf Zahl]

You still haven't made a good point.
I can see how in English this allows deduplicating game specific terms in text, but with all the complex declensions in other languages it won't do much good in most.
On the other side it makes string translations a lot more complex than simply reading a string from a table.