feat: setup Crowdin integration

[andrii-bodnar]

Hey everyone 👋

According to the discussion in #2053, I'm suggesting an automated solution for the Readme translation based on integration with Crowdin via GH Actions.

In this PR:

• .github/workflows/localization.yml - GH Workflows that trigger by pushes to the master branch. This workflow uses the crowdin/github-action to synchronize localization files (readme.md, docs/*.md) between the Crowdin Project and GitHub repo.
• crowdin.yml - a configuration file for Crowdin synchronization.

Here is the Crowdin Demo project - github-readme-stats-demo.

In this demo, the existing translations were uploaded to the Crowdin project by the GH Action, and the rest strings were automatically Pre-Translated using the Crowdin NMT machine translation engine (there is a possibility to connect any MT engine for that).

In addition, this workflow can be extended to localize all the project texts.

Example of PR created by the Action - #1 (Don't worry about the diffs - it's just updated the translation files to the actual state. Crowdin tries to keep the original file structure as much as possible. The next PRs will include the new translations only).

In this integration, there is still a possibility to suggest translations by the community. These translations will be synchronized from Crowdin to the Repo automatically. By the way, Crowdin provides an easy and comfortable preview of files for translators. This makes the translation process extremely straightforward.

[vercel]

@andrii-bodnar is attempting to deploy a commit to the github readme stats Team on Vercel.

A member of the Team first needs to authorize it.

[andrii-bodnar]

The next steps we can do to move further with this integration:

• Create a Crowdin or Crowdin enterprise account.
• Submit the Open-source project setup request form.
• Create a new Crowdin Project:
  • As a source language select English.
  • Fill in other target languages.
  • In the project settings enable the global Translation Memory (optional).
• Generate a new Personal Access Token in your Crowdin account settings.
• Generate a new GitHub Token (only the repo scope is required).
• Create the Actions secrets for your repository:
  • CROWDIN_PERSONAL_TOKEN - the personal access token generated in Crowdin.
  • CROWDIN_PROJECT_ID - ID of the Crowdin project.
  • GH_TOKEN - the personal access token generated in GitHub.
• merge this PR.

Then, according to the selected product (crowdin.com, Crowdin Enterprise) - configure an automation Workflow that will translate any new content added to the Crowdin project.

[rickstaa]

makes the translation process extremely straightforward.

Wow, that looks amazing. Thanks @andrii-bodnar! 🙏

One problem I noticed is that your system currently also translates code blocks of commands (e.g. locale -> locale). Do you have a way to ignore the translation of markdown code blocks? It looks like your solution already correctly ignores HTML code:

But arguments inside markdown code blocks are sometimes translated:

See, for example, andrii-bodnar@21492f6. Apart from that, I think this solution is gold 🚀.

[andrii-bodnar]

@rickstaa thank you, I need to check the code blocks translation issue in more detail 👀

[rickstaa]

@rickstaa thank you, I need to check the code blocks translation issue in more detail 👀

Thank you! Let us know if you need any information from our side. 👍

[anuraghazra]

Amazing work @andrii-bodnar
Thanks for integrating the action.

[anuraghazra]

The next steps we can do to move further with this integration:

Cool cool, will do this.

[andrii-bodnar]

@rickstaa @anuraghazra just updated my demo project - now it ignores the <code></code> blocks during the automated Pre-Translation. Some MT engines still can break some tags and placeholders, we can't fully control it. Currently, it was pre-translated via Crowdin NMT, you can try configuring the Google MT later to see the results it will provide.

Before you enable the automated pre-translation in your Crowdin Project, just tell me its ID, because it requires the same configuration on our side for code blocks.

Usually, the automated Pre-Translation via MT engines or Translation Memory - is just a first rough step. It's a good practice to review the translations by native translators after that.

I would recommend this auto Pre-Translate flow plus encouraging the community to review these translations or suggest their own translations if MT's suggestion wasn't so good.

[rickstaa]

@rickstaa @anuraghazra just updated my demo project - now it ignores the <code></code> blocks during the automated Pre-Translation. Some MT engines still can break some tags and placeholders; we can't fully control it. Currently, it was pre-translated via Crowdin NMT, you can try configuring the Google MT later to see the results it will provide.

Before you enable the automated pre-translation in your Crowdin Project, just tell me its ID, because it requires the same configuration on our side for code blocks.

Usually, the automated Pre-Translation via MT engines or Translation Memory - is just a first rough step. It's a good practice to review the translations by native translators after that.

I would recommend this auto Pre-Translate flow plus encouraging the community to review these translations or suggest their own translations if MT's suggestion wasn't so good.

Great, thanks for implementing this! 🎉 I will leave the merging and setting up of Crowdin to @anuraghazra. Does it also ignore markdown code blocks, or do we need to translate the current README code blocks from `CODE` to <code>CODE</code>?

[andrii-bodnar]

@rickstaa all the code blocks are marked as untranslatable elements (CODE is replaced with <code>CODE</code> due to the way how Crowdin deals with the md files). These elements will not be translated by MT engines and Crowdin will be checking all the suggested translations for tags consistency (Quality Assurance Checks).

During the translations export all these tags will be replaced with the md equivalent as it was on import.

[rickstaa]

@rickstaa all the code blocks are marked as untranslatable elements (CODE is replaced with <code>CODE</code> due to the way how Crowdin deals with the md files). These elements will not be translated by MT engines and Crowdin will be checking all the suggested translations for tags consistency (Quality Assurance Checks).

During the translations export all these tags will be replaced with the md equivalent as it was on import.

Damn, good work! That is amazing. @anuraghazra, in that case, the new setup looks good to me! 🚀

[rickstaa]

@anuraghazra I think we can also use Crowdin for the card translations. I use it on https://crowdin.com/project/github-emoji-picker, and it works amazing. Maybe we can do that after this PRs is merged. 🤔

[andrii-bodnar]

Hi @anuraghazra @rickstaa,

I'm just wondering about the status of this PR. It seems like it stuck. Please let me know if you need any details or clarification 🙂

[rickstaa]

Hi @anuraghazra @rickstaa,

I'm just wondering about the status of this PR. It seems like it stuck. Please let me know if you need any details or clarification 🙂

I think this pull request is good to be merged when @anuraghazra has performed the steps in #2489 (comment) 👍🏻.