Improve language code matching logic for locale fallback #1534
Conversation
|
|
WalkthroughThe Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant LangSelector
participant languageMap
User->>LangSelector: Request closest supported language for code (e.g., "pt-BR")
LangSelector->>LangSelector: Extract first two letters of input code
LangSelector->>LangSelector: Find supported languages starting with those letters
LangSelector->>LangSelector: Return longest matching supported language or "en" if none found
LangSelector-->>User: Return closest supported language code
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm error Exit handler never called! Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (4)
✅ Files skipped from review due to trivial changes (3)
🚧 Files skipped from review as they are similar to previous changes (1)
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![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
🧹 Nitpick comments (1)
src/client/LangSelector.ts (1)
93-118: Consider edge case handling for robustness.The enhanced logic handles most scenarios well, but consider these edge cases:
- Empty string or very short inputs (handled by line 94)
- Language codes shorter than 2 characters (the
slice(0, 2)on line 108 could be problematic)- Non-alphabetic characters in language codes
Add a guard for the base language extraction:
const base = lang.slice(0, 2); +if (base.length < 2) return "en"; const candidates = Object.keys(this.languageMap).filter((key) => key.startsWith(base), );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/client/LangSelector.ts(1 hunks)
🧠 Learnings (1)
📓 Common learnings
Learnt from: andrewNiziolek
PR: openfrontio/OpenFrontIO#1007
File: resources/lang/de.json:115-115
Timestamp: 2025-06-02T14:27:37.609Z
Learning: For OpenFrontIO project: When localization keys are renamed in language JSON files, the maintainers separate technical changes from translation content updates. They wait for community translators to update the actual translation values rather than attempting to translate in the same PR. This allows technical changes to proceed while ensuring accurate translations from native speakers.
Learnt from: scottanderson
PR: openfrontio/OpenFrontIO#949
File: resources/lang/en.json:8-10
Timestamp: 2025-05-30T03:53:52.231Z
Learning: For the OpenFrontIO project, do not suggest updating translation files in resources/lang/*.json except for en.json. The project has a dedicated translation team that handles all other locale files.
Learnt from: Aotumuri
PR: openfrontio/OpenFrontIO#1357
File: resources/lang/de.json:523-540
Timestamp: 2025-07-12T08:41:35.101Z
Learning: In OpenFrontIO project localization files, always check the en.json source file before flagging potential spelling errors in other language files, as some keys may intentionally use non-standard spellings that need to be consistent across all translations.
Learnt from: andrewNiziolek
PR: openfrontio/OpenFrontIO#1007
File: resources/lang/he.json:138-138
Timestamp: 2025-06-02T14:27:23.893Z
Learning: andrewNiziolek's project uses community translation for internationalization. When updating map names or other user-facing text, they update the keys programmatically but wait for community translators to provide accurate translations in each language rather than using machine translations.
Learnt from: scottanderson
PR: openfrontio/OpenFrontIO#1171
File: src/client/LangSelector.ts:20-20
Timestamp: 2025-06-16T00:12:31.955Z
Learning: ISO 3166-1 country codes in OpenFrontIO language files should use uppercase format (e.g., pt_BR, not pt_br) to maintain consistency with the established naming convention and ISO standards.
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: andrewNiziolek
PR: openfrontio/OpenFrontIO#1007
File: resources/lang/de.json:115-115
Timestamp: 2025-06-02T14:27:37.609Z
Learning: For OpenFrontIO project: When localization keys are renamed in language JSON files, the maintainers separate technical changes from translation content updates. They wait for community translators to update the actual translation values rather than attempting to translate in the same PR. This allows technical changes to proceed while ensuring accurate translations from native speakers.
Learnt from: scottanderson
PR: openfrontio/OpenFrontIO#949
File: resources/lang/en.json:8-10
Timestamp: 2025-05-30T03:53:52.231Z
Learning: For the OpenFrontIO project, do not suggest updating translation files in resources/lang/*.json except for en.json. The project has a dedicated translation team that handles all other locale files.
Learnt from: Aotumuri
PR: openfrontio/OpenFrontIO#1357
File: resources/lang/de.json:523-540
Timestamp: 2025-07-12T08:41:35.101Z
Learning: In OpenFrontIO project localization files, always check the en.json source file before flagging potential spelling errors in other language files, as some keys may intentionally use non-standard spellings that need to be consistent across all translations.
Learnt from: andrewNiziolek
PR: openfrontio/OpenFrontIO#1007
File: resources/lang/he.json:138-138
Timestamp: 2025-06-02T14:27:23.893Z
Learning: andrewNiziolek's project uses community translation for internationalization. When updating map names or other user-facing text, they update the keys programmatically but wait for community translators to provide accurate translations in each language rather than using machine translations.
Learnt from: scottanderson
PR: openfrontio/OpenFrontIO#1171
File: src/client/LangSelector.ts:20-20
Timestamp: 2025-06-16T00:12:31.955Z
Learning: ISO 3166-1 country codes in OpenFrontIO language files should use uppercase format (e.g., pt_BR, not pt_br) to maintain consistency with the established naming convention and ISO standards.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: 🏗️ Build
🔇 Additional comments (1)
src/client/LangSelector.ts (1)
108-115: Smart fallback logic with good specificity handling.The base language fallback mechanism is well-designed. It correctly:
- Uses the first 2 characters as the base language code
- Filters candidates that start with the base
- Sorts by length descending to prefer more specific matches (like "pt_BR" over "pt")
This aligns well with your language map structure and handles cases where users might have "pt-PT" but you only support "pt_BR".
github-project-automation
bot
moved this from Triage
to Development
in OpenFront Release Management
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/client/LangSelector.ts (1)
97-103: Good enhancement, but consider supporting underscore delimiters too.The new logic correctly handles hyphen-delimited language codes and progressively tries shorter combinations. However, it only splits on hyphens while the AI summary mentions both hyphens and underscores should be supported.
Consider updating to handle both delimiter types:
- if (lang.includes("-")) { - const parts = lang.split("-"); + const delimiters = ["-", "_"]; + for (const delimiter of delimiters) { + if (lang.includes(delimiter)) { + const parts = lang.split(delimiter); for (let i = parts.length; i > 0; i--) { const code = parts.slice(0, i).join("_"); if (code in this.languageMap) return code; } + } + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/client/LangSelector.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: andrewNiziolek
PR: openfrontio/OpenFrontIO#1007
File: resources/lang/de.json:115-115
Timestamp: 2025-06-02T14:27:37.609Z
Learning: For OpenFrontIO project: When localization keys are renamed in language JSON files, the maintainers separate technical changes from translation content updates. They wait for community translators to update the actual translation values rather than attempting to translate in the same PR. This allows technical changes to proceed while ensuring accurate translations from native speakers.
Learnt from: scottanderson
PR: openfrontio/OpenFrontIO#949
File: resources/lang/en.json:8-10
Timestamp: 2025-05-30T03:53:52.231Z
Learning: For the OpenFrontIO project, do not suggest updating translation files in resources/lang/*.json except for en.json. The project has a dedicated translation team that handles all other locale files.
Learnt from: Aotumuri
PR: openfrontio/OpenFrontIO#1534
File: src/client/LangSelector.ts:97-106
Timestamp: 2025-07-23T12:36:35.331Z
Learning: In OpenFrontIO's LangSelector.ts, the getClosestSupportedLang method always joins language code parts with underscores ("_") because all keys in the languageMap use underscore format (e.g., pt_BR, sv_SE, zh_CN). This normalization ensures consistency regardless of whether the input language code uses hyphens or underscores as delimiters.
Learnt from: Aotumuri
PR: openfrontio/OpenFrontIO#1357
File: resources/lang/de.json:523-540
Timestamp: 2025-07-12T08:41:35.101Z
Learning: In OpenFrontIO project localization files, always check the en.json source file before flagging potential spelling errors in other language files, as some keys may intentionally use non-standard spellings that need to be consistent across all translations.
src/client/LangSelector.ts (9)
Learnt from: Aotumuri
PR: #1534
File: src/client/LangSelector.ts:97-106
Timestamp: 2025-07-23T12:36:35.331Z
Learning: In OpenFrontIO's LangSelector.ts, the getClosestSupportedLang method always joins language code parts with underscores ("_") because all keys in the languageMap use underscore format (e.g., pt_BR, sv_SE, zh_CN). This normalization ensures consistency regardless of whether the input language code uses hyphens or underscores as delimiters.
Learnt from: andrewNiziolek
PR: #1007
File: resources/lang/de.json:115-115
Timestamp: 2025-06-02T14:27:37.609Z
Learning: For OpenFrontIO project: When localization keys are renamed in language JSON files, the maintainers separate technical changes from translation content updates. They wait for community translators to update the actual translation values rather than attempting to translate in the same PR. This allows technical changes to proceed while ensuring accurate translations from native speakers.
Learnt from: Aotumuri
PR: #1357
File: resources/lang/zh_cn.json:527-539
Timestamp: 2025-07-12T08:42:02.109Z
Learning: In OpenFrontIO project, the territory pattern key "embelem" is the correct spelling used in all language files, not "emblem". This is the technical identifier that appears in en.json and must be consistent across all localization files.
Learnt from: Aotumuri
PR: #1357
File: resources/lang/de.json:523-540
Timestamp: 2025-07-12T08:41:35.101Z
Learning: In OpenFrontIO project localization files, always check the en.json source file before flagging potential spelling errors in other language files, as some keys may intentionally use non-standard spellings that need to be consistent across all translations.
Learnt from: scottanderson
PR: #1171
File: src/client/LangSelector.ts:20-20
Timestamp: 2025-06-16T00:12:31.955Z
Learning: ISO 3166-1 country codes in OpenFrontIO language files should use uppercase format (e.g., pt_BR, not pt_br) to maintain consistency with the established naming convention and ISO standards.
Learnt from: scottanderson
PR: #949
File: resources/lang/en.json:8-10
Timestamp: 2025-05-30T03:53:52.231Z
Learning: For the OpenFrontIO project, do not suggest updating translation files in resources/lang/*.json except for en.json. The project has a dedicated translation team that handles all other locale files.
Learnt from: andrewNiziolek
PR: #1007
File: resources/lang/he.json:138-138
Timestamp: 2025-06-02T14:27:23.893Z
Learning: andrewNiziolek's project uses community translation for internationalization. When updating map names or other user-facing text, they update the keys programmatically but wait for community translators to provide accurate translations in each language rather than using machine translations.
Learnt from: scottanderson
PR: #786
File: src/client/TerritoryPatternsModal.ts:337-338
Timestamp: 2025-06-22T05:48:19.241Z
Learning: In src/client/TerritoryPatternsModal.ts, the bit shifting operators (<<) used in coordinate calculations with decoder.getScale() are intentional and should not be changed to multiplication. The user scottanderson confirmed this is functioning as intended.
Learnt from: Aotumuri
PR: #1357
File: resources/lang/ja.json:0-0
Timestamp: 2025-07-12T06:35:10.457Z
Learning: In OpenFrontIO project, "giantworldmap" is the correct localization key name for the giant world map, used consistently across all language files and TypeScript code. Do not suggest renaming this key.
🔇 Additional comments (1)
src/client/LangSelector.ts (1)
105-112: Excellent fallback logic with smart candidate selection.The base language matching with length-based sorting is a solid approach that prioritizes more specific language variants (like
pt_BRoverpt). The logic correctly handles cases where no exact match exists.
src/client/LangSelector.ts
Outdated
| if (lang.includes("-")) { | ||
| const parts = lang.split("-"); | ||
| for (let i = parts.length; i > 0; i--) { | ||
| const code = parts.slice(0, i).join("_"); | ||
| if (code in this.languageMap) return code; | ||
| } | ||
| } |
There was a problem hiding this comment.
Let's just rename the files now.
github-project-automation
bot
moved this from Development
to Complete
in OpenFront Release Management
3 participants
Description:
This pull request improves the logic for matching language codes to supported languages.
Now, the function tries to find the most specific language by splitting the input code with “-” or “_”, and searching from the longest combination to the shortest.
If no direct match is found, it searches for all supported language codes that start with the same base (first two letters) and chooses the most specific one.
If nothing matches, it defaults to English.
Please complete the following:
Please put your Discord username so you can be contacted if a bug or regression is found:
aorumuri