Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internationalization #64

Closed
2 of 4 tasks
molant opened this issue Jul 8, 2021 · 1 comment · Fixed by #112
Closed
2 of 4 tasks

Internationalization #64

molant opened this issue Jul 8, 2021 · 1 comment · Fixed by #112
Assignees
Labels
✨ enhancement New feature or request

Comments

@molant
Copy link
Contributor

molant commented Jul 8, 2021

This is an outline of how we could handle the internationalization if the website based on our current experience in the main site and Docusaurus documentation.

Some considerations

  • Each language is in its own folder under i18n/. In our case it will be 7 languages (Chinese Simplified, French, German, Japanese, Portuguese, Russian, and Spanish)
  • We will have to add a code.json and navbar.json to each locale for translation so the navigation and other strings are translated.
  • We might need to use explicit ids in headings to make sure relative links still work (not sure what the current status is)
  • There is no automatic locale detection (its an static site). We could use some JavaScript or show the English site first and let the users pick their preferred one via the localeDropdown

How to?

I think the less disruptive way would be to:

  • The English language keeps being updated as it is right now
  • Make i18n pull the required files for translations (e.g.: navbar.json) build: add files from electronjs.org-new i18n#1982
  • Pull the translations from crowding using the CLI periodically and move the files to the right place (at least until the changes happen upstream)
  • Move /scripts/tasks/how-to-examples.md upstream. It will get translated but will not show up in the old docs so we should be OK.

The reason to use the Crowdin CLI instead of the i18n package is that this package is a massive JSON blob and only contains the HTML. We want the files and in the future we would like to stop maintaining it.

@molant molant added the ✨ enhancement New feature or request label Jul 8, 2021
@molant molant mentioned this issue Jul 8, 2021
23 tasks
@molant molant self-assigned this Jul 8, 2021
@erickzhao erickzhao changed the title Internazionalization Internationalization Jul 12, 2021
molant added a commit that referenced this issue Jul 13, 2021
The locale `i18n/en-US` is used by `electron/i18n` as the source to
translate content into other locales and avoid having to manually create
the different JSON files or keep them in sync.

Once those files are translated, they will be downloaded and put in
the right place for each locale. This will happen in an upcoming PR.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Rel: #64
molant added a commit to electron/i18n that referenced this issue Jul 13, 2021
There are some files in electronjs.org-new that are not part of the
markdown that need to be translated as well.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Rel: electron/website#64
molant added a commit that referenced this issue Jul 14, 2021
The locale `i18n/en-US` is used by `electron/i18n` as the source to
translate content into other locales and avoid having to manually create
the different JSON files or keep them in sync.

Once those files are translated, they will be downloaded and put in
the right place for each locale. This will happen in an upcoming PR.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Close #67
Rel: #64
erickzhao pushed a commit to electron/i18n that referenced this issue Jul 14, 2021
There are some files in electronjs.org-new that are not part of the
markdown that need to be translated as well.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Rel: electron/website#64
molant added a commit that referenced this issue Jul 14, 2021
The locale `i18n/en-US` is used by `electron/i18n` as the source to
translate content into other locales and avoid having to manually create
the different JSON files or keep them in sync.

Once those files are translated, they will be downloaded and put in
the right place for each locale. This will happen in an upcoming PR.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Close #67
Rel: #64
molant added a commit that referenced this issue Jul 14, 2021
molant added a commit that referenced this issue Jul 21, 2021
Integrate with Crowdin to download the latest translations and generate
the site for the supported locales.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Jul 21, 2021
Integrate with Crowdin to download the latest translations and generate
the site for the supported locales.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Jul 21, 2021
Integrate with Crowdin to download the latest translations and generate
the site for the supported locales.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Sep 30, 2021
Integrate with Crowdin to download the latest translations and generate
the site for the supported locales.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
@molant
Copy link
Contributor Author

molant commented Sep 30, 2021

I've been looking into fixing the build crashes in #78 and haven't been super successful 😞

I found this issue where using esbuild speeds the build process. I'm trying it locally and seems to speed it up, but I still can't build with all the languages in this PR and it takes forever (15 minutes until I get a JavaScript heap out of memory with 5/8 languages built).

My current plan to get this through the finish line is:

  • Do a separate PR with the esbuild patch: This should improve build times for everything 7e163fb
  • Commit docs
  • Stop the Crowdin syncing in electron/i18n
  • Configure Crowdin to use this repo as the source
  • Pull Crowdin changes periodically on a GitHub action
  • Build each locale independently and publish it to a different dino in Heroku, and configure Fastly to serve them as a path and not a subdomain. This is the [Hybrid approach] in Docusaurus configuration. I'm not sure if we will need to do any path transformation in Fastly or maybe specify a different path on build time. I managed to build all the website in CI. It takes about 27 min. My current plan is to migrate to a storage solution, build each language separately, and push those changes there.

molant added a commit that referenced this issue Oct 4, 2021
Integrate with Crowdin to download the latest translations and generate
the site for the supported locales.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Oct 6, 2021
molant added a commit that referenced this issue Oct 6, 2021
molant added a commit that referenced this issue Oct 7, 2021
Integrates with Crowdin to enable i18n of the site. This PR changes the
source of truth for Crowdin and moves it to this repository instead of
relying on `electron/i18n`.

Additionally it uses Crowdin's CLI to do the upload/download of assets
making it more reliable.

The website is built on locale at a time via `yarn i18n:build`.
Otherwise the process crashed with an out of memory error. The regular
`yarn build` command still compiles the `en` locale.

Because we cannot get notifications when there are new translations
avaiable, there is a GitHub workflow (`update-i18n-deploy.yml`) that
downloads the content every few minutes, builds, and deploy. To speed up
this process, the previous generated assets are download. In local tests
this reduces the build times from 250s to 40s so the whole process
should take about 5 minutes.

The previous generated content is stored in Azure Storage. Because this
is a static website it makes more sense than having a dyno and will make
it easier to:
- deploy multiple locales at the same time if we still need to speed up
  the process
- have versioned docs because we just need to "take a snapshot" and
  publish to a different folder

The current live site is still not using this storage but will soon-ish.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Oct 7, 2021
Integrates with Crowdin to enable i18n of the site. This PR changes the
source of truth for Crowdin and moves it to this repository instead of
relying on `electron/i18n`.

Additionally it uses Crowdin's CLI to do the upload/download of assets
making it more reliable.

The website is built on locale at a time via `yarn i18n:build`.
Otherwise the process crashed with an out of memory error. The regular
`yarn build` command still compiles the `en` locale.

Because we cannot get notifications when there are new translations
avaiable, there is a GitHub workflow (`update-i18n-deploy.yml`) that
downloads the content every few minutes, builds, and deploy. To speed up
this process, the previous generated assets are download. In local tests
this reduces the build times from 250s to 40s so the whole process
should take about 5 minutes.

The previous generated content is stored in Azure Storage. Because this
is a static website it makes more sense than having a dyno and will make
it easier to:
- deploy multiple locales at the same time if we still need to speed up
  the process
- have versioned docs because we just need to "take a snapshot" and
  publish to a different folder

The current live site is still not using this storage but will soon-ish.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Oct 7, 2021
Integrates with Crowdin to enable i18n of the site. This PR changes the
source of truth for Crowdin and moves it to this repository instead of
relying on `electron/i18n`.

Additionally it uses Crowdin's CLI to do the upload/download of assets
making it more reliable.

The website is built on locale at a time via `yarn i18n:build`.
Otherwise the process crashed with an out of memory error. The regular
`yarn build` command still compiles the `en` locale.

Because we cannot get notifications when there are new translations
avaiable, there is a GitHub workflow (`update-i18n-deploy.yml`) that
downloads the content every few minutes, builds, and deploy. To speed up
this process, the previous generated assets are download. In local tests
this reduces the build times from 250s to 40s so the whole process
should take about 5 minutes.

The previous generated content is stored in Azure Storage. Because this
is a static website it makes more sense than having a dyno and will make
it easier to:
- deploy multiple locales at the same time if we still need to speed up
  the process
- have versioned docs because we just need to "take a snapshot" and
  publish to a different folder

The current live site is still not using this storage but will soon-ish.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Oct 7, 2021
Integrates with Crowdin to enable i18n of the site. This PR changes the
source of truth for Crowdin and moves it to this repository instead of
relying on `electron/i18n`.

Additionally it uses Crowdin's CLI to do the upload/download of assets
making it more reliable.

The website is built on locale at a time via `yarn i18n:build`.
Otherwise the process crashed with an out of memory error. The regular
`yarn build` command still compiles the `en` locale.

Because we cannot get notifications when there are new translations
avaiable, there is a GitHub workflow (`update-i18n-deploy.yml`) that
downloads the content every few minutes, builds, and deploy. To speed up
this process, the previous generated assets are download. In local tests
this reduces the build times from 250s to 40s so the whole process
should take about 5 minutes.

The previous generated content is stored in Azure Storage. Because this
is a static website it makes more sense than having a dyno and will make
it easier to:
- deploy multiple locales at the same time if we still need to speed up
  the process
- have versioned docs because we just need to "take a snapshot" and
  publish to a different folder

The current live site is still not using this storage but will soon-ish.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Oct 7, 2021
Integrates with Crowdin to enable i18n of the site. This PR changes the
source of truth for Crowdin and moves it to this repository instead of
relying on `electron/i18n`.

Additionally it uses Crowdin's CLI to do the upload/download of assets
making it more reliable.

The website is built on locale at a time via `yarn i18n:build`.
Otherwise the process crashed with an out of memory error. The regular
`yarn build` command still compiles the `en` locale.

Because we cannot get notifications when there are new translations
avaiable, there is a GitHub workflow (`update-i18n-deploy.yml`) that
downloads the content every few minutes, builds, and deploy. To speed up
this process, the previous generated assets are download. In local tests
this reduces the build times from 250s to 40s so the whole process
should take about 5 minutes.

The previous generated content is stored in Azure Storage. Because this
is a static website it makes more sense than having a dyno and will make
it easier to:
- deploy multiple locales at the same time if we still need to speed up
  the process
- have versioned docs because we just need to "take a snapshot" and
  publish to a different folder

The current live site is still not using this storage but will soon-ish.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Oct 8, 2021
Integrates with Crowdin to enable i18n of the site. This PR changes the
source of truth for Crowdin and moves it to this repository instead of
relying on `electron/i18n`.

Additionally it uses Crowdin's CLI to do the upload/download of assets
making it more reliable.

The website is built on locale at a time via `yarn i18n:build`.
Otherwise the process crashed with an out of memory error. The regular
`yarn build` command still compiles the `en` locale.

Because we cannot get notifications when there are new translations
avaiable, there is a GitHub workflow (`update-i18n-deploy.yml`) that
downloads the content every few minutes, builds, and deploy. To speed up
this process, the previous generated assets are download. In local tests
this reduces the build times from 250s to 40s so the whole process
should take about 5 minutes.

The previous generated content is stored in Azure Storage. Because this
is a static website it makes more sense than having a dyno and will make
it easier to:
- deploy multiple locales at the same time if we still need to speed up
  the process
- have versioned docs because we just need to "take a snapshot" and
  publish to a different folder

The current live site is still not using this storage but will soon-ish.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
molant added a commit that referenced this issue Oct 11, 2021
Integrates with Crowdin to enable i18n of the site. This PR changes the
source of truth for Crowdin and moves it to this repository instead of
relying on `electron/i18n`.

Additionally it uses Crowdin's CLI to do the upload/download of assets
making it more reliable.

The website is built on locale at a time via `yarn i18n:build`.
Otherwise the process crashed with an out of memory error. The regular
`yarn build` command still compiles the `en` locale.

Because we cannot get notifications when there are new translations
avaiable, there is a GitHub workflow (`update-i18n-deploy.yml`) that
downloads the content every few minutes, builds, and deploy. To speed up
this process, the previous generated assets are download. In local tests
this reduces the build times from 250s to 40s so the whole process
should take about 5 minutes.

The previous generated content is stored in Azure Storage. Because this
is a static website it makes more sense than having a dyno and will make
it easier to:
- deploy multiple locales at the same time if we still need to speed up
  the process
- have versioned docs because we just need to "take a snapshot" and
  publish to a different folder

The current live site is still not using this storage but will soon-ish.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fix #64
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant