Issues with automatic translation in localizations #53

New issue

Closed

opened 2026-07-15 05:40:10 -07:00 by serrebi · 4 comments

serrebi commented

2026-07-15 05:40:10 -07:00

Owner

One major problem is that the auto‑translation system doesn’t just add inaccurate translations for new strings—it actively overwrites existing, correct manual translations with incorrect ones. For example, the term “feed” is being inconsistently translated into different Russian words across various strings, which leads to terminology inconsistency in the UI. It would be the same as if in the English interface feeds were called "feed" in one place and "channel" in another.

Another issue concerns the ampersand symbol in original tab labels for settings. In UI framework, a single & acts as a shortcut key marker. To make the ampersand visible to the user, it must be escaped by using two consecutive ampersands (&&). This was required for tab labels like “Feeds & Articles” and “Startup & Tray”.

I previously fixed this by changing single ampersands to double ones so that the symbol displays correctly in the UI. However, the neural tool reverted this change, effectively bringing the bug back. It appears the model treated the double ampersand as a spelling mistake and “corrected” it.

Given these issues, the current neural tools are too destructive when handling UI texts and their translations. I propose either restricting their autonomy in this area or discontinuing their use for UI/localization tasks altogether.

Currently, the automatic translation tool is causing more harm than good for our localization workflow. It’s either necessary to significantly limit the autonomy of the neural translation tools or to stop using them for localization entirely and rely on human maintainers instead. One major problem is that the auto‑translation system doesn’t just add inaccurate translations for new strings—it actively overwrites existing, correct manual translations with incorrect ones. For example, the term “feed” is being inconsistently translated into different Russian words across various strings, which leads to terminology inconsistency in the UI. It would be the same as if in the English interface feeds were called "feed" in one place and "channel" in another. Another issue concerns the ampersand symbol in original tab labels for settings. In UI framework, a single & acts as a shortcut key marker. To make the ampersand visible to the user, it must be escaped by using two consecutive ampersands (&&). This was required for tab labels like “Feeds & Articles” and “Startup & Tray”. I previously fixed this by changing single ampersands to double ones so that the symbol displays correctly in the UI. However, the neural tool reverted this change, effectively bringing the bug back. It appears the model treated the double ampersand as a spelling mistake and “corrected” it. Given these issues, the current neural tools are too destructive when handling UI texts and their translations. I propose either restricting their autonomy in this area or discontinuing their use for UI/localization tasks altogether.

serrebi closed this issue

2026-07-15 07:51:03 -07:00

serrebi commented

2026-07-15 07:51:04 -07:00

Author

Owner

Resolved in v1.102.1.

Ampersands. The && fix in #65 (thanks @tseykovets) only covered the source strings and Russian. Because the source msgids changed to "Feeds && Articles" / "Startup && Tray", the other 14 locales were still matching the old single-& text — and most of them (de, es, fr, it, ja, nl, pl, pt_BR, pt_PT, sv, zh_CN, zh_TW) used a literal single & in "Startup & Tray", so they had the exact same bug where wx swallowed the ampersand as a mnemonic. All 15 catalogs are now synced and the literal ampersands are doubled everywhere. No translations were re-generated — this was a mechanical msgmerge + &→&& pass, and ru was left exactly as submitted.

Guardrails against the destructive auto-translation behavior:

tests/test_i18n.py now fails the build if the source labels lose their && escaping, or if any locale reintroduces a lone mnemonic & in these labels — so a model "correcting" && to & can no longer ship silently.
locale/README.md now states the policy explicitly:
- literal ampersands stay doubled (&&); never collapse them back;
- terminology stays consistent within a language (e.g. Russian "feed" = «канал», never alternated with synonyms);
- machine translation may only fill blank entries and must never overwrite an existing human translation; source changes go through msgmerge (which preserves existing translations), not re-translation.

Going forward, human translations are authoritative and automated passes are constrained to filling gaps.

Resolved in **v1.102.1**. **Ampersands.** The `&&` fix in #65 (thanks @tseykovets) only covered the source strings and Russian. Because the source msgids changed to `"Feeds && Articles"` / `"Startup && Tray"`, the other 14 locales were still matching the old single-`&` text — and most of them (de, es, fr, it, ja, nl, pl, pt_BR, pt_PT, sv, zh_CN, zh_TW) used a literal single `&` in "Startup & Tray", so they had the exact same bug where wx swallowed the ampersand as a mnemonic. All 15 catalogs are now synced and the literal ampersands are doubled everywhere. No translations were re-generated — this was a mechanical `msgmerge` + `&`→`&&` pass, and `ru` was left exactly as submitted. **Guardrails against the destructive auto-translation behavior:** - `tests/test_i18n.py` now fails the build if the source labels lose their `&&` escaping, or if any locale reintroduces a lone mnemonic `&` in these labels — so a model "correcting" `&&` to `&` can no longer ship silently. - `locale/README.md` now states the policy explicitly: - literal ampersands stay doubled (`&&`); never collapse them back; - terminology stays consistent within a language (e.g. Russian "feed" = «канал», never alternated with synonyms); - machine translation may only fill **blank** entries and must **never overwrite** an existing human translation; source changes go through `msgmerge` (which preserves existing translations), not re-translation. Going forward, human translations are authoritative and automated passes are constrained to filling gaps.

serrebi commented

2026-07-15 08:39:46 -07:00

Author

Owner

@tseykovets I actually agree with this. We should get rid of it because you have to pay to use it using a third party that not everyone will have access to.

@tseykovets I actually agree with this. We should get rid of it because you have to pay to use it using a third party that not everyone will have access to.

serrebi commented

2026-07-15 08:50:39 -07:00

Author

Owner

@tseykovets If a particular user wants to translate the app into their own native language, they can always reach out to us. As you have done, which is highly appreciated. This is how native desktop apps traditionally worked in the past. I think doing things this way provides way better authenticity, and is easier to maintain or should be in theory for existing translators and bug testers.

serrebi commented

2026-07-15 09:40:38 -07:00

Author

Owner

@Elshara I am not intending to step on the toes of people who want to contribute translations. Hopefully we're good from here.

@Elshara I am not intending to step on the toes of people who want to contribute translations. Hopefully we're good from here.