feat: Add a new generic translation extraction type #1834
Conversation
For non-Django, non-JS projects we should be able to extract translations just using make commands and a small set of assumptions about where the source English file can be found. This adds that functionality and an integration with tutor-contrib-aspects which needs it.
|
@brian-smith-tcril I think this implements what we'd talked about in Slack. The referenced PR above may or may not work for using Atlas to pull the translated files from this repo, but we can't test it until there are some translations in place. I'm hoping that PR and this one get us at least to the place where folks can start translating and we can debug the pull part of the pipeline from there. Leaving this in draft until the other PR lands, though. |
Per feedback in openedx/openedx-translations#1834 this is really just a temp file, so we should treat it as one. Also adding a README to the locale dir to deter people from editing those files.
This relies on the extract_translations make target in each "generic" repo to create a transifex_input.yaml in the root of the site, which greatly simplifies the process.
Co-authored-by: Brian Smith <[email protected]>
There was a problem hiding this comment.
Thanks @bmtcril!
I see the find as a hack, but an acceptable trade-off until we standardize them.
However, for other repositories esp. the generic steps I recommend setting an explicit path. We don't expect to have too many of those repositories anyway to justify a find imo.
Ideally this step can be used for the Android app, but that's a topic for another day.
Please let me know what do you think.
| TRANSIFEX_YAML_PATH=$(find . -name 'transifex_input.yaml') | ||
| # stage the transifex_input.yaml file generated by make, force it in | ||
| # case the file is in .gitignore (it should be) | ||
| git add $TRANSIFEX_YAML_PATH -f -v | ||
| # Check the git status of the translation source files | ||
| echo "GIT_STATUS=$(git status $TRANSIFEX_YAML_PATH -s | wc -l)" >> $GITHUB_ENV |
There was a problem hiding this comment.
| TRANSIFEX_YAML_PATH=$(find . -name 'transifex_input.yaml') | |
| # stage the transifex_input.yaml file generated by make, force it in | |
| # case the file is in .gitignore (it should be) | |
| git add $TRANSIFEX_YAML_PATH -f -v | |
| # Check the git status of the translation source files | |
| echo "GIT_STATUS=$(git status $TRANSIFEX_YAML_PATH -s | wc -l)" >> $GITHUB_ENV | |
| # stage the transifex_input.yaml file generated by make, force it in | |
| # case the file is in .gitignore (it should be) | |
| git add ${{ matrix.repo.transifex_file_paths }} -f -v | |
| # Check the git status of the translation source files | |
| echo "GIT_STATUS=$(git status ${{ matrix.repo.transifex_file_paths }} -s | wc -l)" >> $GITHUB_ENV |
| max-parallel: 1 | ||
| matrix: | ||
| repo: | ||
| - tutor-contrib-aspects |
There was a problem hiding this comment.
| - tutor-contrib-aspects | |
| - repo: tutor-contrib-aspects | |
| transifex_file_paths: some-path-to/transifex_input.yaml |
|
@OmarIthawi I took a stab at your suggestions. I couldn't find a use of matrix like that in some looking around, so I'm not sure how it will work. Let me know what you think. |
There was a problem hiding this comment.
Thanks @bmtcril! Looks great.
Usually we require a testing on your fork, would you mind following this document to ensure the workflow works?
| repository_config: | ||
| - repo: tutor-contrib-aspects | ||
| transifex_file_path: transifex_input.yaml |
There was a problem hiding this comment.
That looks good.
I'm not sure if it's widely documented, but that's a proper GitHub matrix config to set the item as an object instead of a string.
|
Making this a draft while I test in my fork, hopefully will stop spamming people with errors |
bmtcril
force-pushed
the
bmtcril/add_generic_extract
branch
from
44a2475 to
94bb36a
Compare
|
@OmarIthawi the test ran successfully on my fork and created this commit: bmtcril@2ada561 |
|
Awesome @bmtcril!! I'm merging this. Thanks for your contribution and verifying that both this PR and documentation works!! |
For non-Django, non-JS projects we should be able to extract translations just using make commands and a small set of assumptions about where the source English file can be found. This adds that functionality and an integration with tutor-contrib-aspects which needs it.
Depends on openedx/tutor-contrib-aspects#462 being merged