You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here we have to move the current script to detect pending translations from the workflow to a script inside the website directory.
Outcome
A script called pending-translations.sh that has the current implementation to detect the pending translations. Also evaluate the potential of this script as translation.sh --dry-run --debug for testing purposes.
Evaluate the next behavior for the script
Have minimal maintenance, adding new translations in the future. We could for example look at the repository and check the folder names https://github.com/cncf/tag-env-sustainability/tree/main/website/content - we have a folder en & zh & es &de, we establish a base with en (we dont need to open a PR for en since its already merged). This could eliminate referencing languages in the script.
Assigning people over groups could work this way too. We assign tag-env-translators- so for example tag-env-translators-es.
To reduce duplication we should look into possibilities to loop through the list of issue templates and for every entry trigger a "Create issue" action instead of duplicating the action for a single file. I think that you can achieve something close to running an action in a loop with matrix in GH Actions. Should we create a task for this?
We should also look into storing supported languages (that you store in languages variable) somewhere more visible, outside of the workflow, where the list can be retrieved from, like a separate file for instance. Or even let the script check the website/content folders for languages and dynamically generate the list with languages from it. In that case we can potentially avoid relying on someone remembering to manually update this list in this script based on new languages being added. Show we create a task for this or maybe consolidate it in the same task with the previous point?
Should we also create a first, pilot, reviewer group for one of the languages? Maybe we should have a task for it as well so that we can create translator groups once you feel the automation is ready? So that we can avoid potentially spamming folks in the beginning, while automation is still being tested and maturing.
To-Do
Move the code inside .github/workflows/check-outdated-content.yml to website/content/translation.sh
Test the script translation.sh
Add --dry-run
Add --debug
Evaluate the execution as translation.sh --dry-run --debug
Description
Here we have to move the current script to detect pending translations from the workflow to a script inside the website directory.
Outcome
A script called pending-translations.sh that has the current implementation to detect the pending translations. Also evaluate the potential of this script as translation.sh --dry-run --debug for testing purposes.
Evaluate the next behavior for the script
Have minimal maintenance, adding new translations in the future. We could for example look at the repository and check the folder names https://github.com/cncf/tag-env-sustainability/tree/main/website/content - we have a folder en & zh & es &de, we establish a base with en (we dont need to open a PR for en since its already merged). This could eliminate referencing languages in the script.
Assigning people over groups could work this way too. We assign tag-env-translators- so for example tag-env-translators-es.
To reduce duplication we should look into possibilities to loop through the list of issue templates and for every entry trigger a "Create issue" action instead of duplicating the action for a single file. I think that you can achieve something close to running an action in a loop with matrix in GH Actions. Should we create a task for this?
We should also look into storing supported languages (that you store in languages variable) somewhere more visible, outside of the workflow, where the list can be retrieved from, like a separate file for instance. Or even let the script check the website/content folders for languages and dynamically generate the list with languages from it. In that case we can potentially avoid relying on someone remembering to manually update this list in this script based on new languages being added. Show we create a task for this or maybe consolidate it in the same task with the previous point?
Should we also create a first, pilot, reviewer group for one of the languages? Maybe we should have a task for it as well so that we can create translator groups once you feel the automation is ready? So that we can avoid potentially spamming folks in the beginning, while automation is still being tested and maturing.
To-Do
PR reference #407
Code of Conduct
Comments
This issue is part of the next steps for the issue #325
The text was updated successfully, but these errors were encountered: