ci: autoupdating translation stats via PRs

[RobPasMue]

This PR solves the autoupdating problem we currently have in the translation stats.
It will run once a month (or on demand) and it will trigger a PR to update the _static/translation_stats.json file in case any modification happened.

It leverages https://github.com/peter-evans/create-pull-request behind the scenes for the PR creation process.

Related to #493

[RobPasMue]

Not sure why the deploy workflow is not working @lwasser 😢

[sneakers-the-rat]

So I am not sure why we don't just remove translation stats from being versioned and then compute them every time we build the docs? Seems like they should be pretty cheap to compute, should always reflect the current status, and they aren't used anywhere but the graph? Seems like riding up to a month behind and needing to add another ci action might be a lil complicated

[sneakers-the-rat]

here's how i would do that: RobPasMue#1

[RobPasMue]

Hi @sneakers-the-rat! Sure, we can move to a single-process file generation. I'm fine with that option as well. Like I mentioned in #511 (comment) I went with my initial ideal which was to set up the workflow mechanism but I'm fine going with your approach as well. I think both of them are valid anyway, both of them have pros and cons - your case generates all in the fly and avoids making the file persistent, which is fine. But during discussions happening at the PyCon sprint with @lwasser I thought we would want it to persist. That's why I went with this approach. I know my approach has the downside of having "stale" information (until you run the workflow again manually or the scheduled run gets triggered).

[sneakers-the-rat]

Ya I don't have strong feelings, my preference is just based on always having the correct info & avoiding another workflow that would require someone to merge it periodically, but if we want to have it as a persistent file within the repo (as opposed to a persistent file on the site) then this would be the way to do it

[lwasser]

hey @RobPasMue @sneakers-the-rat
Can you help me understand the difference between this persisting on the site vs in the repo? If it's on the site won't it be in the repo as well? I suspect i'm mis-understanding something basic!

I am agnostic regarding approach. I think when I was thinking about it as a separate workflow, then we might want to have a workflow dispatch to trigger and update. however, if it builds every time the docs build and things are updated, then I think that is great.

Regarding the output - we do want it on the site, but I think for contributors, i could imaging a .png file that gets updates too that our README file can render (i would presume fancy plotly or other types of plots won't work in a readme file). The idea here would be that new contributors can quickly look at our readme and we can highlight how to get involved there and link to the translation page. But having a graphic in the readme will make it super clear where they can quickly plugin if they are bilingual.

I hope that make sense. Please let me know if there is another / better way to think about this!

[RobPasMue]

Hi @lwasser!

So the main difference between both approaches is that:

• Using the workflow and PR creation approach, the translation_stats.json is available inside the repository as a committed file. That implies that we have to update it (manually, using workflows with dispatch mode or scheduled mode).
• Using the in-process mechanism, the file is not committed to the repository itself (it will be available in the gh-pages branch sinec it gets committed as part of the documentation build). The file gets generated on build time.

In both cases, the output docs will both show the graph properly generated and users will be able to download it if they want. If that's the main goal, I think that @sneakers-the-rat approach makes definitely more sense. I will change the implementation accordingly :)

[lwasser]

@RobPasMue that sounds great. If it's on the gh-pages branch in the end and the build happens every time, then we don't need to worry about syncing the data. That sounds like a perfect approach to me if you are OK with it! Thank you for breaking it down for me!

[RobPasMue]

Sure no problem! I'll review the PR that @sneakers-the-rat did on my fork and submit the changes. However, due to potential conflicts, I would merge #511 beforehand.

[RobPasMue]

Or if @sneakers-the-rat wants to submit the PR directly here that's fine by me too! =)

[lwasser]

ok friends. I just merged #511 as requested above. This pr can be rebased if needed 🚀 Please let me know how else I can support!

[RobPasMue]

Awesome, thanks @lwasser! @sneakers-the-rat let me know how you prefer to proceed - I'm fine with any of the previous options I listed: me reviewing your PR on my fork and submitting the PR from my fork; or you submitting the PR directly into the repo from your personal fork =)

Just want to give you the proper credit! =)