fix: internationalization-related modifications, temporarily hide the entry point #3597
Conversation
WalkthroughThe changes introduce full support for two additional languages—Latin American Spanish (es-LA) and Brazilian Portuguese (pt-BR)—across the example site and locale packages. This includes new locale files, expanded language constants, updated routing and initialization logic, and enhancements to language selection and detection mechanisms throughout the codebase. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant App
participant LocaleDetector
participant i18n
participant Router
User->>App: Accesses site (URL may contain /zh-CN, /en-US, /es-LA, /pt-BR)
App->>LocaleDetector: Call getLocaleMode()
LocaleDetector->>App: Returns detected language (zhCN, enUS, esLA, ptBR)
App->>i18n: Initialize with detected language
App->>Router: Set up routes with LANG_PATH_MAP[detected language]
User->>App: Interacts with language switcher
App->>LocaleDetector: Update language and reload as needed
App->>i18n: Use getWord(cn, en, es, pt) for UI text
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
examples/sites/src/tools/appData.jsOops! Something went wrong! :( ESLint: 8.57.1 ESLint couldn't find the plugin "eslint-plugin-vue". (The package "eslint-plugin-vue" was not found when loaded as a Node module from the directory "".) It's likely that the plugin isn't installed correctly. Try reinstalling by running the following: The plugin "eslint-plugin-vue" was referenced from the config file in ".eslintrc.js » @antfu/eslint-config » @antfu/eslint-config-vue". If you still can't figure out the problem, please stop by https://eslint.org/chat/help to chat with the team. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
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: 2
🧹 Nitpick comments (3)
examples/sites/src/tools/utils.js (1)
107-117: Simplify URL checking logic and improve performanceThe function works correctly but has redundant URL checks and could be optimized.
Consider this more efficient implementation:
const getLocaleMode = () => { - const zhPath = LANG_PATH_MAP[ZH_CN_LANG] - const enPath = LANG_PATH_MAP[EN_US_LANG] - const esPath = LANG_PATH_MAP[ES_LA_LANG] - const ptPath = LANG_PATH_MAP[PT_BR_LANG] - const isZhCn = location.href.includes(`/${zhPath}`) || location.pathname.includes(`/${zhPath}/`) - const isEnUs = location.href.includes(`/${enPath}`) || location.pathname.includes(`/${enPath}/`) - const isEsLa = location.href.includes(`/${esPath}`) || location.pathname.includes(`/${esPath}/`) - const isPtBr = location.href.includes(`/${ptPath}`) || location.pathname.includes(`/${ptPath}/`) - return isEnUs ? EN_US_LANG : isZhCn ? ZH_CN_LANG : isEsLa ? ES_LA_LANG : isPtBr ? PT_BR_LANG : ZH_CN_LANG + const pathname = location.pathname + + for (const [lang, path] of Object.entries(LANG_PATH_MAP)) { + if (pathname.includes(`/${path}/`) || pathname.includes(`/${path}`)) { + return lang + } + } + + return ZH_CN_LANG }Benefits:
- Single pathname check instead of both href and pathname
- More maintainable when adding new languages
- Clearer logic flow
examples/sites/src/main.js (1)
69-82: Consider using getLocaleMode consistently throughoutThe logic correctly extends language detection to the new locales, but there's duplication between the local URL checking and the imported
getLocaleMode()function.Consider simplifying by using
getLocaleMode()consistently:-const zhPath = LANG_PATH_MAP[ZH_CN_LANG] -const enPath = LANG_PATH_MAP[EN_US_LANG] -const esPath = LANG_PATH_MAP[ES_LA_LANG] -const ptPath = LANG_PATH_MAP[PT_BR_LANG] -const isZhCn = location.href.includes(`/${zhPath}`) -const isEnUs = location.href.includes(`/${enPath}`) -const isEsLa = location.href.includes(`/${esPath}`) -const isPtBr = location.href.includes(`/${ptPath}`) -const notMatchLang = - (isZhCn && appData.lang !== ZH_CN_LANG) || - (isEnUs && appData.lang !== EN_US_LANG) || - (isEsLa && appData.lang !== ES_LA_LANG) || - (isPtBr && appData.lang !== PT_BR_LANG) -if (notMatchLang) { - appData.lang = getLocaleMode() +const detectedLang = getLocaleMode() +if (appData.lang !== detectedLang) { + appData.lang = detectedLang i18n.global.locale = appData.lang }This reduces code duplication and ensures consistent locale detection logic.
examples/sites/src/i18n/index.js (1)
11-18: Consider simplifying the language validation logic.The current implementation works correctly but can be optimized. Since the Map is just mapping keys to themselves, consider using a Set for better readability and performance.
-const langMap = new Map([ - ['zhCN', 'zhCN'], - ['enUS', 'enUS'], - ['esLA', 'esLA'], - ['ptBR', 'ptBR'] -]) - -$local._lang = langMap.get($local._lang) || 'zhCN' +const supportedLocales = new Set(['zhCN', 'enUS', 'esLA', 'ptBR']) + +$local._lang = supportedLocales.has($local._lang) ? $local._lang : 'zhCN'
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (21)
examples/sites/src/components/demo.vue(1 hunks)examples/sites/src/const.ts(1 hunks)examples/sites/src/i18n/en.json(1 hunks)examples/sites/src/i18n/es.json(1 hunks)examples/sites/src/i18n/index.js(2 hunks)examples/sites/src/i18n/pt.json(1 hunks)examples/sites/src/i18n/zh.json(1 hunks)examples/sites/src/main.js(3 hunks)examples/sites/src/router.js(3 hunks)examples/sites/src/tools/appData.js(2 hunks)examples/sites/src/tools/storage.js(2 hunks)examples/sites/src/tools/useApiMode.js(1 hunks)examples/sites/src/tools/useStyleSettings.js(1 hunks)examples/sites/src/tools/utils.js(2 hunks)examples/sites/src/views/components-doc/common.vue(2 hunks)examples/sites/src/views/layout/layout.vue(1 hunks)examples/sites/src/views/overview.vue(1 hunks)packages/vue-locale/src/vue2.7/index.ts(4 hunks)packages/vue-locale/src/vue2/index.ts(4 hunks)packages/vue-locale/src/vue3/index.ts(4 hunks)packages/vue/package.json(1 hunks)
🧰 Additional context used
🧠 Learnings (6)
examples/sites/src/tools/useApiMode.js (2)
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-histogram/src/chart-histogram.vue:33-36
Timestamp: 2024-11-25T03:43:05.285Z
Learning: 在 Tiny Vue 代码库中，使用 `chart-core` 中的 `huiChartOption` 的组件，不应在其 `data` 中定义 `huiChartOption` 或 `option`，而是应该依赖 `chart-core` 提供的 `huiChartOption`。
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-heatmap/src/chart-heatmap.vue:38-40
Timestamp: 2024-11-25T03:43:19.322Z
Learning: 在 Vue.js 组件（如 `chart-heatmap.vue`）中，使用来自 `chart-core` 的 `huiChartOption` 来管理图表选项，不要在 `data()` 中声明 `option`。
examples/sites/src/i18n/es.json (1)
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-histogram/src/chart-histogram.vue:33-36
Timestamp: 2024-11-25T03:43:05.285Z
Learning: 在 Tiny Vue 代码库中，使用 `chart-core` 中的 `huiChartOption` 的组件，不应在其 `data` 中定义 `huiChartOption` 或 `option`，而是应该依赖 `chart-core` 提供的 `huiChartOption`。
examples/sites/src/router.js (2)
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-histogram/src/chart-histogram.vue:33-36
Timestamp: 2024-11-25T03:43:05.285Z
Learning: 在 Tiny Vue 代码库中，使用 `chart-core` 中的 `huiChartOption` 的组件，不应在其 `data` 中定义 `huiChartOption` 或 `option`，而是应该依赖 `chart-core` 提供的 `huiChartOption`。
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-sunburst/src/chart-sunburst.vue:30-32
Timestamp: 2024-11-25T03:24:05.740Z
Learning: 在位于`packages/vue/src/huicharts/huicharts-sunburst/src/chart-sunburst.vue`的组件中，当使用`chart-core`时，应删除错误的`option`定义，使用`chart-core`中的`huiChartOption`。
examples/sites/src/i18n/pt.json (1)
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-histogram/src/chart-histogram.vue:33-36
Timestamp: 2024-11-25T03:43:05.285Z
Learning: 在 Tiny Vue 代码库中，使用 `chart-core` 中的 `huiChartOption` 的组件，不应在其 `data` 中定义 `huiChartOption` 或 `option`，而是应该依赖 `chart-core` 提供的 `huiChartOption`。
examples/sites/src/tools/appData.js (2)
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-heatmap/src/chart-heatmap.vue:38-40
Timestamp: 2024-11-25T03:43:19.322Z
Learning: 在 Vue.js 组件（如 `chart-heatmap.vue`）中，使用来自 `chart-core` 的 `huiChartOption` 来管理图表选项，不要在 `data()` 中声明 `option`。
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-histogram/src/chart-histogram.vue:33-36
Timestamp: 2024-11-25T03:43:05.285Z
Learning: 在 Tiny Vue 代码库中，使用 `chart-core` 中的 `huiChartOption` 的组件，不应在其 `data` 中定义 `huiChartOption` 或 `option`，而是应该依赖 `chart-core` 提供的 `huiChartOption`。
packages/vue-locale/src/vue2/index.ts (2)
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-histogram/src/chart-histogram.vue:33-36
Timestamp: 2024-11-25T03:43:05.285Z
Learning: 在 Tiny Vue 代码库中，使用 `chart-core` 中的 `huiChartOption` 的组件，不应在其 `data` 中定义 `huiChartOption` 或 `option`，而是应该依赖 `chart-core` 提供的 `huiChartOption`。
Learnt from: Davont
PR: opentiny/tiny-vue#2513
File: packages/vue/src/huicharts/huicharts-sunburst/src/chart-sunburst.vue:30-32
Timestamp: 2024-11-25T03:24:05.740Z
Learning: 在位于`packages/vue/src/huicharts/huicharts-sunburst/src/chart-sunburst.vue`的组件中，当使用`chart-core`时，应删除错误的`option`定义，使用`chart-core`中的`huiChartOption`。
🧬 Code Graph Analysis (5)
examples/sites/src/tools/useApiMode.js (1)
examples/sites/src/tools/appData.js (1)
appData(6-10)
examples/sites/src/tools/utils.js (3)
examples/sites/src/main.js (8)
zhPath(67-67)enPath(68-68)esPath(69-69)ptPath(70-70)isZhCn(71-71)isEnUs(72-72)isEsLa(73-73)isPtBr(74-74)examples/sites/src/const.ts (5)
LANG_PATH_MAP(12-17)ZH_CN_LANG(6-6)EN_US_LANG(7-7)ES_LA_LANG(8-8)PT_BR_LANG(9-9)examples/sites/src/tools/appData.js (1)
isZhCn(11-11)
examples/sites/src/router.js (2)
examples/sites/src/const.ts (2)
LANG_PATH_MAP(12-17)ZH_CN_LANG(6-6)examples/sites/src/tools/appData.js (1)
appData(6-10)
examples/sites/src/tools/storage.js (1)
examples/sites/src/tools/utils.js (1)
getLocaleMode(107-117)
examples/sites/src/i18n/index.js (4)
packages/vue-locale/src/vue2/index.ts (3)
esLA(91-91)ptBR(91-91)i18n(53-57)packages/vue-locale/src/vue3/index.ts (3)
esLA(88-88)ptBR(88-88)i18n(40-43)examples/sites/src/tools/storage.js (1)
$local(44-44)examples/sites/src/composable/utils.ts (1)
$local(8-8)
🔇 Additional comments (35)
packages/vue/package.json (1)
240-240: Minor formatting cleanup unrelated to PR objectives.This change removes a trailing newline, which is good for consistent formatting, but it's unrelated to the internationalization modifications mentioned in the PR title.
examples/sites/src/i18n/en.json (1)
4-5: LGTM! Proper language entries added for new locales.The additions correctly follow the existing pattern and use proper locale identifiers ("es-la" for Latin American Spanish, "pt-br" for Brazilian Portuguese) with appropriate English display names.
examples/sites/src/i18n/zh.json (1)
4-5: LGTM! Correct Chinese translations for new language options.The Chinese translations "西班牙语" (Spanish) and "葡萄牙语" (Portuguese) are accurate and maintain consistency with the English localization file.
examples/sites/src/tools/useApiMode.js (2)
3-3: LGTM! Import updated to include centralized app data.Adding
appDatato the import aligns with the centralized locale management approach.
9-9: Excellent architectural improvement for multi-language support.Replacing the URL-based locale detection with
appData.langcentralizes locale management and enables support for the new languages (es-LA, pt-BR) being added in this PR. This is much more maintainable than the previous URL checking approach.examples/sites/src/tools/useStyleSettings.js (1)
19-26: Ignore locale identifier “inconsistency” here.The
valuefields use camelCase (e.g.esLA,ptBR) because they correspond to the internal Vue-locale exports (zhCN, enUS, esLA, ptBR). Thetextlookup uses kebab-case (e.g.'es-la','pt-br') to match the keys in the localization files. This is the intended design and consistent with the rest of the code.Likely an incorrect or invalid review comment.
examples/sites/src/views/layout/layout.vue (1)
99-99: LGTM! Internationalization support correctly expanded.The
getWordfunction call has been properly updated to include the new Latin American Spanish ('es-LA') and Brazilian Portuguese ('pt-BR') locales, maintaining consistency with the broader internationalization enhancements across the application.examples/sites/src/views/overview.vue (1)
124-124: LGTM! Consistent internationalization implementation.The expansion of
getWordparameters to include Spanish and Portuguese locales is correctly implemented and consistent with the pattern used across other components in this PR.examples/sites/src/views/components-doc/common.vue (2)
124-124: LGTM! Language key properly expanded for new locales.The
langKeyassignment correctly includes the full locale codes for the new Spanish and Portuguese languages, maintaining consistency with the UI-facing internationalization pattern.
285-285: LGTM! Internal language codes correctly updated.The
langvariable uses the appropriate abbreviated language codes ('es','pt') for internal processing, which is consistent with the expected format for this context.examples/sites/src/i18n/es.json (1)
1-47: LGTM! Comprehensive Spanish localization file added.The new Spanish locale file provides complete translations for all UI elements including language names, navigation, component descriptions, API preferences, and user messages. The JSON structure is correct and follows the established localization pattern.
examples/sites/src/const.ts (2)
8-9: LGTM! New language constants properly defined.The new
ES_LA_LANGandPT_BR_LANGconstants follow the established naming convention and provide the foundation for Latin American Spanish and Brazilian Portuguese locale support.
15-16: LGTM! Language path mappings correctly extended.The
LANG_PATH_MAPupdates properly map the new language constants to their corresponding URL path segments ('es-LA'and'pt-BR'), maintaining consistency with the existing mapping pattern.examples/sites/src/components/demo.vue (1)
126-126: LGTM! Correctly expanded language support.The
getWordfunction call has been properly updated to include the two new language locales ('es-LA', 'pt-BR') alongside the existing ones, maintaining consistency with the internationalization enhancement.examples/sites/src/tools/appData.js (2)
4-4: Good cleanup of unused import.Removing the unused
EN_US_LANGconstant improves code maintainability.
17-19: Improved language switching logic.The updated
toggleLangmethod now properly supports dynamic language switching by settingappData.langto the requested language and usinghistory.replaceState+location.reload(). This is a significant improvement over the previous hardcoded approach and enables proper support for the new es-LA and pt-BR locales.examples/sites/src/router.js (2)
45-45: Improved redirect logic for internationalization.The redirect logic now correctly uses the current application language from
appData.langwith appropriate fallback to Chinese, supporting the expanded language set.
15-15: Static routes are re‐evaluated on language toggleThe
appData.toggleLangmethod replaces the URL segment viahistory.replaceStateand then callslocation.reload(). This full-page reload causes your router definitions (which useLANG_PATH_MAP[appData.lang] || 'zh-CN') to reinitialize with the new language. No additional runtimerouter.pushor route reconfiguration is needed.packages/vue-locale/src/vue2.7/index.ts (2)
53-53: Correctly integrated new locales throughout the module.The new locales (esLA, ptBR) are properly added to the internal lang object, named exports, and default export, maintaining consistency with the existing locale integration pattern.
Also applies to: 78-78, 89-91
3-4: Locale files confirmed to existThe locale files
es-LA.tsandpt-BR.tswere found inpackages/vue-locale/src/lang/. No further action is needed—new locale support is ready for merge.examples/sites/src/i18n/pt.json (1)
1-47: Comprehensive Portuguese localization file.The Brazilian Portuguese localization file is well-structured and comprehensive, covering all essential UI elements including language selection, themes, navigation, API documentation, and demo functionality. The translations appear appropriate for a component library documentation site.
Note: Language labels (lines 2-5) are in English rather than Portuguese, which appears to be consistent with the internationalization pattern used across locales.
examples/sites/src/tools/utils.js (2)
3-3: Import statement looks goodThe import correctly brings in the new language constants and path mapping needed for locale detection.
119-119: Export statement correctly includes the new functionThe export properly exposes
getLocaleModefor use in other modules.examples/sites/src/main.js (2)
23-23: Import additions look correctThe new language constants are properly imported and align with the i18n enhancements.
34-34: Good addition of locale utility functionImporting
getLocaleModeprovides consistent locale detection across the application.packages/vue-locale/src/vue2/index.ts (4)
4-5: Import statements for new locales are correctThe imports properly follow the established pattern for locale modules.
67-67: Locale integration in initI18n function is properThe new locales are correctly added to the lang object alongside existing ones.
91-91: Named exports properly include new localesThe export statement correctly exposes the new locale modules.
102-104: Default export object updated consistentlyThe new locales are properly added to the default export, maintaining consistency with the API.
packages/vue-locale/src/vue3/index.ts (4)
3-4: Import statements follow established patternThe new locale imports are correctly structured and consistent with the Vue 2 implementation.
63-63: Locale object properly extendedThe lang object correctly includes the new locales alongside existing ones in the initI18n function.
88-88: Named exports are completeThe export statement properly includes all four supported locales.
99-101: Default export maintains consistencyThe default export object is properly updated to include the new locales, ensuring API consistency across Vue versions.
examples/sites/src/i18n/index.js (2)
9-9: LGTM! Consistent expansion of messages object.The addition of new locales to the messages object follows the existing pattern correctly using spread operators.
6-7: Locale file imports validated
- examples/sites/src/i18n/es.json exists
- examples/sites/src/i18n/pt.json exists
The import statements for
esLAandptBRare correct and the corresponding locale files are present. No further action required.
| const getWord = (cn, en, es, pt) => { | ||
| const localeMap = new Map([ | ||
| ['zhCN', cn], // 简体中文 | ||
| ['enUS', en], // 英语 | ||
| ['esLA', es], // 西班牙语 | ||
| ['ptBR', pt] // 葡萄牙语 | ||
| ]) | ||
| const currentLocale = i18n.global.locale | ||
|
|
||
| return localeMap.get(currentLocale) ?? cn | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Address breaking change and improve parameter handling.
The expanded getWord function introduces a breaking change by requiring 4 parameters instead of 2. Consider making the new parameters optional for backward compatibility.
-const getWord = (cn, en, es, pt) => {
+const getWord = (cn, en, es = cn, pt = cn) => {
const localeMap = new Map([
['zhCN', cn], // 简体中文
['enUS', en], // 英语
['esLA', es], // 西班牙语
['ptBR', pt] // 葡萄牙语
])
const currentLocale = i18n.global.locale
return localeMap.get(currentLocale) ?? cn
}🏁 Script executed:
#!/bin/bash
# Description: Check all usages of getWord function to ensure they're updated for the new signature
# Expected: All calls should either use 4 parameters or be updated accordingly
rg -A 3 -B 1 "getWord\(" examples/sites/src/Length of output: 3818
🏁 Script executed:
#!/bin/bash
# Display the i18n setup to verify how locale is exposed
sed -n '1,200p' examples/sites/src/i18n/index.jsLength of output: 1238
Address backward compatibility for getWord parameters
The expanded getWord(cn, en, es, pt) signature breaks existing two-argument calls. Maintain compatibility by providing defaults for Spanish and Portuguese:
-const getWord = (cn, en, es, pt) => {
+const getWord = (cn, en, es = cn, pt = cn) => {No changes are needed for i18n.global.locale—it’s a plain string in legacy mode. Please update or verify these two-arg usages remain correct:
- examples/sites/src/views/overview.vue:
getWord(menu.label, menu.labelEn) - examples/sites/src/views/docs/docs.vue:
getWord('', '-en') - examples/sites/src/components/version-tip.vue:
•getWord(props.tip['zh-CN'], props.tip['en-US'])
•getWord(znChTip, enUsTip)
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const getWord = (cn, en, es, pt) => { | |
| const localeMap = new Map([ | |
| ['zhCN', cn], // 简体中文 | |
| ['enUS', en], // 英语 | |
| ['esLA', es], // 西班牙语 | |
| ['ptBR', pt] // 葡萄牙语 | |
| ]) | |
| const currentLocale = i18n.global.locale | |
| return localeMap.get(currentLocale) ?? cn | |
| } | |
| const getWord = (cn, en, es = cn, pt = cn) => { | |
| const localeMap = new Map([ | |
| ['zhCN', cn], // 简体中文 | |
| ['enUS', en], // 英语 | |
| ['esLA', es], // 西班牙语 | |
| ['ptBR', pt] // 葡萄牙语 | |
| ]) | |
| const currentLocale = i18n.global.locale | |
| return localeMap.get(currentLocale) ?? cn | |
| } |
🤖 Prompt for AI Agents
In examples/sites/src/i18n/index.js around lines 35 to 45, the getWord function
now requires four parameters, which breaks existing calls with only two
arguments. To fix this, update the function signature to provide default values
for the Spanish and Portuguese parameters (es and pt) so that two-argument calls
remain valid. This ensures backward compatibility without changing the logic for
i18n.global.locale usage.
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
国际化相关修改，暂时隐藏入口
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit
New Features
Documentation
Refactor