Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
please migrate to the new Fedora translation platform
[optional] do you have any announcement/warning you would like to display to the translators? (it will be displayed in Weblate)
[optional] do you need us to activate any specific checks? (this is a setting per component [3])
[optional] do you need us to automatically detect new translation files? (typical usecase: website translation with one translation file per page)
Please note:
For github and gitlab hosted projects, Weblate open pull request. For other project, you'll have to add a key to allow commits.
In Weblate's vocable, one project is a group of component. Each component is a translation file. You can have many projects or many components or both.
This tool directly interact with your git repository, and requires us to know:
What does "directly interact" mean? If you mean that Weblate reads from the git repository, then OK, but if you mean that Weblate directly writes to the git repository, then you seem to be confused. This is the upstream PulseAudio project, not affiliated with Fedora.
(But if you'd like to set up Weblate for PulseAudio upstream, that would be very welcome, because the current translation workflow involves sending patches manually, which isn't very translator friendly.)
[mandatory] which branch is your development branch?
master
[mandatory] have you merged latest translation from Zanata and locked the project?
I have no idea what's happening in Fedora's Zanata. We're not affiliated with Fedora.
[optional] do you need us to activate any specific checks? (this is a setting per component [3])
I don't know. Maybe that means "no".
Sorry, I didn't notice the reference to the Weblate documentation about the checks. Many checks seem sensible. I would enable these checks:
Unchanged translation
Starting or trailing newline
Starting spaces
Trailing space
Double space
Trailing stop
Trailing colon
Trailing question mark
Trailing exclamation
Punctuation spacing
Trailing ellipsis
Trailing semicolon
Maximum length
Formatted strings
C format
Placeholders
Regular expression
Missing plurals
Same plurals
Inconsistent
Has been translated
Mismatched \n
Zero-width space
URL
I'm not so sure about these:
Python format - There's the qpaeq GUI that is written in Python, but it probably doesn't currently have translation support set up. I'd enable this anyway if it doesn't do any harm.
[optional] do you have any announcement/warning you would like to display to the translators? (it will be displayed in Weblate)
I guess it would be good to make clear what the relationship with upstream is.
Also, if translators see problems with the source strings or Weblate gives stupid warnings, such issues should be reported in the appropriate GitLab project (pulseaudio, pavucontrol or paprefs).
In Weblate's vocable, one project is a group of component. Each component is a translation file. You can have many projects or many components or both.
I think there should be one project for pulseaudio, another for pavucontrol and third for paprefs. I don't think we need more than one component per project.
Yes, using the Fedora translation is an upstream decision. You are welcome to use it explicitly as the place for all upstream contribution.
Please note: as weblate will interact with your git repo (using direct commits or pull requests, as you wish), any change to a po file will create git conflicts.
This means, pot updates will be propagated to existing po files by weblate itself. Contributors can upload a full po files if they wish to translate offline or did not know about weblate.
Thank you for the offer to set up Weblate for us! I think this is great and we should definitely use your service, but I'll need to ask @arun's and @gchini's opinion too.
Is it so that even though Fedora maintains the translation setup, there's really nothing Fedora specific in the translations? You're translating the upstream master branch, not the version in Fedora?
If we have issues with the Weblate setup or otherwise need to contact the translation service maintainers, where to go? Should we email you, or is there some mailing list, or something else?
Regarding pot files - I'm not that familiar with how gettext works, but I know we don't have pot files in git. Can Weblate generate them by itself?
Contributors can upload a full po files if they wish to translate offline or did not know about weblate.
I'm not sure what you mean here. Do you mean that it's ok for contributors to send po files directly to us and we can apply them outside Weblate, or do you mean that contributors can upload po files to Weblate?
If we have issues with the Weblate setup or otherwise need to contact the translation service maintainers, where to go? Should we email you, or is there some mailing list, or something else?
Is it so that even though Fedora maintains the translation setup, there's really nothing Fedora specific in the translations?
Fedora guideline is: upstream first. Yes, we'll only translate what you publish, nothing else.
You're translating the upstream master branch, not the version in Fedora?
Yes, only upstream branch.
But if you maintain multiple version in parallel, and wish to push translations updates, it's fine for us. We can do that too. For example, anaconda, our installer, has one master branch, and one per OS version it supports. You should do only what makes sense to your way of diffusion your software.
Regarding pot files - I'm not that familiar with how gettext works, but I know we don't have pot files in git. Can Weblate generate them by itself?
I'm not sure what you mean here. Do you mean that it's ok for contributors to send po files directly to us and we can apply them outside Weblate, or do you mean that contributors can upload po files to Weblate?
They should use Weblate only, they'll be able to upload the file.
While it change nothing for the one uploading the file or you as a maintainer, it informs every translator of the changes and who did it. It will be fully integrated in Weblate's history, which makes our work way easier.
I think we can commit the pot file to the repository and update it every now and then (I don't want to update it in every commit). The "mini.po" approach of libvirt sounds interesting, but I don't think I have motivation to pursue that right now.
Can I choose the squashing mode? I'd like to have "per author" to keep the copyright status of the translations more clear. How does Weblate decide when to open a merge request? If one author does several changes, at what point is the merge request created?
Regarding Zanata and PulseAudio, in the past someone set up a project on Fedora’s Zanata instance to translate a RHEL package of PA. I don’t know how that worked out, but this is how we got here. :)
As for me, I can definitely work on PA translations on Fedora’s Weblate server.
if you never did it in the past, I suggest you to pull zanata files in a separate repository and to use msgcat. For each zanata po file, if the file exists in pulseaudio_po_folder, then run msgcat --use-first "pulseaudio_po_folder/
How do I pull the zanata files? Is there a git repository? I couldn't find other ways to download the translations than downloading the po files one by one.
I wonder if the translations in Zanata are worth out time. They’re against a very old version, and the PulseAudio project on Zanata wasn’t really advertised outside the RHEL group that not many Fedora translators work on. It might be the case that translations sent through patches and MRs are more complete and up to date.
It looks like this is going to take a fair bit of manual work anyway, so it doesn't make that much difference that I need to manually copy the .po files from the Zanata web page. So far I've checked 4 translations: as, bn_IN, bg and ca. Out of those as and bn_IN didn't contain any new translations, but bg was a completely new translation and ca was more recent than what we have upstream.
I think it still makes sense to go through the Zanata translations and take what is easy to take. I have patches for bg (new language) and ca (new translated strings). There are still 34 languages to check before I'll submit the patches.
Weblate will open PR when new contributions are committed.
Weblate will squash commits per author inside the PR.
Weblate will update LINGUAS when new languages are added.
Weblate will update po files each time you update the pot file.
No user is made admin yet, please provide your usernames (just connect once to the translation platform so I can see you).
I should have the preparations for the main pulseaudio repository finished soon.
@arun, @gchini: If you want admin rights for Weblate, log in to translate.fedoraproject.org (if you don't have a Fedora account, you'll need to create one).
Could not push the repository.Weblate could not push changes to the upstream repository.2020/02/18 15:38:43 fork.go:55: gitlab project not found, verify you have access to the requested resource (1)6 days ago
So, tiny bad news here.
We discovered Weblate can interact with gitlab, but only the one of gitlab.com... Because of the tool they use to open the Pull request.
The single impact: Weblate can't open pull request directly on your repository.
All other features works as expected. Translators can work, they get latest changes from your repositories.
@jibecfed, can something be done about the paprefs alert I mentioned ("Could not push the repository")? Why is there an alert only for paprefs and not for pavucontrol?
Thanks for removing the error! Unfortunately, the same error seems to be back.
I'm done with !256 (merged). Yuri Chornoivan (@yurchor) seems to have added PulseAudio to Weblate now too. Is there anything left to do, or can this be closed?