WIP: Translation
The goal of this PR is to try to translate 100% into Chinese. I speparate different part to track the progress:
-
[ ] Settings
- [x] General panel
- [x] Appearance panel
- [x] Actions panel
- [x] Integrations panel
- [x] Profile panel
- [x] Shortcusts panel
- [ ] Wallet panel
- [x] Invitations panel
- [x] About panel
-
[ ] Sidebar
- [x] words
- [x] context menu
- [ ] Edit feed
-
[x] Articles list
- [x] words
- [x] context menu
-
[x] Entry content
@djyde is attempting to deploy a commit to the RSS3 Team on Vercel.
A member of the Team first needs to authorize it.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| follow | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Sep 13, 2024 7:54am |
@djyde
Thanks for the contribution.
One thing though, we need to split multiple namespaces to make the i18n module more maintainable.
For example
namespace - common is used to store common nouns verbs etc. namespace - lang can be used to store language nouns. Other things like setting can also be split into one namespace.
We don't want to manage all the i18n modules in a single file, as the file will be bloated and difficult to maintain.
@djyde
Thanks for the contribution.
One thing though, we need to split multiple namespaces to make the i18n module more maintainable.
For example
namespace - common is used to store common nouns verbs etc. namespace - lang can be used to store language nouns. Other things like setting can also be split into one namespace.
We don't want to manage all the i18n modules in a single file, as the file will be bloated and difficult to maintain.
I recommend maintain in one single file. Do you have some open source project example that I can learn how to maintain in seperate namespace?
@djyde Thanks for the contribution. One thing though, we need to split multiple namespaces to make the i18n module more maintainable. For example namespace - common is used to store common nouns verbs etc. namespace - lang can be used to store language nouns. Other things like setting can also be split into one namespace. We don't want to manage all the i18n modules in a single file, as the file will be bloated and difficult to maintain.
I recommend maintain in one single file. Do you have some open source project example that I can learn how to maintain in seperate namespace?
Maybe vscode-loc?
https://github.com/microsoft/vscode-loc/blob/main/i18n/vscode-language-pack-cs/translations/extensions/ms-vscode.js-debug.i18n.json
@djyde Thanks for the contribution. One thing though, we need to split multiple namespaces to make the i18n module more maintainable. For example namespace - common is used to store common nouns verbs etc. namespace - lang can be used to store language nouns. Other things like setting can also be split into one namespace. We don't want to manage all the i18n modules in a single file, as the file will be bloated and difficult to maintain.
I recommend maintain in one single file. Do you have some open source project example that I can learn how to maintain in seperate namespace?
Maybe vscode-loc?
https://github.com/microsoft/vscode-loc/blob/main/i18n/vscode-language-pack-cs/translations/extensions/ms-vscode.js-debug.i18n.json
Well. I still don't think it's a good practice. Separating to different files only increases maintainance cost. For example, I just need to translate one single file to get 100% trasnlation for the whole app to another language.
And if translations locate on different namespace, you always need to consider which namespace you should use with useTranslation(). Maybe sometime you need to even use more than one useTranslation() in a single component.
@djyde
For translation contributors or maintainers, it is indeed better to write all translations in the same file.
But imagine if a json has thousands of lines and there are many nested modules, and each developer maintains a different module. In the subsequent development, it is easy to have redundancy and code conflicts.
Or, the subsequent module deletion also becomes difficult.
Though I do agree with you very much.
But we need to break down into at least the following necessary namespaces:
- common - common translation resource
- app - used only in app
- external - only used in external pages
- lang provides translations for languages, e.g. original Name and names in the current language.
If you agree with this, I would move the root resource to namespaces/app
Also, for the sake of app loading speed, we don't load all the language resources. But by splitting the namespaces, we load the common resource for all languages, but not the others.
We only load the language-specific resource when necessary.
If you agree with this, I would move the root resource to namespaces/app
Sure. I will finish the rest of translation after your refactoring
@djyde I've refactored it and resolved the code conflicts
@djyde And, we added the eslint rule to ensure that the order of each json is sortable. Fixed a bug in hmr where it would automatically switch back to default English.
After the translation is complete, we then do an overall Lint to sort them.
It seems that it breaks https://github.com/lokalise/i18n-ally/ preview feature.
It seems that it breaks lokalise/i18n-ally preview feature.
Which feature? I can't use i18n-ally, the namespace breaks them. This is a known issue.
https://github.com/lokalise/i18n-ally/issues/1201
maybe we should refactor the locales structure to /locales/en/app.json, /locales/en/common.json
But, this file structure is supported.
https://github.com/lokalise/i18n-ally/wiki/Path-Matcher
I don't know why it not work.
Resolved conflicts again.
@djyde And, we added the eslint rule to ensure that the order of each json is sortable. Fixed a bug in hmr where it would automatically switch back to default English.
After the translation is complete, we then do an overall Lint to sort them.
Seems --fix not work
For this rule, you may need to fix it multiple times.
Resolved conflicts again.
I often stay on the silent crowd when looking at FOSS, but since this one is in the early stages, may I float a suggestion of using flat structures for i18n, such as settings.titles.about instead of hiearchy JSON?
It can still be a JSON, but no sub-keys.
The translation file will look bigger with more repetitions on the key names, but it's easy to select-and-find the translations when dealing with them down the road, as the app grows. Curious to know what is the maintainers opinion on that. I've been dealing with i18n in a big banking app where I work, and we switched to this flat structure after bugs start appearing.
Understand what you're saying. For example, in xcode projects also use flat key-value pairs, and the famous open source project AFFiNE is similar.
https://github.com/toeverything/AFFiNE/blob/4ac9bd7790eeea7e0660861432caa17a0337bd26/packages/frontend/i18n/src/resources/en-US.json
@djyde I'd like to hear what your advice is.
Understand what you're saying. For example, in xcode projects also use flat key-value pairs, and the famous open source project AFFiNE is similar.
https://github.com/toeverything/AFFiNE/blob/4ac9bd7790eeea7e0660861432caa17a0337bd26/packages/frontend/i18n/src/resources/en-US.json
@djyde I'd like to hear what your advice is.
I think flat key is fine.
@dorival @Innei I've made the i18n key flat
@Innei Now all the translation is done except the "Wallet" setting panel (I don't have dev api server to test this page).
When the Wallet panel is done, I think we can rollout this PR
@djyde Can you provide the current cursor ai chat prompt? Thank you very much.
@djyde Can you provide the current cursor ai chat prompt? Thank you very much.
Open the component you want to translate, then cmd+l:
Notice that you need to at(@) the correct locale file
I've merged it first, I'll continue translating it later
Have all the content been translated?