Conversation
Walkthrough
ChangesTargetLanguages Expansion and Version Bump
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Apps.DeepL/Constants/LanguageConstants.cs (1)
13-129:⚠️ Potential issue | 🔴 CriticalVerify all added language codes against current DeepL API support before merge.
This PR adds ~84 language codes to the hardcoded
TargetLanguagesdictionary, which is used to validate user input before calling the DeepL client. Any unsupported codes will cause runtime failures when users attempt translation.Current status: The example codes you mentioned (ACE, AF, YUE) are confirmed supported by DeepL, and the regional variants (EN-GB, EN-US, PT-BR, PT-PT, etc.) are valid language code formats.
However: The definitive way to verify all 84 codes is to cross-check them against the DeepL API's
/v3/languagesendpoint withresource=translate_text. Since the DeepL.net SDK does not provide a static list of all supported languages (the API itself is the authoritative source), manual verification of the full list is necessary to ensure no unsupported codes are included in this dictionary.Recommend running through the live API endpoint or consulting the official DeepL supported languages list before this PR is merged to prevent user-facing failures on unsupported language selections.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Apps.DeepL/Constants/LanguageConstants.cs` around lines 13 - 129, Verify all language codes being added to the TargetLanguages dictionary in LanguageConstants.cs against the DeepL API's authoritative source by querying the /v3/languages endpoint with resource=translate_text parameter. Cross-check each of the ~84 codes in the dictionary against the API response to ensure they are all currently supported; remove or correct any codes that the API does not recognize as valid translation targets, as unsupported codes will cause runtime failures when users attempt translations.
🧹 Nitpick comments (1)
Apps.DeepL/Constants/LanguageConstants.cs (1)
7-129: 💤 Low valueConsider updating README.md to reflect the expanded language support.
This PR significantly expands the supported target languages from ~20 to over 100 languages. Users may benefit from documentation that lists or describes the newly supported languages, especially if this is a major feature update.
Per the coding guidelines, check whether the README.md reflects this change.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Apps.DeepL/Constants/LanguageConstants.cs` around lines 7 - 129, The LanguageConstants.cs file now defines significantly more supported languages (over 100 language entries in the dictionary) compared to the previous implementation. Update the README.md documentation to reflect this expanded language support. Add or revise the section that describes supported languages to list the newly added languages or provide a comprehensive overview of the language coverage, ensuring the documentation accurately represents what is now available in the LanguageConstants dictionary.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Apps.DeepL/Constants/LanguageConstants.cs`:
- Line 13: Before adding base language codes like EN, PT, and ZH to the
LanguageConstants, you must clarify the intended use case and API behavior.
Determine whether the primary use case is translation (where DeepL API accepts
but may default to undocumented variants) or glossary configuration (where base
codes are required for setup). If the use case is translation, decide whether
the plugin should restrict users to explicit variant codes to prevent
unpredictable regional defaults. If glossaries, document that base codes are
setup-only while variants apply the glossary. Once these architectural questions
are resolved, update the code and any related UI/documentation accordingly to
ensure users understand which codes apply to which operations and what behavior
to expect when selecting a base code.
---
Outside diff comments:
In `@Apps.DeepL/Constants/LanguageConstants.cs`:
- Around line 13-129: Verify all language codes being added to the
TargetLanguages dictionary in LanguageConstants.cs against the DeepL API's
authoritative source by querying the /v3/languages endpoint with
resource=translate_text parameter. Cross-check each of the ~84 codes in the
dictionary against the API response to ensure they are all currently supported;
remove or correct any codes that the API does not recognize as valid translation
targets, as unsupported codes will cause runtime failures when users attempt
translations.
---
Nitpick comments:
In `@Apps.DeepL/Constants/LanguageConstants.cs`:
- Around line 7-129: The LanguageConstants.cs file now defines significantly
more supported languages (over 100 language entries in the dictionary) compared
to the previous implementation. Update the README.md documentation to reflect
this expanded language support. Add or revise the section that describes
supported languages to list the newly added languages or provide a comprehensive
overview of the language coverage, ensuring the documentation accurately
represents what is now available in the LanguageConstants dictionary.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 74d2aaf8-d9f1-4b08-b5f4-f15b00147ff1
📒 Files selected for processing (2)
Apps.DeepL/Apps.DeepL.csprojApps.DeepL/Constants/LanguageConstants.cs
| { "EL", "Greek" }, | ||
| { "EN-GB", "English (British)" }, | ||
| { "EN-US", "English (American)" }, | ||
| { "EN", "English" }, |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does the DeepL API accept base language codes like "EN", "PT", or "ZH" without regional specifiers, or does it require explicit regional variants like "EN-US" or "PT-BR"?
💡 Result:
The DeepL API accepts base language codes for many languages, but for languages that have multiple regional or script-based variants (specifically English, Portuguese, and Chinese), it often requires or strongly encourages the use of explicit variant codes [1][2]. Key details regarding language code usage: - Supported Formats: DeepL API language codes follow BCP 47 [3][4]. The API is case-insensitive, accepting uppercase, lowercase, or mixed-case codes (e.g., 'pt-BR', 'PT-BR', or 'pt-br' are all valid) [5][1][6]. - Regional/Script Variants: For languages like English (EN), Portuguese (PT), and Chinese (ZH), the API often requires you to specify a variant to ensure the correct output, such as EN-US or EN-GB, PT-BR or PT-PT, and ZH-HANS or ZH-HANT [1][2]. When translating into these languages, if you omit the variant, the API may default to a specific regional variant, but it is best practice to explicitly define the desired variant [1]. - Source vs. Target Usage: Regional variants are generally intended for use in the target_lang parameter [1]. Using a variant code in the source_lang parameter may cause an error [1]. - Customizations: When creating customizations such as glossaries, you must use the root language code (e.g., PT, ZH) rather than a variant code (e.g., PT-BR, ZH-HANS) [7]. Once created with the root code, the glossary can then be applied to translation requests using any of that language's supported variants [7]. - Backward Compatibility: In some cases, DeepL maintains support for original root codes even after introducing specific variants to ensure backward compatibility for existing integrations [4]. However, for new development, you should consult the /v3/languages endpoint to identify the officially supported codes for your specific use case [3][2].
Citations:
- 1: https://developers.deepl.com/docs/learning-how-tos/examples-and-guides/translation-beginners-guide
- 2: https://developers.deepl.com/api-reference/translate/request-translation
- 3: https://developers.deepl.com/api-reference/languages/retrieve-supported-languages-by-resource
- 4: https://developers.deepl.com/docs/resources/language-release-process
- 5: https://deepl-c950b784.mintlify.app/api-reference/languages/migrate-from-v2-languages
- 6: https://github.com/DeepLcom/deepl-python/blob/main/README.md
- 7: https://developers.deepl.com/docs/learning-how-tos/examples-and-guides/customizations-for-variants
Clarify which DeepL API operations support base language codes without variants.
The PR adds base codes EN (English), PT (Portuguese), and ZH (Chinese) alongside regional variants. DeepL API behavior differs depending on context:
- For translation (target language): The API accepts base codes but may default to an undocumented variant if one is not specified. Best practice requires explicit variant codes (e.g.,
EN-US,PT-BR,ZH-HANS). - For customizations like glossaries: The API requires root codes (e.g.,
PT,ZH) but then supports any variant of that language.
Before adding base codes to the UI, clarify:
- What is the primary use case — translation or glossary configuration?
- If translation, should the plugin restrict selection to explicit variants to avoid unexpected behavior?
- If glossaries, document that base codes are for setup only and variants apply the glossary.
Without this clarity, users selecting "EN" may receive an unpredictable regional variant.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Apps.DeepL/Constants/LanguageConstants.cs` at line 13, Before adding base
language codes like EN, PT, and ZH to the LanguageConstants, you must clarify
the intended use case and API behavior. Determine whether the primary use case
is translation (where DeepL API accepts but may default to undocumented
variants) or glossary configuration (where base codes are required for setup).
If the use case is translation, decide whether the plugin should restrict users
to explicit variant codes to prevent unpredictable regional defaults. If
glossaries, document that base codes are setup-only while variants apply the
glossary. Once these architectural questions are resolved, update the code and
any related UI/documentation accordingly to ensure users understand which codes
apply to which operations and what behavior to expect when selecting a base
code.
1 participant
Update list of supported languages