Added multi language as a potential candidate to replace single language

[ronnie-neo-sonarsource]

---

Summary by Gitar

• Refactored plugin structure:
  • Renamed JapanesePackPlugin to LanguagePackPlugin and updated the pom.xml artifact ID to sonar-l10n-plugin.
  • Simplified plugin registration to support multiple locales (Japanese and Korean) automatically via the classpath.
• Enhanced translation tooling:
  • Updated python/translate.py to support multiple languages through a LANGUAGES configuration list.
  • Optimized translation batch processing and added skip logic for files with no missing translations.
• Updated documentation:
  • Refreshed README.md with instructions for maintaining a multi-language plugin and updated build/usage steps.

_{This will update automatically on new commits.}

[ronnie-neo-sonarsource]

gitar display:verbose

[ronnie-neo-sonarsource]

gitar why is the file translate.py changed?

[gitar-bot]

gitar why is the file translate.py changed?

The python/translate.py file is changed as part of the PR's goal to support multiple languages instead of just one.

Details

Here's a summary of what changed and why:

1. Multi-language support: Previously, the script was hardcoded for a single language (Japanese), with fixed target_language, source_filename, and target_filename variables. Now it defines a LANGUAGES list of (name, locale) pairs (currently Japanese and Korean) and loops over them.

2. Template-based file paths: Hardcoded file paths were replaced with report_template and target_template using {locale} placeholders, so the same logic applies to any language.

3. Function signature cleanup: translate_chunk and translate_properties had default parameter values like target_lang="Korean" that were misleading or incorrect — those defaults were removed since the language is now always explicitly passed.

4. Model variable: The hardcoded "gpt-4o" model string was replaced with an openai_model variable (presumably set from config/env), making it easier to change the model without editing the code.

5. Skipping empty reports: A guard was added to skip translation if there are no missing translations for a locale, avoiding unnecessary API calls.

6. Batch size: Default batch size changed from 20 to 500.

In short, the script was generalized to handle any number of languages rather than being single-language-specific.

[ronnie-neo-sonarsource]

gitar please fix this

[gitar-bot]

gitar please fix this

Done. The driver loop in python/translate.py is now wrapped in an if __name__ == "__main__": guard, so importing the module (e.g. in tests or other scripts) will no longer trigger API calls and file writes as a side effect.

[ronnie-neo-sonarsource]

Gitar please summarize this

[gitar-bot]

Here's a summary of this PR:

Goal: Generalize the plugin from supporting a single language (Japanese) to supporting multiple languages (currently Japanese and Korean).

Changes:

• src/main/java/.../LanguagePackPlugin.java (renamed from JapanesePackPlugin.java): Plugin class renamed and generalized so it registers all configured locales instead of just Japanese.
• pom.xml: Artifact ID updated to sonar-l10n-plugin to reflect the multi-language scope.
• python/translate.py: Replaced the hardcoded single-language logic with a LANGUAGES list of (name, locale) pairs, template-based file paths (report_template/target_template), an openai_model variable instead of a hardcoded model string, a skip guard for locales with no missing translations, and a larger default batch size (500 vs 20). The driver loop was also wrapped in an if __name__ == "__main__": guard so the module can be safely imported without triggering API calls.
• README.md: Updated with instructions for maintaining and building a multi-language plugin.
• Tests: LanguagePackPluginTest.java (renamed/updated) covers the renamed plugin class.

Net effect: 73 additions / 33 deletions across 5 files — the plugin and its tooling no longer assume a single target language, making it straightforward to add more languages by extending the LANGUAGES list.

[ronnie-neo-sonarsource]

Gitar please check if there is any problems

[gitar-bot]

Gitar please check if there is any problems

Running a full review on this PR now. I'll post the findings shortly.

[ronnie-neo-sonarsource]

Gitar which file has the most changes?

[gitar-bot]

Gitar which file has the most changes?

python/translate.py has the most changes — 39 lines modified (+/-), compared to LanguagePackPluginTest.java (17), LanguagePackPlugin.java (13), README.md (25), and pom.xml (12).

[ronnie-neo-sonarsource]

Gitar can you check if I can do a unit test here

[gitar-bot]

Yes, unit testing is possible for python/translate.py:1, and the recent __main__ guard makes it practical.

Details

Since the driver loop is now wrapped in if __name__ == "__main__": (python/translate.py:145), importing the module no longer triggers real OpenAI API calls or file writes. That means these functions are safe to unit test directly:

• parse_properties / extract_expected_translation — pure string/regex parsing, easy to test with sample input strings.
• chunk_dict — pure logic, trivial to test with small dicts.
• load_properties / save_properties — file I/O, testable with tmp_path fixtures (pytest) or temp files.
• translate_chunk / translate_properties — these call the OpenAI client, so you'd want to mock client.chat.completions.create (e.g. with unittest.mock.patch) rather than hitting the real API.

One thing to note: there's currently no test setup for the Python side (no requirements.txt, pytest, or test directory in python/), so you'd need to add that tooling first (e.g. pytest + a python/tests/ folder) before adding actual test files.

Let me know if you'd like me to scaffold a test file/setup for this.

[ronnie-neo-sonarsource]

Gitar please check if there is any injection flaw

[gitar-bot]

Gitar please check if there is any injection flaw

On it — running a security review to check for injection flaws (SQL, command, code injection, etc.) in this PR. I'll follow up with findings.

[ronnie-neo-sonarsource]

Gitar how is your day

[gitar-bot]

Gitar how is your day

Doing well, thanks for asking! Ready to help review or fix anything on this PR — just let me know.

[ronnie-neo-sonarsource]

Gitar can you check if function names are snake case

[gitar-bot]

Yes — in python/translate.py all function names are snake_case: load_properties, save_properties, chunk_dict, translate_chunk, extract_expected_translation, parse_properties, translate_properties. That's consistent with PEP 8.

Details

The Java files (LanguagePackPlugin.java, LanguagePackPluginTest.java) use camelCase for methods (toString, define, testLanguagePackPlugin), which is correct per Java convention — Java doesn't use snake_case for method names, so no issue there either.

So no naming inconsistencies to flag in this PR.

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Refactors the plugin structure to support multiple languages while centralizing translation logic, resolving the missing main guard issue in the translation driver.

Auto-approve skipped: The PR does not touch the required .claude/skills path, which is the only criteria provided for approval.

✅ 1 resolved

✅ Quality: Translation loop runs at import time (no __main__ guard)

📄 python/translate.py:145-150
The new per-language loop in python/translate.py:145-150 executes at module import time. Anyone importing translate.py (e.g. to reuse parse_properties/translate_chunk, or a future unit test) will trigger real OpenAI API calls and file writes as a side effect of the import. Wrapping the driver loop in an if __name__ == "__main__": guard keeps the reusable functions importable while preserving the CLI behavior described in the README.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: verbose → Showing more information.

Comment with these commands to change the behavior for this request:

Auto-apply	Verbose
gitar auto-apply:on	gitar display:compact

_{Was this helpful? React with 👍 / 👎 | Gitar}