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

Automate the gettext machinery #126

Open
bmillemathias opened this issue May 11, 2018 · 5 comments
Open

Automate the gettext machinery #126

bmillemathias opened this issue May 11, 2018 · 5 comments

Comments

@bmillemathias
Copy link
Contributor

bmillemathias commented May 11, 2018

I wrote previously the french translation and the updates, and it is tiresome to check and to update manually the po files, so I like to know if it would be possible to automate the process for gettext, so we will have pot for new language contribution and update of po files with new and fuzzy strings.

We could also benefit to setup some hook with online translation like transifex or Zanata

Thanks

@TingPing
Copy link
Member

Run make gettext in the docs dir.

@TingPing
Copy link
Member

@bmillemathias
Copy link
Contributor Author

bmillemathias commented May 12, 2018

Yes I used this doc and succeed (manually) to generate the POT files (but in the standard docs/_builld/) location and then register and push them to transifex as a test bed on https://www.transifex.com/baptistemm/flatpak-documentation/

If we could automate that (except the transifex part) that'd be great and useful

@bmillemathias bmillemathias changed the title Set up the gettext machinery Automate the gettext machinery May 12, 2018
@rffontenelle
Copy link
Contributor

As translator, I love to find translation files with up-to-date source strings, not having to run commands to check whether there are new ones. So, I'm in favor of having some kind of automation for this.

One solution that comes in my mind is a GitHub Actions workflow triggered on push event to master branch (or scheduled to run once per week, etc.), that runs make gettext and pushes latest source strings to Zanata translation platform.

The downside of this is that the commit history would be more polluted with translation updates. Running this workflow once per week might not be that bad, though.

Another solution that avoids pollution in this repository's commit history is to have translations infraestructure in a separated branch in the same repository (just like packaging.python.org did) or separated repository for translations (like First Robotics Competition documentation and in Django docs)

@TingPing
Copy link
Member

TingPing commented Oct 20, 2022

If anybody has time to add automation via Actions I'd love it.

I think we can avoid adding the complication of splitting up branches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants