Add statistics of localization to the docs

[DelazJ]

Add a script that loads and format the stats (code highly inspired from Alexandre's expression script) in a rst file we can include in other parts of the docs.

The real objective (following #6645) is to be able to provide something like in the godot-engine page: see widget in en vs fr: you get the stats corresponding to the locale used to build. I fail to find which Sphinx variable hold the build language.

Another issue related to the script is that we need to run it regularly to have it make sense --> automate the calls --> find a way to run it a the project level --> find credentials of the qgis user in Transifex. I have no idea where this could be added/found and who could be in help. @rduivenvoorde @mbernasocchi ?

Last point (an upcoming thread): we should really consider setting a threshold translation to allow language builds, otherwise we are filling our servers with duplicate English docs

[rduivenvoorde]

Nice work @DelazJ !!!!
Will have a look later into your questions/issues!

[DelazJ]

@rduivenvoorde did you have time to check if there's something we can use? Thanks

[rduivenvoorde]

@DelazJ nice, I'm able to create/output the stats!

If you only want this rst table, we could run some cronjob to run this script during the build of the docs?

If you want a widget, another route would be:

• have one script fetch the transifex full json daily and make it availabe at qgis.org (and/or docs.qgis.org) via some url (like we do the feeds)
• then create some javascript which
  • fetches that json, and make it available as plain json url
  • using javascript the same json injects a Widget for language on every page
  • using javascript the same json injects a table somewhere on both docs and site?

In the qgis.org site (and earlier also in the docs site), we do/did that kind of things in this script file which runs on every page:
https://github.com/qgis/QGIS-Website/blob/master/themes/qgis-theme/languageswitch.html

(which started as a js script to only build the language dropdown (also for every page), but evoluated to also inject the Flickr screenshots and atom feeds into the frontpage...

In that script I fetch the language from the url: https://github.com/qgis/QGIS-Website/blob/master/themes/qgis-theme/languageswitch.html#L62 because I also need the page path...
Another option is to pass it into conf.py like Juergen makes the schedule variables available in the 'context'
https://github.com/qgis/QGIS-Website/blob/master/source/schedule.py

https://github.com/qgis/QGIS-Website/blob/master/scripts/updatefeeds.sh

Those 'fetch scripts' then also can do some tests on the fetched data, to only write a new json if it is valid?

The ThankYou popup code is also 'injecting' some html into the DOM:
https://github.com/qgis/QGIS-Website/blob/master/themes/qgis-theme/languageswitch.html#L97

[DelazJ]

Hi @rduivenvoorde late reply, sorry.

If you only want this rst table, we could run some cronjob to run this script during the build of the docs?

Yes I want that table for translation statistics exposure of/to the whole community (and probably raise some discussion about minimal rate for build). I think I solved that issue, adding a transifex token to the repo (I did not know that I had enough rights to set one) with a weekly-scheduled github action branched on the script. This allows automated and manual/local run by everyone (preferable for me to something running server side, under few people maintenance). I think a week fetch is enough for what we have here.

If you want a widget, another route would be:

Yes I want a widget, or some nice way to display the current language translation rate (like the godot project - just above this section). If I'm not wrong, what we need is:

• a way to retrieve the language being built
• connect the language variable to its stats in the json file
• a way to display the stats within a "widget" in the Intro page

About your suggestions, well... TBH, I wished I had time to deeply explore your links and try to understand the differences and come with a sensible reply but... May I just say, please do the way you think is better and easily maintainable? TIA

[DelazJ]

@rduivenvoorde I opened a new issue report to handle the "widget" part of the issues. I'd like to merge this one, to test the GH action (should run tomorrow) and have a first part closed. May I?

[Gustry]

It looks nice work @DelazJ 👍
I will keep an eye on this script.

[DelazJ]

In that case, it should be safe to merge... and watch together

[DelazJ]

Afaict, it worked: df9842e

[Gustry]

Cool !