Splitting into version branches

[MikuroXina]

Currently, translation contents are stored in versions folders. But doing this occurs some confusing on Crowdin because there are many contents like these:

• /current/en-US (should be translated)
• /en-US (not used)
• /(major)-x-y/en-US (not used except latest version)

According Crowdin docs, I think it needs to split them into their version branches:

• 10-x-y
• 11-x-y
• 12-x-y (current)
• 13-x-y

[welcome]

👋 Thanks for opening your first issue here!

[molant]

Going to be working on this. Hopefully I'll have a PR soon-ish

[molant]

I've been looking at our crowdin implementation and it looks like we are not using the GitHub integration and just the GitHub action. Adding the GitHub integration will make the handling of version branches easier.

I'm trying to come up with a plan that I'll update as I found more info.

• Pause any crowdin integration
• Create new branches for the supported versions (10-x-y, 11-x-y, and 13-x-y, master will track the current stable and we might be able to rename it to main in this effort)
• Update each one of those branches with the following:
  • Move appropriate content from contents/version-x-y directly into contents and delete the rest
  • Configure schedule-download-translations.yml to run only on that particular branch (on branch: "branchName") and set the option pull_request_base_branch_name to that branch as well (we might be able to use a predefined env variable for this?). I'm not an expert on GitHub Actions so we might need to add multiple workflows to the main branch or maybe we can just have the right one on each branch.
  • Update collect.ts to put the content in the right branches instead of folders. We could have an action that runs only on that branch. That should hopefully make things easier...
  • Configure the schedule-update-source-content.yml to run only on that branch (on branch: "branchName") and set the option crowdin_branch_nameto that branch. **Note 1:** This is the workflow that triggerscollect.ts. **Note 2:** We might be able to skip this step if we do the GitHub integration (although we might still have to call collect.ts` somehow)
• TBD: Updates to the website to point to the right place when looking at previous versions
• Add a script that automatically checks what is the latest release number. If there is a new one then it will move the master/main one to whatever value should have, move the next one to master/main, create a new one, running the appropriate scripts in each branch
• Enable GitHub integration on crowdin to track this repo or re-activate the actions

@erickzhao how does this sound? Who else should I ping to validate this (at least the high level vision)?

[vhashimotoo]

Who else should I ping to validate this (at least the high level vision)?

Maybe @vhashimotoo, some folks say that he has an understanding of i18n workflow. But I not sure if he would talk 🙃

[molant]

But I not sure if he would talk 🙃

Last time I read him, he wanted some quiet time and did not want to be pinged so I wanted to be respectful of his whishes. That said, if you have a way to communicate with him and see if he would like to validate the above strategy it would be awesome 😉

[vhashimotoo]

@molant for some issues I have exceptions.

From opening this issue I always think it's an out-of-scope because it's easy to say to do, but in the practice, I not understanding how does this should work, to create the best DX for everyone.

Who is the Source of Truth for scripts?

The question itself is who runs the scripts, which branch? If we talk about every branch runs the script itself, who should update these scripts?

In my best vision, it's greatest to split the branches, clean them, and runs scripts from the master/scripts branch.

This gives a guarantee of the script is be always on top of the tree.

Not End But And Not Continue

I still have many other minds about this in the head, and maybe will share them when having more details. But this is only one of the big problems which I can see.

The plan itself maybe looks good, but yes it's only the tip of the iceberg and can have many other issues.

[molant]

Thanks @vhashimotoo
I'm doing some tests on a new crowdin project to test things and find the path of less resistance.
I'll keep updating here.

[vhashimotoo]

Since all issues which I found can be fixed or they go to only a single source, yes it's possible and I already have a dirty solution (which means this isn't tested, but it's should work)