Integrate translations into beta workflow?

[joelnitta]

When the blog post announcing the beta phase of the Workbench format was written, there was no consideration yet as to how to handle translations.

Now that there is a (very early!) development version of a package 'dovetail' to help with translating lessons in Workbench, could we discuss how this might be integrated into the beta workflow? It may be a bit premature since dovetail is still just getting started, but I would at least like to brainstorm how this could be done.

One reason to think about this sooner rather than later is that we have local communities who would like to contribute translations so lessons may be used in their local languages, but it would be preferable to direct this effort at Workbench lessons (even in beta), since 'style' lessons will be phased out soon.

[zkamvar]

Joel, I cannot tell you how impressed I am at what you created! I think testing this out is absolutely needed and worthwhile and we should figure out the logistics so that we don't end up overwhelming the maintainers of the lessons undergoing the beta phase.

I think the most important thing is that we establish a clear workflow of what the translation workflow (inputs and outputs) looks like regardless of the tools used to create it (which I think you did well in dovetail). This way, when we need to in the future, we can pivot to a system that works well to be easy and equitable for translators and maintainers alike.

I also want to apologise for not getting more infrastructure for translations. Getting the workbench setup has been a long journey and we have had translation on our radar from the beginning, but it's been a big enough challenge that I haven't been able to properly tackle it (that is, make sure the solution is equitable) quite just yet.

Chopportunities

There are a few logistical challenges that I'm wondering (and have been wondering) about

1. what does the development cycle look like for translators and maintainers?
2. Is this language-agnostic? I.E. would this work for any language to any other language (e.g. can we have a Japanese lesson as the origin and translate that into Spanish)?
3. Where would the translations live?
4. Where does the website live?
5. How do we give proper credit the translators?

Regarding point 1 and 3: This is particularly important to me because the model of keeping po files inside the lesson repository means that the number of pull requests to that repository increases with the number of languages added, which puts burdens on the maintainers and barriers for the translators.

Regarding point 4: I think this point can be saved for later down the road, but I do want to get my thoughts in here. In the workbench website templates, we have a reserved navigation item for language selection next to the instructor view button, and a framework for implementing l10n into the lesson infrastructure. The challenge is: where do the translated websites live?

Sorry if this raised more questions than answers.

[zkamvar]

I agree that the po files living inside the repository can indeed work, and there are two ways it can work (each with tradeoffs) (and I apologise if I'm being too verbose; I have to process my thoughts out loud in order to understand them):

flowchart LR
M["😼 Maintainer"]
GH[(Repository)]

TF[(Transifex)]
T["😹 Translator"]

GH -.->|automation| TF;
T --> TF;
TF -.->|automation| GH;
GH --> M;
M --> GH;

Loading

In the above scenario, the translations get pulled in and automatically committed with no need for the maintainer's approval. However, if the maintainers are used to pushing directly to main, they will encounter this scenario:

$ git push
To https://github.com/program/lesson.git
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/program/lesson.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

This can be fixed by having maintainers always pull before they push, but it can be disruptive. This is why the updates to workflows and the package cache are done via pull requests. A diagram for this for the translation workflow can be seen here:

flowchart LR
M["😼 Maintainer"]
PR>"Pull Request"]
GH[(Repository)]


TF[(Transifex)]
T["😹 Translator"]

GH -.->|automation| TF;
T --> TF;
TF -.->|automation| PR --> GH;
M --> PR;

Loading

The drawback for this is that a maintainer is required to merge the pull requests as they come in, which means more notifications for the maintainers, which they have expressed frustration with.

The advantage of hosting the translations in a separate repository is that it could be an r-universe style infrastructure where the translation repository is completely automated in fetching updates from the lessons and the PO files:

flowchart LR
M["😼 Maintainer"]
GH[(Repository)]
AU[("Translation Repo 🤖")]
TF[(Transifex)]
T["😹 Translator"]

M --> GH
GH -.->|automation| AU
AU -.->|automation| TF
TF -.->|automation| AU
T --> TF

Loading

The benefit is that both the translators and maintainers can work seamlessly and new languages can be easily added. The cost is that it requires a more centralised setup that takes a bit more time to get off the ground and it's more difficult for orgs outside of The Carpentries to integrate this workflow.

I think either way is possible and I think it's possible to switch between the two.

[joelnitta]

I see, thanks for taking the time to re-create the diagrams!

I think it will be hard to make a final call without testing out each of these options. What about at least trying one of them during the beta phase?

From the standpoint of dovetail, I think it could be compatible with any one of these scenarios, so I will continue working on it with these possibilities in mind.

[zkamvar]

I think it will be hard to make a final call without testing out each of these options. What about at least trying one of them during the beta phase?

Joel, I really want to say yes and I really want to get this project going, but the problem is that I literally do not have enough hours in my day to support the additional coordination and development required for this testing to happen in parallel with the beta phase initially without burning out.

[zkamvar]

So, it's not a yes, but it's not quite a no... it's a please give me some time because there are a lot of complexities running around.

[joelnitta]

No problem! Better to be realistic about expectations than to overdo it. In the meanwhile, I can continue with development of dovetail on my own and see how it works with test translations of the beta lessons in the Japanese community.