You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by "hiciefte (via GitHub)" <gi...@apache.org> on 2026/07/06 09:42:15 UTC
[I] Worth automating the messages.properties translation sync? [jmeter]
hiciefte opened a new issue, #6719:
URL: https://github.com/apache/jmeter/issues/6719
The localisation guide says the coverage gaps are "due to lack of contributions," and the numbers back that up. I cloned `master` and counted the core `messages` bundle (1,522 keys, 11 languages): only French (96%) and Korean (93%) are close. The rest lag — German 35%, Traditional Chinese 38%, Japanese 29%, Norwegian 9% — and that's before the ~289 component bundles, which add a lot more untranslated strings.
These land as hand-written PRs a component at a time, so they drift as English strings change.
I maintain Bisq's localization tooling ([localize-pipeline](https://github.com/bisq-network/localize-pipeline)) and could set up a job that translates the changed keys and opens a PR to review. It stays off until someone sets a model key, never merges by itself, keeps the `{0}` placeholders intact, and handles the ISO-8859-1/`native2ascii` encoding these bundles use. It can run against a local model too.
Worth pursuing? Happy to move this to `dev@` if that's the better place. And if AI-drafted translations are a no in principle, that's a fine answer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jmeter.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Worth automating the messages.properties translation sync? [jmeter]
Posted by "vlsi (via GitHub)" <gi...@apache.org>.
vlsi commented on issue #6719:
URL: https://github.com/apache/jmeter/issues/6719#issuecomment-4893679276
Thanks for the proposition. I would close the issue as the localization is not focus, and adding the workflows would divert maintainer's attention.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jmeter.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Worth automating the messages.properties translation sync? [jmeter]
Posted by "vlsi (via GitHub)" <gi...@apache.org>.
vlsi closed issue #6719: Worth automating the messages.properties translation sync?
URL: https://github.com/apache/jmeter/issues/6719
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jmeter.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Worth automating the messages.properties translation sync? [jmeter]
Posted by "vlsi (via GitHub)" <gi...@apache.org>.
vlsi commented on issue #6719:
URL: https://github.com/apache/jmeter/issues/6719#issuecomment-4891546345
Localization requires native-speaker review.
Sure LLMs help with translations, however, their output requires proofreading.
Frankly, I think the right direction for localization is:
* Create language-specific skill for technical writing (see https://github.com/Netcracker/qubership-ai-packages/tree/main/agent-packages/english-us-developer-style, https://github.com/Netcracker/qubership-ai-packages/tree/main/agent-packages/french-developer-style, https://github.com/Netcracker/qubership-ai-packages/tree/main/agent-packages/russian-developer-style)
* Create a app-specific glossary for each language. E.g. see (not sure if you read Russian :) ) https://github.com/vlsi/jmeter/blob/russian_translation/xdocs/localising/glossary_ru.md
* Generate/update translations with LLM
* Review the translations with a native speaker
WDYT?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jmeter.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Worth automating the messages.properties translation sync? [jmeter]
Posted by "hiciefte (via GitHub)" <gi...@apache.org>.
hiciefte commented on issue #6719:
URL: https://github.com/apache/jmeter/issues/6719#issuecomment-4892555304
That workflow is exactly the shape I'd want, and native review staying as the final gate is non-negotiable for me too — the pipeline never auto-merges, it just opens a PR.
The glossary and style-guide pieces are already how localize-pipeline works: it takes a per-language glossary of required term mappings plus terms that must never be translated, and enforces them in the prompt, so your `glossary_ru.md` would drop in almost directly. It runs against a local model and handles the ISO-8859-1/`native2ascii` encoding these bundles use.
On the proofreading point — that's exactly how we run it on Bisq. The AI drafts ship as a starting point, but they're not treated as final: they flow through Transifex, where native speakers correct and improve them over time instead of facing an empty file. So the human review isn't a one-time gate, it's continuous, and the machine draft just removes the cold-start problem.
If it's useful, I could prototype it end-to-end on a single language against the core `messages` bundle — reusing your Russian glossary — and open a draft PR so you can see the output quality before committing to anything.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jmeter.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Worth automating the messages.properties translation sync? [jmeter]
Posted by "vlsi (via GitHub)" <gi...@apache.org>.
vlsi commented on issue #6719:
URL: https://github.com/apache/jmeter/issues/6719#issuecomment-4892777154
> handles the ISO-8859-1/native2ascii encoding these bundles
We target Java 17+, so we should use UTF-8 properties and drop native2ascii altogether. I thought we have removed that long ago, however, I should double-check.
> If it's useful, I could prototype it end-to-end on a single language against the core messages bundle — reusing your Russian glossary — and open a draft PR so you can see the output quality before committing to anything.
Got it.
The pace of development is low in JMeter, so I would refrain from adding automatic localization at the moment.
The idea is great, yet I think one-time pass would be sufficient.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jmeter.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org