Fixes l10n workflow.

[pierreozoux]

I think this time it will be good \o/

(sorry for all these commits, difficult to try on my machine :/ )

• I add the id to the job so the test to autoapprove/automerge will work
• I avoid to test this branch as this branch is triggered by a bot and then it doens't trigger other jobs...

[skjnldsv]

• I avoid to test this branch as this branch is triggered by a bot and then it doens't trigger other jobs...

You can use appropriate tokens for those. Have a look at the transifex configuration we have here for example https://github.com/nextcloud/nextcloud-upload/blob/master/.github/workflows/l10n.yml https://github.com/nextcloud/nextcloud-upload/blob/master/.github/workflows/transifex-approve-merge.yml

[pierreozoux]

@skjnldsv Actually, let me go back and take a bit of perspective.

The transifex -> GitHub problem is already solved. (Transifex automatically creates a PR and it is automagically merged \o/)

But, the missing bit is how to do github -> transifex automatically.

To my knowledge here are the approaches possible:

• ask people contributing to doc to also include updated pot files (I think it is a lot of work on their side, and will not ease contribution)
• run a job against PR to add this change (I don't like this approach as I find it difficult to amend work in PR)
• run a job once a PR is merged
  • this job could automatically commit to master branch the pot files (this is what I'm trying to do in this PR) (and then transifex is configured to pull from github)
  • or this job could push directly to transifex with the transifex cli

I think the last approach is my favorite one. I like to have one version of resources, and not copy them around. So for me the ideal case would be to:

• once a PR with new doc is merged
• create POT files in a job
• push these to transifex
• and do not store them in GitHub And then, once we want to build documentation:
• pull PO files (translated strings) from transifex
• build doc with these pulled files

The benefit is that we avoid the noise of PRs and actions moving around all the time.

But to do so, we need:

• transifex api token (from me or a bot, don't know the best)
• access to GitHub settings to configure this token in the settings.

As I don't have either, that's why I went the "automatic PR" route.

And then once we are happy with the automation, we can replicate it in the various Nextcloud repos.

Hope this helps, and I'd love to have your feedback @skjnldsv :)

Have a nice day!

[skjnldsv]

But, the missing bit is how to do github -> transifex automatically.

This is done automatically. Once the pot file is updated on the github repo, transifex is syncing it every 6h

Project stays synced with your GitHub settings. Resources not identified in the settings YML are automatically deleted. Learn more. https://docs.transifex.com/transifex-github-integrations/github-tx-ui#section-syncing-content-from-github

[skjnldsv]

Here is the config for the upload library https://github.com/nextcloud/nextcloud-upload/blob/master/transifex.yml

[pierreozoux]

@skjnldsv yes ok, I know, I configured it in this repo :upside_down_face:

But how to you convert rst files to pot files automatically without asking "devs" to do so? This is what I try to fix.

[skjnldsv]

But how to you convert rst files to pot files automatically without asking "devs" to do so? This is what I try to fix.

Ah, sorry, I misunderstood this part:

But, the missing bit is how to do github -> transifex automatically.

I would ask the devs, same as we do in a lot of places. You can also add a command to do so from a comment, same as we do for the shipped binaries. But instead you use the l10n pot generate command

/l10n-build (amend|fixup)? or something

[pierreozoux]

You can also add a command to do so from a comment, same as we do for the shipped binaries. But instead you use the l10n pot generate command

/l10n-build (amend|fixup)? or something

Then this is similar to

run a job against PR to add this change (I don't like this approach as I find it difficult to amend work in PR)

I wouldn't say that this approach is fully automatic either.

I'm also available for a call, maybe it is easier, and I think it is worth it to discuss a bit, and have the same approach on all repos.

[skjnldsv]

and have the same approach on all repos.

We enforce l10n checks and being up-to-date on all libraries for now (vue, moment, dialogs and upload) I think it's easier that way

[pierreozoux]

@skjnldsv so if I understand well, you say that you prefer develop a check that asks the author to correct its PR, when the exact same check can do the work and not bother the author?

I think moving forward, I'd like to basically automate this, so we don't have to think about it anymore.

[skjnldsv]

@pierreozoux then use the command bot token on the pull-request-create step. Then it should work.

Also, instead of triggered on every push, could yousetup a cron job instead? Maybe every 3h? That should reduce the load a lot :pray:

[pierreozoux]

I thought a lot about this topic, and I think the right approach would be:

Push to transifex:

- once a PR with new doc is merged
- create POT files in a job
- push these to transifex (and do not store them in GitHub)

Pull from transifex, once we want to build documentation:

 - pull PO files (translated strings) from transifex
 - build doc with these pulled files

If you agree with this approach, I can start to implement it.

If you have questions, suggestions, want to discuss what would be the best approach, let's sit down around the table with a 30m/1h call together to fix doc and translation for Nc once for all.

[p-bo]

skjnldsv With all respect to aim to ensure the most correct workflow, in meantime, we have translated user docs for servers into quite few languages for long time, even with imperfect workflow, thus much more useful for user around the globe. But unfortunately translations of desktop client docs are blocked until this will be solved in most perfect way. So what about to unblock it allowing the same workflow as for user-server docs for now (so we, translators could do work for user) and afterward refactor both workflows "on background" into desired state?

[rakekniven]

We have a big demand of localized desktop client manual from our users at the forums. So please, please make this thing starting.

[p-bo]

Any hope we can advance there please? That offered virtual meeting between repo admins and contributors sounded promising…

[rakekniven]

Hello @pierreozoux @skjnldsv ,

hope you are doing well.

How can we get this thing done? Can you please summarize the problems there are?

At the forums we have users struggling with englisch client docs and I want to help them.

[skjnldsv]

Let's move forward