I18N
Gabriele Battaglia
Hi everyone,
Julian, thanks for narrowing down my problem so well.
When Shaunt wrote to me yesterday, I thought I was being stupid; I
checked and re-checked all the menus, but in my case, the second option
entry had nothing to do with changing the language. Then I read your
email and it was enlightening.
Guys, I suggest this: for a while, let's stop fixing things and
introducing new features, which are otherwise much appreciated. Let's
release a new version in which we force the English language for
everyone until we better define this issue. I say this because, as
things stand, I don't think it's possible to play in a language other
than English, and perhaps Chinese, which I don't know. Besides the
problem with incorrect menu items, I think there are also issues with
the keys: I have combinations that tell me I'm controlling units, and
then, when I look for an order, it tells me I can't because I'm not
controlling any units. An inconsistency due, I think, to the game's
internationalization.
For I18N, I use pybabel, which can be installed via pip and is easy to
use. It uses gettext |_()| to wrap strings.
Then you can use that tool I sent a few days ago, |translator.py|, which
can be called in parallel on all installed languages.
Once the automatic translations are complete, you need to ask an
LLM—Gemini Flash 3.6 and Kimi K3 are great at this—to:
1.
Check the semantics and consistency of all translated strings;
2.
Verify the correctness of placeholders enclosing variables in the
translated strings;
3.
Compile all catalogs.
Naturally, all the code must be modified so that every string is
enclosed in |_().format()|, and here too the LLM can speed up the work.
I suggest installing Antigravity-CLI in your environment and calling it
with |agy|, logging in with Google, and giving it extremely specific and
detailed prompts.
I propose studying and using my utility package, where I believe you can
find interesting things. I make extensive use of it in all my
applications, and it contains the |polipo| functions for I18N and
|auto-updater|, which could be useful.
Check out the code here: www.github.com/GabrieleBattaglia/GBUtils
<https://www.google.com/search?q=https%3A%2F%2Fwww.github.com%2FGabrieleBattaglia%2FGBUtils>
Talk to you soon,
Gabe.
--
Gabriele Battaglia (IZ4APU)
--... ...-- -.. . .. --.. ....- .- .--. ..- - ..- . .
Sent from my Giant desktop PC.
修君
Gabriele Battaglia
Il 28/07/2026 08:19, 修君 ha scritto:
> I estimate that the French and pt-br (Brazilian Portuguese) languages
> cannot run the game properly.
Julian Dreykorn
the game itself, but also in external components like mods, which makes
a normal replacement with Babel/gettext harder. But I agree with you,
since I know that already from other projects, this would be the most
modern and user-friendly approach. I already started creating scripts to
help with the translation, will update here when I have real progress to
share.
Julian Dreykorn
It's not only mods using that format, tts.txt may also contain
references to sound files, therefore this format should (for now) stay.
But what I have ready now, and will momentarily submit as the next PR:
Scripts to use gettext in between. So, already in my GitHub, and in
upstream once merged, you'll find:
tools/i18n/extract_pot.py
that will create corresponding .po files under i18n, which then can be
used by translators, an LLM, uploaded to crowdin, or whatever. When
that's done, build_tts.py can be used to recreate the tts.txt from the
pot files, leaving the structure usable, but simplifying translations in
this way. That should already make things a lot easier, and allow us to
continue correcting the translations.
Best, Julian
修君
Julian Dreykorn
I agree that AI models can measure benchmarks and compare, but the new i18n tooling (btw thank you again for the very quick merge) will also make that more reliable, here's why. Other than Gabe I use Claude Code and Codex instead of Antigravity, but the procedure may be similar. E.g. to do many languages at once, I could prompt to check for all the .po-files under i18n, and spawn a subagent for each, to save model context. Then, the agent needs to check only this single file, and add missing or empty strings accordingly. E.g. if you now search for 5750 in tts-de.po, the string we were talking about on Monday, you'll find it, with the msgid language, making such a shift much less likely, because everything related lives in one place.
--
You received this message because you are subscribed to the Google Groups "soundRTSChat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to soundrtschat...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/soundrtschat/c2e1b286-ee9f-4c09-bcd9-c66cdb573972n%40googlegroups.com.
Julian Dreykorn
Hi,
Gabe, I checked your translator.py and this was definitely worth saving. However, the problem involved lies in the structure of SoundRTS: Target language needs to be known, and was hardcoded there. However it's not always the same, some was English, e.g. Crazymod had French as source, and some sources even were Chinese as it looked. So, I created a new pipeline in the tools/i18n directory. check_translations.py reports the current state across all languages, extract_pot.py renders the tts.txt files to .po files under i18n, build_tts.py does the opposite direction back to txt. Additionally, the big amount of strings can be split into groups, then merged back with apply_translations.py. See the section translating with an LLM in the README under tools/i18n, once the PR is merged. That workflow allowed me to get German from 50% up to 100% now, as check_translations.py confirms. Maybe that helps you as well, e.g. for Italian.
Best, Julian
--
Gabriele Battaglia
Thanks for info.
Unfortunately I have no experience within the localizzation you're
facing on with SoundRTS and I am afraid I can't help with that.
Anyway I'm just a step away following you guys with great interest.
If there is something I could do to support, just ask.
Gabe.