Worth automating the messages.properties translation sync?

[hiciefte]

I cloned the repo and counted the messages_*.properties files against messages.properties (1,076 keys, 25 languages). Every language is incomplete — Russian is the most complete at 82%, then German 79%, French 80%, dropping to Hungarian 29%, Korean 31%, Czech 32%, Dutch 35%. As new English strings get added, the translations fall further behind.

I maintain Bisq's localization tooling (localize-pipeline) and could set up a workflow that translates the changed keys and opens a PR to review. It stays off until someone adds a model key, never merges by itself, keeps the {0} placeholders intact, and can run on a local model. Since you keep some of these current by hand, the idea is to take that off your plate.

Before I put up a PR: worth having here? If AI-drafted translations are a no for you, that's fine — just say so.

cc @helge17

[guiv42]

Personally, I am very clearly not favorable to automated translation.
Especially when it comes to technical (musical) jargon, I prefer by far an absence of translation to an approximate translation that cannot be checked by any means.

By the way, the completeness indicators you mention are quite pessimistic. Historically, text items that are unchanged when translated from English are not repeated. As an example, "note" in English translates to "note" in French, but as it is implicit it appears "not translated" in your indicator.
That could (should?) be changed if we want to have representative indicators.

[hiciefte]

Thanks for the candid take — that's genuinely useful. And good catch on the metric: you're right that counting identical source/target strings as "untranslated" overstates the gap, since unchanged items like "note" aren't repeated. The real backlog is smaller than my numbers suggested.

On the jargon concern — that's the part I'd want to solve rather than wave away, because an unverifiable approximate translation of a musical term is worse than leaving the English. Three things the pipeline uses for exactly this:

• Glossary — musical/technical terms are pinned per language (or marked "never translate"), so the model can't paraphrase "capo," "slur," "tremolo" etc. into something approximate; they resolve to the agreed term every time.
• Prompt guidance — a per-language style/terminology brief goes into the prompt, so the output follows the conventions a native contributor would use rather than generic machine phrasing.
• Native review, continuously — this is how we run it on Bisq: the AI draft is a starting point, not the shipped string. It flows through Transifex, where native speakers correct and refine over time. So there's always a human check — the draft just means they're editing instead of starting from a blank file.

None of that forces AI text into a release unreviewed, which I think is the crux of your concern. If it's still not a direction you'd want for TuxGuitar, that's a completely fair answer and I'll leave it.

[guiv42]

OK, thanks for the precision. I remain globally opposed to this. There is a significant risk of seeing tens of PRs (at least one per language) that will remain open for a very long time, with no one in charge of review. And if some day anybody claims it has reviewed one, it's difficult to be confident. I would naturally give more confidence to a PR that has been initiated by a contributor: this proves that some effort has been done. Furthermore, AI tools usually produce outputs that look pretty well, but the devil sometimes hides in the details and it's quite easy to miss it even during a review.

Anyway, this is only my opinion, and I'm not alone here

[hiciefte]

Fair enough — I won't try to talk you out of it. One factual correction for the record, though, since it's the crux of the PR-sprawl worry: it isn't one PR per language. The pipeline opens a single PR per batch of source-string changes, with all affected locales in it together. So a round of English updates produces one reviewable PR, not tens of parallel ones sitting open with no owner — the review surface is the same shape as a contributor-initiated PR, just pre-filled.

That doesn't resolve your deeper point — that a machine-drafted PR carries less proof-of-effort than a contributor's, and that subtle errors can survive review — and I think that's a legitimate place to land. Appreciate you taking the time to spell it out.