Folo icon indicating copy to clipboard operation
Folo copied to clipboard

WIP: Translation

Open djyde opened this issue 1 year ago • 21 comments

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 avatar Sep 11 '24 14:09 djyde

@djyde is attempting to deploy a commit to the RSS3 Team on Vercel.

A member of the Team first needs to authorize it.

vercel[bot] avatar Sep 11 '24 14:09 vercel[bot]

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

vercel[bot] avatar Sep 11 '24 16:09 vercel[bot]

@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.

Innei avatar Sep 12 '24 04:09 Innei

@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 avatar Sep 12 '24 05:09 djyde

@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

Innei avatar Sep 12 '24 05:09 Innei

@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 avatar Sep 12 '24 06:09 djyde

@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.

Innei avatar Sep 12 '24 07:09 Innei

If you agree with this, I would move the root resource to namespaces/app

Innei avatar Sep 12 '24 07:09 Innei

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.

Innei avatar Sep 12 '24 07:09 Innei

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 avatar Sep 12 '24 07:09 djyde

@djyde I've refactored it and resolved the code conflicts

Innei avatar Sep 12 '24 08:09 Innei

@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.

Innei avatar Sep 12 '24 09:09 Innei

It seems that it breaks https://github.com/lokalise/i18n-ally/ preview feature.

djyde avatar Sep 12 '24 09:09 djyde

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

Innei avatar Sep 12 '24 09:09 Innei

maybe we should refactor the locales structure to /locales/en/app.json, /locales/en/common.json

djyde avatar Sep 12 '24 09:09 djyde

But, this file structure is supported.

CleanShot 2024-09-12 at 5  25 57@2x

https://github.com/lokalise/i18n-ally/wiki/Path-Matcher

I don't know why it not work.

Innei avatar Sep 12 '24 09:09 Innei

Resolved conflicts again.

Innei avatar Sep 12 '24 12:09 Innei

@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.

CleanShot 2024-09-12 at 21 54 27@2x

Seems --fix not work

djyde avatar Sep 12 '24 13:09 djyde

For this rule, you may need to fix it multiple times.

hyoban avatar Sep 12 '24 14:09 hyoban

Resolved conflicts again.

Innei avatar Sep 12 '24 14:09 Innei

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.

dorival avatar Sep 12 '24 20:09 dorival

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.

Innei avatar Sep 13 '24 03:09 Innei

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.

djyde avatar Sep 13 '24 04:09 djyde

@dorival @Innei I've made the i18n key flat

djyde avatar Sep 13 '24 05:09 djyde

@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 avatar Sep 13 '24 06:09 djyde

@djyde Can you provide the current cursor ai chat prompt? Thank you very much.

Innei avatar Sep 13 '24 08:09 Innei

@djyde Can you provide the current cursor ai chat prompt? Thank you very much.

Open the component you want to translate, then cmd+l:

CleanShot 2024-09-13 at 16 08 33@2x

Notice that you need to at(@) the correct locale file

djyde avatar Sep 13 '24 08:09 djyde

I've merged it first, I'll continue translating it later

Innei avatar Sep 13 '24 10:09 Innei

Have all the content been translated?

evanzme avatar Sep 16 '24 12:09 evanzme