Openfoodnetwork: Automatically create pull requests for the transifex branch

[mkllnk]

Following https://community.openfoodnetwork.org/t/the-transifex-process/831/8.

Modify the scripts on our CI server to create pull requests. Whenever a locale is translated, we merge it into the transifex branch. At the same time we should check via the Github API if there is an open pull request for that branch. If there is no open pull request, we should create one. Whenever we push new commits to that branch, the pull request is automatically updated by Github. Before we do the next release, we can manually click the merge button in Github. Changes to locales other than en.yml are not visible on our staging server and therefore don't need to go through user testing. They are also not used on the Australian production server. A simple merge to master should be okay.

@RohanM and @oeoeaio: Any thoughts on this?

[enricostano]

One thing I would add is that assuming that Transifex process is the only way to add translations to OFN, I would create a bad practice check in CI to avoid commits to change other locale related files than config/locales/en.yml.

And we really should have only one way to add translations IMHO. What do you think?

[mkllnk]

That is tempting, but we haven't decided yet if we want to make Transifex the only option. It is a great tool, but has some disadvantages:

• Dependent on a third party. What if Transifex goes down?
• Not build on free software. Lock-in and value alignment.
• No offline translations.

There is some way to make OmegaT work with Transifex, but it's not ideal yet.

At the moment, you can open pull requests to submit your locale generated by another tool, but then you should not use Transifex, because it will override your locale.

[enricostano]

Completely agree, the "bad practice" thing could just be ignored in some cases (offline translations for instance).

Maybe we can try to make Transifex the only option for a green PR for now meanwhile we look for a better and FLOSS solution. I say so because the lack of an official option :tm: can generate confusion.

[daniellemoorhead]

Is this still relevant @mkllnk @enricostano? Should we be prioritising this work?

[mkllnk]

Yes, please. There is still annoying manual work with every release.

[myriamboure]

I added that to the delivery train backlog, it is part of sys admin standardization priority for m as well.

[mkllnk]

I added automatic branch and pull request creation in https://github.com/transifex/txgh/commit/93336288d634e0b9122c0a71bbcfb94d21eb61bd. It's deployed on our CI server now.

Looking through the code, I can confirm that we update a translation when it gets translated to 100%. But if translators change things after that point, it doesn't trigger anything any more. That's probably why a lot of changes didn't come through. I can change the code so that we also listen to 100% reviewed.

[mkllnk]

Ah, that trigger change was actually configurable. So that's all done now. We just need some translations now. :-)

[sauloperez]

Can I forget about creating and removing the branch while preparing a release?

[mkllnk]

Yes, we should update the documentation. It doesn't really matter, but I think it would be good to delete the branch when merging the pull request so that it gets created again with the first translation. That just gives a cleaner Git history.

[mkllnk]

Okay, I removed the step about re-creating the transifex branch from the release wiki page. I left the part about looking for a pull request. Once we are sure that everything works fine, we can simplify that step as well.