Description

When adding translations of text for the buttons on the home page, the buttons become inactive and are replaced with simple text of the translation instead of a button containing the translated text. None of the text is clickable.

Screenshot

For reference, these are the "Returning Teams" and "New Teams" sections on the home page. The text in the bottom of each card is supposed to have buttons, e.g. "Changelog" or "Go to Zero-to-Robot".

Note: I am going to revert the changes so that the latest version of the site is functional.

So translators can view changes inline:

1. Clone
2. Install requirements
3. tx pull -l fr_CA,es_MX --mode onlyreviewed --use-git-timestamps
4. make -e SPHINXOPTS="-D language='fr'" html

Suggestion(s)

1. Use any analytics that might exist for page traffic to figure out which wpilib pages are the most used and create a list ordered from most to least visited and use that as a reference order for translating pages. This would probably need to be regenerated at the beginning/end of each build season.
2. If that data is difficult to use or non-existent, a fallback might be doing some sort of site-mapping exercise and assigning some heuristic based on depth of resource (e.g. how many links you'd have to click to get there from a top-level link to get to the page) and/or based on prevalence (e.g. how many pages link back to a page).

This would help translation teams make the most impact early on and avoid duplicated effort on new/high-churn pages.

Context

I have been leading the translation for the Japanese frc-docs for the past several months. A common thought I've had is "it's difficult to figure out what to translate next". When there's not a clear answer, I usually ask around until we settle on something, but this isn't a great use of time and doesn't guarantee we are working on a page that is actually that useful.

My manual process has basically boiled down to:

1. Translate explicit zero-to-robot resources
2. Translate resources that are referenced in the indices for zero-to-robot
3. Translate random pages that are referenced in zero-to-robot pages
4. Translate pages that feel important
5. ???

Not to say this is a terrible approach, but we are getting to a point where we are spending relatively a bit more time pondering on what to work on vs. actually working on things.

I also think it's helpful for delegating and motivating. I would always have the next item ready to go when I have a translator who has time to help, and translators always know they are working on the most important thing that needs to be worked.

See the last updated flag here https://www.transifex.com/api/2/project/frc-docs/resource/docs--contributing--top-contributors?details

Take a look at these images. Does anyone have any ideas why this is happening?

Currently whenever we move or rename articles, it creates duplicates on Transifex. We should be able to do a pull of the transifex documents and see which ones then get used. We'll then run a script to delete the unused assets from transifex.

l use your transifex workflow as reference but l go into an error with Error retrieving remote resources 404, l don't know whether it is a problem of network? But since it is runned on Github's runner , l don't think it is a problem of network. And here is my lock-translation.py https://github.com/mendax1234/6940Swerve-docs/blob/main/scripts/lock-translations.py , can you give me some suggestions on how to fix this bug? Thanks!

Best
Daniel

It was nice having clean git diffs previously, but because of Sphinx's incremental builder it wouldn't delete the deleted POTs when a resource was deleted. We should not recreate all the POTS, just delete the deleted ones.

We need to handle the situation where a resource is relocated.

If we detect a relocated resource using a git diff, we should: push source updates, pull the new translations, upload the old .po translation file to the newly created resource, lock/delete old resources.

We should make the update.sh script be a python script so it is cross platform

The transifex-client as well is going away in November 30, 2022. The new transifex/cli is going to be the new thing. Since the new client is written in Go lang, it won't be installable via Python's requirements.txt,

For more info: https://community.transifex.com/t/postponing-api-2-0-2-5-and-transifex-client-sunset-date/2759