Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track number of Sphinx build warnings #45

Closed
wants to merge 24 commits into from
Closed

Track number of Sphinx build warnings #45

wants to merge 24 commits into from

Conversation

m-aciek
Copy link
Collaborator

@m-aciek m-aciek commented Feb 1, 2025

A new column with number of Sphinx build warnings for every language build. Linking to a text file with warnings.


📊 Dashboard preview 📊: https://python-docs-translations.github.io/dashboard/45/merge/

@rffontenelle
Copy link
Collaborator

How about have the warnings text file made available in the published page, accessible as a link via the warning numbers?

@m-aciek
Copy link
Collaborator Author

m-aciek commented Feb 1, 2025

How about have the warnings text file made available in the published page, accessible as a link via the warning numbers?

We are copying the file to main directory and linking to it in the template. It works locally for me (tested the change with a single language).

The [readthedocs] build was terminated due to time out.

It looks like we need to switch to GH pages with pull requests preview.

@AA-Turner
Copy link
Member

This feels out of scope, at least without justification. Especially given it now introduces a dependency onto Sphinx and runs the full build process for each translation.

A

@m-aciek
Copy link
Collaborator Author

m-aciek commented Feb 1, 2025

Some background discussion is here: python-docs-translations/transifex-automation#91.

For me after tracking the completion progress, tracking quality indicators of a translation feels natural. If the intended audience of the dashboard are (potential) contributors, this feature would support the engagement.

The impact on generation time is huge, maybe for local runs we could provide a flag to toggle it? I am thinking also of some kind of data caching to ease the dashboard development, but for now it seems to me like the implementation is not obvious.

@m-aciek
Copy link
Collaborator Author

m-aciek commented Feb 1, 2025

Part of me feels like quality checks should only be part of a translation platform. It would be probably easier with Weblate as it's more customizable and Python friendly than tx. But a number of translation projects don't use platform, and centralized place to look up such checks could be beneficial for them.

@rffontenelle
Copy link
Collaborator

Weblate recently implemented reStructuredText quality checks which helps a lot for Sphinx-based docs. Even though, building and linting enables a useful central point of warnings.

I feel this dashboard is a great place to put warnings, as this is becoming a great place for nice insights of Python docs translation.

Are the builds being parallelized to optimize time and resources?

@m-aciek
Copy link
Collaborator Author

m-aciek commented Feb 1, 2025

Are the builds being parallelized to optimize time and resources?

They aren't. Let me look into that.

@m-aciek
Copy link
Collaborator Author

m-aciek commented Feb 1, 2025

By the way, even though we don't have the preview working, the build is being uploaded in Actions, and can be downloaded: https://github.com/m-aciek/pydocs-translation-dashboard/actions/runs/13088511934/artifacts/2521209918.

@m-aciek
Copy link
Collaborator Author

m-aciek commented Feb 3, 2025

For what it's worth process parallelization and removing builds for 0-completion language projects cut down time on GitHub Actions from 47 to 31 minutes. Locally on my computer to less than 12 minutes.

@m-aciek
Copy link
Collaborator Author

m-aciek commented Feb 4, 2025

After the docs community meeting and Adam's comment about details level, I'd like to try with a separate table view linked from main view. “Translations Quality”/“Translations Checks”?

For now I have an idea for four columns:

  • language
  • translated branch
  • build warnings (sphinx-build)
  • lint errors (sphinx-lint)

I think I'll try to develop that in a separate branch/PR. Also I'm thinking that probably a separate cron/loop would be nice, to generate it independently from the main view.

@m-aciek m-aciek mentioned this pull request Feb 5, 2025
@m-aciek
Copy link
Collaborator Author

m-aciek commented Feb 18, 2025

Closing in favour of #58.

@m-aciek m-aciek closed this Feb 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants