-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: add the Python Repo section into OEP-58 docs #366
docs: add the Python Repo section into OEP-58 docs #366
Conversation
Thanks for the pull request, @OmarIthawi! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for writing up these docs! I left quite a few comments but overall this is wonderful! Looking forward to seeing these come together!
Enabling translations on a new repo is mostly starting from an up-to-date cookiecutter | ||
and the rest is ensuring that the repo is configured correctly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think linking to the cookiecutter and configuration docs might be helpful, maybe something like:
"The easiest way to enable translations on a new repository is to use an up-to-date cookiecutter, and ensure the repository is configured correctly"
Enabling translations on a new repo is mostly starting from an up-to-date cookiecutter | ||
and the rest is ensuring that the repo is configured correctly. | ||
|
||
However, this guide will assume that you're starting from scratch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you mean by "starting from scratch" here, it seems both the python and react repo instructions mention cookiecutters/templates.
The `OEP-58: Translations Management <https://docs.openedx.org/projects/openedx-proposals/en/latest/architectural-decisions/oep-0058-arch-translations-management.html>`_ | ||
proposal introduced new workflows and tooling to the Open edX translation management: | ||
|
||
- Created the new `openedx-translations project <https://app.transifex.com/open-edx/openedx-translations/dashboard/>`_ | ||
in Transifex. | ||
- Created the new `openedx-translations repo <https://github.com/openedx/openedx-translations>`_ | ||
in GitHub. | ||
- Setup two-way links between the Transifex project and the GitHub repo via the | ||
`Transifex GitHub app <https://github.com/apps/transifex-integration>`_. | ||
- Added new the `atlas <https://github.com/openedx/openedx-atlas>`_ command line tool to pull translations which will be used in the repo Makefiles, build and deploy processes to fetch translations from the | ||
`openedx-translations repo <https://github.com/openedx/openedx-translations>`_. | ||
|
||
The full background and rational for the new workflows and tooling can be found in the | ||
`OEP-58: Translations Management <https://docs.openedx.org/projects/openedx-proposals/en/latest/architectural-decisions/oep-0058-arch-translations-management.html>`_ | ||
docs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might make sense to have this be at the top of this document. It seems everything above this is also covered in the individual repo type sections, so that may not be needed.
`openedx-translations repo <https://github.com/openedx/openedx-translations>`_. | ||
|
||
The full background and rational for the new workflows and tooling can be found in the | ||
`OEP-58: Translations Management <https://docs.openedx.org/projects/openedx-proposals/en/latest/architectural-decisions/oep-0058-arch-translations-management.html>`_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: we tend to not use inline links in the middle of paragraphs like this. This is mostly for readability when editing the rst files, it's nice to just see
The full background and rationale for the new workflows and tooling can be found in the
`OEP-58: Translations Management`_ docs.
2f51afc
to
110dd4b
Compare
bfbd690
to
619d20c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this is looking great! Left a few comments with suggestions to make some parts a little less wordy, and a couple with questions about the order of instructions (what should be done pre/post PR)
7. Install the XBlock or plugin in a devstack and run the ``OPENEDX_ATLAS_PULL=true make pull_translations`` in | ||
the edx-platform repo to preview the translations in devstack. | ||
|
||
This step is somewhat oversimplified and assumes you're familiar with the Open edX development workflow whether | ||
you're using `Tutor <https://docs.tutor.overhang.io/>`_ or the | ||
`Open edX devstack <https://github.com/openedx/devstack/>`_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it make sense to move this step above the PR step? it seems like testing locally is something that should happen before PRing, but the listed command won't work pre-PR
7. Run the ``OPENEDX_ATLAS_PULL=true make pull_translations`` to verify that it pulls the translations from the | ||
`openedx-translations repo`_ into ``conf/locale`` directory. Depending on the repo | ||
``make static``/``make static.dev`` is usually needed to generate the JavaScript translation files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it make sense to move this step above the PR step? it seems like testing locally is something that should happen before PRing, but the listed command won't work pre-PR
035b70d
to
42b5608
Compare
cf7c7d9
to
612d8b9
Compare
@brian-smith-tcril Thanks a lot for the review and suggestions. It's much better now. I've tried to address all review comments and I've added inline TODOs where I intend to make further PRs. This PR is ready for another review/merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks wonderful! I left a couple comments with tiny nitpicks but this is 99% good to go!
I also left one comment in there with a suggestion that might make it so people don't need to scroll up and down as much, but I wouldn't consider that a blocker for merging this.
#. Run ``OPENEDX_ATLAS_PULL=true make pull_translations`` to verify translations are pulled from the | ||
`openedx-translations repo`_ into the ``conf/locale`` directory. To generate JavaScript translation files you will | ||
likely also need to run ``make static``/``make static.dev``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Variations of this exist in all 3 types of repo instructions. Maybe it makes sense to move it down into the debugging section instead of having people scroll down and then back up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point @brian-smith-tcril, but I'm reluctant to merge them.
The three variations would may end up in a large item with 3-bullet points which is slightly more complicated than scrolling up and down.
I'd like to keep it as-is and we can iterate later.
a4aa32e
to
4c884b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spotted a couple of structural issues in my review that I think should be changed, but I did not thoroughly review the content.
============ | ||
Introduction | ||
============ | ||
|
||
|
||
The `OEP-58 - Translations Management`_ proposal introduced new workflows and tooling to the Open edX translation | ||
management: | ||
|
||
- Created the new `openedx-translations project`_ in Transifex. | ||
- Created the new `openedx-translations repo`_ in GitHub. | ||
- Setup two-way links between the Transifex project and the GitHub repo via the | ||
`Transifex GitHub app <https://github.com/apps/transifex-integration>`_. | ||
- Added new the `atlas <https://github.com/openedx/openedx-atlas>`_ command line tool to pull translations which will | ||
be used in the repo Makefiles, build and deploy processes to fetch translations from the | ||
`openedx-translations repo`_. | ||
|
||
After configuring the repo as shown in the sections below, the translations workflow will automatically: | ||
|
||
- Add the extracted source (English) translation files from the repository you added to the | ||
`openedx-translations repo`_ in GitHub. | ||
- Create a new Transifex resource for your repo in the `openedx-translations project`_ in Transifex. | ||
- Add the translations (Arabic, French, etc) to the GitHub `openedx-translations repo`_ when translation entries are | ||
updated by translators. | ||
|
||
The full background and rationale for the new workflows and tooling can be found in the | ||
`OEP-58 - Translations Management`_ docs. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section is useful context but I think belongs in a concepts
doc probably one titled Translation Technology and Process
. Then I think you could add a link to that in a ..seealso
section of this document.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed this section and focused on the How-to part.
This section is a summary of the OEP-58 document. So if we're aiming for brevity, a link should suffice.
I have the habit of summerization from the time that I used to write some academic research.
The full background and rationale for the new workflows and tooling can be found in the | ||
`OEP-58 - Translations Management`_ docs. | ||
|
||
The next sections cover the steps to enable translations on a new repo depending its type: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need this line.
|
||
TODO: How to enable translations infrastructure on a Python repo | ||
========== |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use the heading structure describe in the Documentation quick-reference instead of using double headings. https://docs.openedx.org/en/latest/documentors/references/quick_reference_rst.html#headings
#. For existing repos which don't have the ``make extract_translations`` command, it can be copied from the | ||
`edx-cookiecutters`_ Makefile in the corresponding template e.g. ``cookiecutter-xblock`` Makefile for XBlocks. | ||
|
||
**Note:** Some repositories use ``django-manage makemessages``. The recommendation is to use ``i18n_tool extract`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use a ..note
admonition instead: https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-note
#. If you are creating a new repository, use the `cookiecutter-django-ida`_ | ||
template. | ||
|
||
**TODO:** How to enable translations infrastructure on a Django microservice |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this todo still relevant? Seems like you answer it below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it needs expansion and I'll follow up in other PRs.
@feanil thanks for the comments. The PR is ready for another review. |
4c884b6
to
71ebcc4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last change and then it looks good to me from a syntax and structure perspective.
|
||
TODO: How to enable translations infrastructure on a Python repo | ||
Quickstart | ||
********* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
********* | |
********** |
Needs to match the length.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done @feanil!
document the new translation workflow This contribution is part of the [FC-0012 project](https://openedx.atlassian.net/l/cp/XGS0iCcQ) which is sparked by the [Translation Infrastructure update OEP-58](https://open-edx-proposals.readthedocs.io/en/latest/architectural-decisions/oep-0058-arch-translations-management.html#specification).
71ebcc4
to
2aba751
Compare
@brian-smith-tcril would you mind checking if it's ready to merge? So I can start merging adding the other sections. |
@brian-smith-tcril feel free to merge yourself once you think this is good. |
@OmarIthawi 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
document the new translation workflow for Python Repo.
I'll be filling the other sections in upcoming PRs.
For now the controversial part is whether we should be recommending
i18n_tool extract
or usedjango-admin.py makemessages
. My memory isn't helping me to determine which does what, so I'll be asking for help from @shadinaif and of course @sarina who have used both a ton.Preview the file here: https://github.com/Zeit-Labs/docs.openedx.org/blob/mfe-atals-docs/source/developers/how-tos/enable-translations-new-repo.rst
This pull request is open against a parent one that'll be merged later:
This contribution is part of the FC-0012 project which is sparked by the Translation Infrastructure update OEP-58.