Hi Mario,

glabels-qt being a free software is more than welcome in Fedora Weblate.

Are you maintainer of glabels-qt? It is important that a maintainer of the project is aware and agrees on using this translation platform considering that this is a change in the workflow and a few settings need to be done.

Please also check https://docs.fedoraproject.org/pt_BR/localization/hosting/#_request_a_new_translation_project_on_fedora_weblate for extra information needed, followed by the webhook URL to set in the GitHub repo.

I'm the translation coordinator for years – since glabels 3.x development has been abandoned and switched to Qt. The maintainer ist Jaye Evins (evins@snaught.com). He is aware of this change; I'll write to him again. See https://github.com/j-evins/glabels-qt/issues/271, which has triggered the move.

Rather than pushing directly to the glabels-qt github repo, can this be configured to create pull requests instead?

-Jaye

We don't need to push anything directly. I assume Weblate is able to update the translation templates automatically in the background, as Transifex does. So the templates are always up-to-date. From time to time (after some significant changes in the translatable strings), I can update the translation files in a temporary branch in my Github fork, and then create a pull request into your master branch.

Weblate does support direct push, GitHub pull request and no push at all (manually pull with wlc CLI tool). See https://docs.weblate.org/en/latest/admin/continuous.html#push-changes

It also features:
- updating templates (.pot files) whenever there is a change in the upstream repository if such repository has webhook set (Please set https://translate.fedoraproject.org/hooks/github, see https://docs.weblate.org/en/latest/admin/continuous.html#github-setup)
- updating translation files (.po files) once the template is updated

Both are optional based on the project workflow, although it is very common to see it enabled for a continous localization

Would you like to translate man-page translation as well? I see a translation project in Transifex for man pages. Since it is written in Sphinx, Weblate supports it as well.

Would you like to translate man-page translation as well? I see a translation project in Transifex for man pages. Since it is written in Sphinx, Weblate supports it as well.

Yes, some time ago I tested the behavior of python-sphinx. The resulting .pot file I sent to Transifex. But man page translations are currently not implemented in glabels-qt. I'm working on a new sphinx-based user manual (.rst files), almost finished; maybe we can create a merged template from both user manual and man pages…? Or we provide separate components, doesn't matter.

@rffontenelle, thank you for your work! I've added a hint to the project description at Transifex that the project has been moved to Fedora Weblate. Let's wait a bit; if no more translations come in, I will remove the Transifex project.

So, I don't know if Weblate can automatically regenerate the source files (*_C.ts) and update the source strings in translation files for .ts files. I said before that it does, but I was referring to Gettext PO file, which obviously has nothing to do with glabels-qt (sorry).

At this moment, I don't know how to work around this situation in Weblate. This might require a GitHub Actions to automatically regenerate the files, or manually regenerate files and push to weblate via wlc CLI client.

So, just to be sure, we want to go with GitHub pull request?

Weblate is not able to update translations/TRANSLATION_FILES.txt with new languages, so enabling new translation files would require manual action on maintainer side.

However Weblate supports updating LINGUAS files (a file containing only language codes). Weblate can be set to have the same languages in both glabels and templates, so it is simpler maintaining the list of enabled languages. How about changing the build workflow to regenerate a translations/TRANSLATION_FILES.txt based on a LINGUAS file?

Alternatively, adding new languages can be blocked in Weblate and the translations instructions can point the translator to request via GitHub issues before they can translate it.

Here is a pull request demonstrating current configuration: https://github.com/j-evins/glabels-qt/pull/285

It includes translation from both 'glabels' and 'templates' components

Weblate is not able to update translations/TRANSLATION_FILES.txt with new languages, so enabling new translation files would require manual action on maintainer side.

However Weblate supports updating LINGUAS files (a file containing only language codes). Weblate can be set to have the same languages in both glabels and templates, so it is simpler maintaining the list of enabled languages. How about changing the build workflow to regenerate a translations/TRANSLATION_FILES.txt based on a LINGUAS file?

Alternatively, adding new languages can be blocked in Weblate and the translations instructions can point the translator to request via GitHub issues before they can translate it.

I should be able to work with a LINGUAS file.

This issue has been migrated to a new Fedora Forge at https://forge.fedoraproject.org/localization/tickets/issues/46.

On behalf of the Fedora Localization Team, I am sorry for any inconvenience caused and respectfully ask you, from now, to follow this request for a new translation project on Fedora Weblate within the new forge.