langs/i18n: Prefer languageCode when picking translation file #14225
Conversation
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. |
AI Detection Analysis 🔍Confidence Score: 35% Reasoning: Key Indicators:
Overall, this appears to be a thoughtful, human-written pull request, albeit one that could potentially be partially assisted by an AI in small ways (e.g., docstring phrasing or test scaffolding), but not generated outright. ✅ No strong indicators of AI generation detected |
Fixes gohugoio#14204 Closes gohugoio#14217 Co-authored-by: Patrice Chalin <pchalin@gmail.com>
bep
force-pushed
the
feat/languagecode-14217
branch
from
ec9975b to
45e5c4f
Compare
There was a problem hiding this comment.
Pull request overview
This PR fixes issues #14204 and #14217 by changing the translation file selection logic to prefer the languageCode (e.g., "en-US") over the language key (e.g., "en") when both translation files are present. This allows for more specific translations to be used when a language has a specific regional variant configured.
Key Changes:
- Introduced a new
Lookupmethod inTranslatorto allow non-fallback lookups - Refactored translation function retrieval into a new
getTranslateFuncmethod that trieslanguageCodefirst, then falls back toLang - Added comprehensive integration tests for both scenarios
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| langs/i18n/translationProvider.go | Refactored to use new getTranslateFunc method that implements the languageCode-first lookup logic |
| langs/i18n/i18n.go | Added Lookup method for non-fallback translation function lookups |
| langs/i18n/i18n_integration_test.go | Added integration tests covering languageCode preference and fallback scenarios with case-sensitivity variations |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
|
@gemini-code-assist review |
![gemini-code-assist[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the internationalization logic to prefer the languageCode when selecting a translation file, falling back to the language key. The changes are logical and are supported by new integration tests. I've made one suggestion in langs/i18n/translationProvider.go to improve the clarity and efficiency of the new translation function lookup logic. Otherwise, the changes look good.
| runTest := func(s string) { | ||
| b := hugolib.Test(t, s) | ||
| b.AssertFileContent("public/pt/index.html", `Greetings from pt!`) | ||
| } | ||
|
|
||
| runTest(filesTemplate) | ||
| runTest(strings.ReplaceAll(filesTemplate, "pt:", "PT:")) | ||
| runTest(strings.ReplaceAll(filesTemplate, "-- i18n/pt.yml --", "-- i18n/pT.yml --")) |
There was a problem hiding this comment.
Nice approach to test variants.
2 participants
Fixes #14204
Closes #14217