Automate plugin translation process

[engahmeds3ed]

Is your feature request related to a problem? Please describe. We have a process (mostly manual process) to handle WP Rocket translations as follows:-

1. Starting from the develop branch when we finish the release development and start the alpha release.
2. Merge develop branch into transifex branch.
3. Checkout transifex branch.
4. Update bot file with new translatable strings using poedit (or WP CLI, will mention that later).
5. Wait till transifex finalize its work of translations.
6. With the final release (PR to merge develop into trunk), call bin/makemo.sh script to generate mo files.
7. Merge transifex branch into develop
8. Everything is now on develop branch and available for the release.

Describe the solution you'd like We need to create github workflow(s) to automate this part.

[WordPresseur]

Transifex automatic translations are rarely accurate at the first shot and still need to be reviewed by a human, especially for our features' names.

[wordpressfan]

Transifex automatic translations are rarely accurate at the first shot and still need to be reviewed by a human, especially for our features' names.

Sorry for the late reply here, we are trying to automate the process that we already do manually so you still can go to transifex and update the translation as u would like then with WPR release all of those translations will be grabbed as it's in transifex.

[wordpressfan]

Grooming

Alpha release process

The Idea is to create a PR for the release from develop into trunk with the name Release/x.x.x and the changelog as a PR description then once we create it we will wait till tests pass and dynamic lists commit is added then we need to manually add the label release-alpha once we add this label we will do the following steps:

1. Checkout transifex branch
2. Merge develop into transifex
3. Install NPM dependencies
4. Call the command npm run makepot to update pot file
5. Call the shell script bin/makemo.sh (this point needs to be validated to make sure that the msgfmt is there in the OS because we depend on it inside this shell script).
6. Commit the changes and push into transifex
7. Checkout develop
8. Merge transifex into develop
9. Create a new tag from develop branch and get the version info from the PR (we need to set naming convension for example Release/x.x.x)
10. Then this will trigger our deployment workflow that we already have.

For this, we need to create a github workflow with the trigger of pull_request labeled

Final release process

The trigger for this process will be manual:

1. Change the plugin version in the main WPR file and push this commit into develop.
2. Merge the release PR that we created above.
3. Create a release/tag from trunk
4. This will trigger our deployment workflow that we already have.

---

Here I'll mostly use github cli commands inside the workflow.

[MathieuLamiot]

Pending next alpha to test & compare with the manual process.