Add vue-i18n (#116) #673
Add vue-i18n (#116) #673
Conversation
…18n if needed, closes #116
WalkthroughThe pull request introduces comprehensive internationalization (i18n) support to the frontend application. The changes span multiple files, adding Vue I18n plugin configurations, localization files, and updating components to use dynamic translations. The implementation focuses on German localization, systematically replacing hardcoded text with translatable keys. Modifications include updates to the ESLint configuration, package dependencies, and TypeScript type definitions to fully integrate internationalization capabilities. Changes
Sequence DiagramsequenceDiagram
participant App as Vue Application
participant I18n as Vue I18n Plugin
participant Locale as Locale Files
App->>I18n: Initialize with locale
I18n->>Locale: Load translation files
App->>I18n: Request translation for key
I18n-->>App: Return translated text
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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
Documentation and Community
|
github-actions
bot
added
the
Template: Frontend
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
refarch-frontend/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (13)
refarch-frontend/eslint.config.js(3 hunks)refarch-frontend/package.json(1 hunks)refarch-frontend/src/App.vue(4 hunks)refarch-frontend/src/components/TheSnackbar.vue(1 hunks)refarch-frontend/src/components/common/YesNoDialog.vue(2 hunks)refarch-frontend/src/locales/de.yaml(1 hunks)refarch-frontend/src/plugins/i18n.ts(1 hunks)refarch-frontend/src/plugins/index.ts(1 hunks)refarch-frontend/src/views/GetStartedView.vue(6 hunks)refarch-frontend/src/views/HomeView.vue(2 hunks)refarch-frontend/tests/unit/example.spec.ts(2 hunks)refarch-frontend/tsconfig.app.json(1 hunks)refarch-frontend/vite.config.ts(2 hunks)
🧰 Additional context used
🪛 Biome (1.9.4)
refarch-frontend/vite.config.ts
[error] 3-3: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
🔇 Additional comments (34)
refarch-frontend/src/components/TheSnackbar.vue (3)
15-15: Localization key usage looks good!
Using t("common.actions.close") here aligns perfectly with your i18n structure. Ensure you monitor changes to common.actions.close in the locale files to keep the UI consistent.
22-22: Importing useI18n is aligned with the new i18n implementation.
This import is necessary and sufficiently scoped to handle all translations in this component.
28-29: Integration of the i18n instance is well done.
Destructuring t from useI18n() is a concise approach that keeps the component code clean and consistent. Consider verifying locale availability when adding more translations.
refarch-frontend/src/views/GetStartedView.vue (4)
5-8: All good on the heading and subheading changes.
Thank you for replacing hardcoded strings with dynamic translations using t("views.getStarted.dokuHeader") and t("views.getStarted.dokuSubtext"). This helps maintain uniform i18n support across the application.
58-59: Good approach to translating dialog titles and text.
Leveraging the t('views.getStarted.saveLeave.title') and t('views.getStarted.saveLeave.text') ensures the dialog contents will be easily adjustable for different languages.
68-74: i18n setup is correct.
The import useI18n and the destructuring of t are straightforward and well-aligned with Vue I18n usage patterns. This is fundamental to enabling translations.
Line range hint 15-51: Consistent usage of translation keys for links.
Each link text is now localized with t("views.getStarted.dokuLinks.XXX"). This maintains consistency and ensures that translators need only update language files, not references in multiple files. Nicely done!
You might want to ensure that all keys reference the correct German translations in your de.yaml or any fallback locale by running a quick search for these keys in the translation files.
✅ Verification successful
Let me search for these translation keys in the locale files to verify their existence.
Let me try a different approach to locate the translation files.
I found the German translation file. Let's check its content to verify the translation keys.
All translation keys are properly defined in the German locale file
I've verified that all the translation keys used in the links are correctly defined in the German translation file (de.yaml) under the path views.getStarted.dokuLinks:
barrakuda: "Barrakuda-Doku"apiGateway: "Doku Archetype API-Gateway"backend: "Doku Archetype Backend"archetypesRepo: "Git-Repo Archetypes"javascriptWiki: "Javascript-Wiki"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for translation keys used here to ensure they exist in the locale files
rg "views\.getStarted\.dokuLinks\."
Length of output: 596
Script:
#!/bin/bash
# Search for translation files
fd -e yaml -e json "translations|locales|i18n"
# Let's also check the content of any found translation files
fd -e yaml -e json "translations|locales|i18n" --exec cat {}
Length of output: 113
Script:
#!/bin/bash
# Try to find any yaml or json files that might contain translations
fd -e yaml -e json .
# Also search for any imports of translation files
rg -i "import.*\.(yaml|json)" -A 2
Length of output: 1363
Script:
#!/bin/bash
# Check content of the German translation file
cat refarch-frontend/src/locales/de.yaml
Length of output: 1346
refarch-frontend/src/plugins/index.ts (2)
3-3: Use of i18n import is consistent with project architecture.
This import cleanly integrates internationalization support.
9-9: Chain registration of i18n plugin.
Great job adding .use(i18n) to the existing plugin registration chain for a seamless i18n setup.
refarch-frontend/tests/unit/example.spec.ts (2)
9-9: Importing i18n for test environment.
Including i18n in unit tests ensures accurate coverage of localized text and avoids missing translation errors.
32-32: Mounting TheSnackbar with i18n plugin.
Providing the i18n plugin in the test environment is essential for verifying translated strings in the component.
refarch-frontend/src/plugins/i18n.ts (2)
10-36: Well-defined date/time formats for German locale.
The structured datetimeFormats nicely covers short, long, and timestamp variations. This ensures consistency of date/time presentation.
38-44: Creating and exporting the i18n instance.
Setting both locale and fallbackLocale to "de" is suitable for a German-only app. In the future, you can extend this to support additional locales as needed.
refarch-frontend/src/views/HomeView.vue (4)
14-14: Replacing static header text with translation key.
This dynamically translates the header, enhancing the bilingual or multilingual readiness of the application.
17-17: Localized text for API gateway status.
Using t("views.home.apiGatewayStatus") ensures consistent translations across different locales if added later.
27-27: Importing useI18n for localized UI content.
Explicitly importing and declaring useI18n ensures the component can call t() for dynamic translations.
34-35: Destructuring the translation function.
Using const { t } = useI18n(); is a neat approach for concise references to t in the template and script.
refarch-frontend/vite.config.ts (2)
5-5: vue-i18n plugin addition looks good.
Integrating the @intlify/unplugin-vue-i18n/vite plugin is consistent with the project's i18n strategy and appears correctly imported.
36-38: Expand testing of locale files.
The plugin’s include pattern restricts transformations to ./src/locales/**. Ensure that newly added or future locale files are placed in the same location so they are included properly. If there is a possibility of storing locale files in other directories, consider adjusting the pattern accordingly.
refarch-frontend/eslint.config.js (4)
2-2: vueI18n plugin import confirmed.
The import is aligned with the plugin usage below, ensuring the lint rules are properly integrated.
15-15: Included recommended i18n config is appropriate.
Bringing in the plugin’s recommended flat configuration enforces good i18n practices by default.
28-40: i18n-specific rules appear well configured.
You’re enforcing naming conventions (camelCase) and preventing unused or duplicate keys. Keeping no-raw-text at “warn” is a balanced approach, allowing devs to override it if desired. Overall, this fosters consistent i18n usage.
41-45: Localization settings are comprehensive.
Defining localeDir and messageSyntaxVersion ensures consistent checking and syntax requirements for your YAML-based translations. This is a solid practice to keep your i18n structure maintainable.
refarch-frontend/src/App.vue (3)
13-15: Localized app name updates.
Replacing hardcoded text with translated keys is a key i18n best practice. The dynamic usage of t("app.name.partX") streamlines future language expansion.
61-63: Navigation link translation.
Good job externalizing strings for the “Get started” navigation text. This ensures it can be easily translated or modified later without touching component logic.
84-84: useI18n import & usage well-structured.
Destructuring t for template interpolation is a standard, clean approach. Continuing this pattern across components will maintain consistency.
Also applies to: 111-111
refarch-frontend/tsconfig.app.json (1)
13-13: Extended type definitions for i18n.
Including "@intlify/unplugin-vue-i18n/messages" in compilerOptions.types ensures improved type checking and eliminates potential type errors when accessing messages via vue-i18n.
refarch-frontend/package.json (1)
18-18: Verify vue-i18n related package versions
Let's verify if these are the latest stable versions and check for any security advisories.
Also applies to: 23-23, 28-28
✅ Verification successful
✅ All vue-i18n related packages are using latest versions with no known vulnerabilities
The verification shows that all packages are using their latest stable versions:
- @intlify/unplugin-vue-i18n@6.0.3 (latest: 6.0.3)
- vue-i18n@11.0.1 (latest: 11.0.1)
- @intlify/eslint-plugin-vue-i18n@3.2.0 (latest: 3.2.0)
While there are known vulnerabilities in older versions of vue-i18n (9.x and 10.x), the version being used (11.0.1) is not affected. No vulnerabilities were found for the other two packages.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check latest versions and security advisories for vue-i18n packages
echo "Checking latest versions from npm registry..."
for pkg in "@intlify/unplugin-vue-i18n" "vue-i18n" "@intlify/eslint-plugin-vue-i18n"; do
echo "Package: $pkg"
curl -s "https://registry.npmjs.org/$pkg" | jq -r '.["dist-tags"].latest'
done
# Check for known vulnerabilities
echo "Checking for vulnerabilities..."
for pkg in "@intlify/unplugin-vue-i18n" "vue-i18n" "@intlify/eslint-plugin-vue-i18n"; do
gh api graphql -f query="
query {
securityVulnerabilities(first: 5, ecosystem: NPM, package: \"$pkg\") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
}
}
}"
done
Length of output: 3043
refarch-frontend/src/locales/de.yaml (2)
28-44: LGTM! Comprehensive view translations with proper escaping.
The view translations are well-structured and properly handle special characters (e.g., it{'@'}M). The navigation and documentation sections are complete.
14-20: Verify the linked message concatenation
The app name concatenation using @: syntax looks correct, but please verify the rendering in the UI to ensure no unwanted spaces are introduced.
✅ Verification successful
No unwanted spaces in app name concatenation
Based on the App.vue implementation, the app name is not using the concatenated app.name.full key, but rather renders each part separately with proper styling:
<span class="text-white">{{ t("app.name.part1") }}</span>
<span class="text-secondary">{{ t("app.name.part2") }}</span>
<span class="text-white">{{ t("app.name.part3") }}</span>This approach actually provides better control over styling and spacing than using the concatenated version, ensuring no unwanted spaces are introduced. The concatenated key app.name.full appears to be unused in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of the concatenated app name
echo "Checking usage of app.name.full..."
rg -l "t\(['\"]app\.name\.full['\"]" src/
Length of output: 171
Script:
#!/bin/bash
# Search for usage of the concatenated app name with corrected path
echo "Checking usage of app.name.full..."
rg -l "t\(['\"]app\.name\.full['\"]" refarch-frontend/src/
# Also search for other potential translation usages
echo -e "\nChecking other translation patterns..."
rg -l "useTranslation|t\(['\"]app\.name" refarch-frontend/src/
# Check content of any component files that might use the app name
echo -e "\nChecking content of potential component files..."
fd -e tsx -e jsx -e ts -e js . refarch-frontend/src/ --exec cat {}
Length of output: 15801
Script:
#!/bin/bash
# Let's check the App.vue file specifically since it was found in the translation pattern search
echo "Checking App.vue content..."
cat refarch-frontend/src/App.vue
# Also check for any vue files that might use the app name
echo -e "\nChecking vue files for app name usage..."
rg -l "app\.name" refarch-frontend/src/ --type vue
Length of output: 4367
refarch-frontend/src/components/common/YesNoDialog.vue (4)
41-41: Good use of translation keys for 'No'.
This change replaces hard-coded text with an i18n translation key, aligning with the project’s internationalization efforts. Ensure that "common.no" is defined in your translation files (e.g., de.yaml).
48-48: Good use of translation keys for 'Yes'.
As with "common.no", confirm that "common.yes" is appropriately translated in all supported locales.
56-56: Import statement for useI18n looks good.
This is required to access t for translations. Make sure this import is consistently used throughout the codebase wherever translations are needed.
68-69: Well-structured usage of the i18n composition API.
Destructuring t from useI18n() is a clean approach, keeping translation calls concise. Continue to maintain the convention of referencing t("namespace.key") for clarity.
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
refarch-frontend/src/locales/README.md(1 hunks)refarch-frontend/vite.config.ts(2 hunks)
🧰 Additional context used
🪛 Markdownlint (0.37.0)
refarch-frontend/src/locales/README.md
16-16: null
Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
30-30: null
Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
33-33: null
Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
60-60: null
Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (4)
refarch-frontend/vite.config.ts (3)
2-2: LGTM! Using recommended node: protocol.
The import statement correctly uses the node: protocol for Node.js builtin modules.
5-5: LGTM! Vue I18n plugin import.
The plugin import is correctly placed with other Vite plugins.
36-38: LGTM! Verify locale files path.
The Vue I18n plugin configuration looks good. The path resolution is correct and the glob pattern will support multiple locale files.
Let's verify the locale files setup:
✅ Verification successful
Locale files setup is correctly configured and functional
The verification confirms that:
- The locales directory exists at the correct path:
refarch-frontend/src/locales/ - The German translation file
de.yamlis present and contains valid YAML structure - The path resolution in the Vue I18n plugin configuration correctly matches the actual file structure
The locale setup follows i18n best practices with:
- Well-organized translation keys in hierarchical structure
- Support for nested keys and interpolation
- Documentation (README.md) present in the locales directory
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the locale files structure and content
# Check if the locales directory exists and contains yaml files
fd -e yaml . src/locales
# Verify the German translation file exists and is valid YAML
if [ -f "src/locales/de.yaml" ]; then
echo "German translation file exists"
# Basic YAML validation (will error if invalid)
cat src/locales/de.yaml | yq eval '.' - >/dev/null
fi
Length of output: 158
Script:
#!/bin/bash
# Let's check if the locales directory exists anywhere in the repository
fd locales
# Also search for any YAML files that might contain translations
fd -e yaml -e yml
# Let's also check the content of the vite.config.ts to see the full context
cat refarch-frontend/vite.config.ts
Length of output: 1960
Script:
#!/bin/bash
# Let's check the content of the German translation file
cat refarch-frontend/src/locales/de.yaml
# List all files in the locales directory to ensure we're not missing any
ls -la refarch-frontend/src/locales/
Length of output: 1616
refarch-frontend/src/locales/README.md (1)
1-73: Documentation provides comprehensive guidance for i18n implementation.
The README effectively communicates the translation management strategy, aligning perfectly with the PR objectives of integrating vue-i18n. The hierarchical organization, naming conventions, and best practices will help maintain consistency across the project.
🧰 Tools
🪛 Markdownlint (0.37.0)
16-16: null
Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
30-30: null
Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
33-33: null
Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
60-60: null
Fenced code blocks should have a language specified
(MD040, fenced-code-language)
Description
Adds vue-i18n plugin to allow centralized text definition and enable i18n if needed.
I only added a german translation (
src/locales/de.yaml) as the static texts were already german. So it's up to the application developers to add additional translation files (when they are needed).Some conventions are enforced by
eslint-plugin-vue-i18n:camelCasefor message keysIf application developers don't want to use vue-i18n for centralizing text definitions (like mentioned by @darenegade in #116 ) they are still not forced to do so. By setting the eslint rule
@intlify/vue-i18n/no-raw-texttooffthey also can remove lint warnings if they choose to include raw text in components or views.Reference
Issues #116
Summary by CodeRabbit
New Features
Chores
Documentation