-
Notifications
You must be signed in to change notification settings - Fork 9
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
Switch to using Weblate #21
Comments
Happy to help |
I think the action point here for now is to create a feature request in Weblate for allowing the target repository to not have a language code in the filename pattern (second point from the list of blockers in the issue description). Point first and three should be possible to implement as GitHub Actions scripts. |
I've added proof-of-concept repository and successfully pushed the first change: https://github.com/m-aciek/python-docs-pl-weblate-poc (https://hosted.weblate.org/projects/python-docs/). I've updated original issue with refined points that still require an effort. I think of scripts being fired with GitHub Actions for both updating source strings and translations propagation. |
Translation propagation between components will be handled by Autotranslate add-on. Discovery for adding or removing components will be handled by Discovery add-on. |
According to this discussion setting up Autotranslate between projects (Python versions) is also possible. |
@m-aciek There is also the shared translation memory between other projects on Hosted Weblate, which can be turned on in Don't use CC0, it is not advisable. It is also not the license used for the documentation already.
from https://github.com/python/python-docs-pl/blob/3.10/copyright.po https://github.com/python/cpython/blob/main/LICENSE#L65 If you add "kingu" in https://hosted.weblate.org/access/remmina/#users I can see if I find other improvements to be made. :) |
I already found and did that 👍 . @comradekingu do you know if we add a separate project for Python 3.9 documentation translation, will we be able to set automatic propagation from Python 3.10 project? (Not only having a translation memory as a suggestions.) I wonder if this feature is visible when you have admin privileges to two projects (WeblateOrg/weblate#7200 seems to suggest that).
From what I understand the license of translations may be a bit different than the license of the original documentation. The PEP 545 suggests to use CC0. If needed we can/should discuss it further on Python documentation Discourse section.
Sure, I've added you as an administrator. |
The setup worked just fine, but the grace period timed out. @m-aciek |
According to this comment by nijel, our request would be put down, at least until WeblateOrg/weblate#7271 is done.
Do you maybe have some external resource with the critique of CC0 in a context of similar works like this translation? I'd be keen to get to know more. For what it's worth on main branch of this repository I started trying to put together a GitHub Action to update translations source strings. |
https://rd-alliance.org/sites/default/files/cc0-analysis-kreuzer.pdf It always stops at the "what did you think you were doing" stage, and it is never popular, with nobody using it for collaborative works at scale, or with success at a smaller scale. I couldn't find the one that hits the nail on the head, but basically moral rights can't be waived in some jurisdictions, https://www.gnu.org/licenses/license-recommendations.html is a particularly bad recommendation, and they also championing waiving copyright for translations. |
Another blocker (?) on Weblate side: WeblateOrg/weblate#263. |
How about presenting to all translation teams a migration to a single workflow using Weblate? If accepted by teams and by Python core devs, this would eliminate per-team customized scripts and would land translations directly in the main repository (or another suffixed with e.g. "-doc-translations" of their choice). For PyPA (PyPI website/warehouse and the packaging guide) it is working fine. One thing I know is that French teams gives great importance to FLOSS, so the Hosted Weblate linked with several machine translations might be a problem. So self-hosted weblate could be a solution. I wanted to present a proof-of-concept of a Weblate instance for python docs translations using Yunohost, but never went further. |
That would require an update in PEP 545, which now includes per-language repositories.
Would French team be keen to enable machine translations on self-hosted Weblate? In my opinion ML suggestions are a must-have in a modern translations workflow. On the other hand even shared repository could be used through Weblate only as opt-in (I mean PR flow without a service could also work there). I started looking into Weblate core, to see how much of a hassle would be to allow multiple single-language Git repositories for a project. It's quite a big change (to the core models), but according to Weblate creator it would be accepted. |
Using a single workflow would probably mean eliminating the per-language repository, indeed. So if not all teams agree, that indeed would be a blocker. But I think it worth the shot to simplify and centralize the translation maintenance.
I don't know, but I assume they are not. I'm saying this because French moved from GitHub (now a mirror) to AFPy Gitea-based repo, and something else I don't recall right now. If I'm wrong, great, Hosted Weblate is a go. Fedora migrated to Weblate and because they give great importance to FLOSS, they opted to self-host Weblate and to have machine translation disabled (i.e. not linked to Google, Microsoft, etc.).
If at least we can make this work, I'd love to migrate to Weblate. Count me in. |
I realized we could use Weblate "as is" by creating a repo like "python-docs-weblate" to use it as a "Weblate backend" and fetch the translations to the current repositories e.g. using weblate CLI or Python API. It would allow us to use translation memory (through global translation memory on Hosted Weblate). We would need to create separate Weblate projects for different Python versions with separate users management (until WeblateOrg/weblate#263 is done). We would preserve current authorship tracking style in the languages repositories (PO header with translators list). I've created the repo and a project on Hosted Weblate for the POC (again, but with different approach this time). I will try to prepare the "client's" scripts (for the "mirrors") in the python-docs-pl-weblate-poc repository soon.
According to Weblate's policy for open-source we'd need to eventually move python-docs-weblate into Python organization on GitHub to have the project approved on Weblate. (The trial is for 14 days.) |
I think we might not get accepted in libre hosting because its limits are the same as Advanced Plan: 10k source strings and we have 24K+. See table and libre hosting right below the table in https://weblate.org/hosting/ |
@m-aciek How did you create the components for your language? I'd rather not do it one by one. :D |
Ah, I see that there's that "libre has the same limits as advanced plan". Hm, we might need to reach out directly to Michal and ask for dedicated plan. 🤔
I have put all PO files into the "backend" repository in the current state from the language repo. Weblate should just recognize a new language for component being added and display it inside the existing components. We also have autodiscovery plugin enabled, so in case of a new component it should be created in Weblate automatically. |
Agreed. Considering that this is not a high demanding project (lots os change, lots of translators working at the same time, I assume this will not result in a high resource consumption of Hosted Weblate resources. So worth the shot. One thing I had in mind would be to ask PSF sysadmins to host a Weblate instance. Maybe this would allow as to improve the resources organization in different projects (not sure how and if it would help anyhow, but just saying). |
Nice, as I said about the string limit, Billing Overview says "Used 56,499 of 10,000" |
Please avoid CC0, it generally does nothing, and when it does it is incompatible across jurisdictions. Just use what the source is licensed as, and drop the CLA. Keep it snimple. |
@comradekingu Actually, CC0 and the CLA are requirements from PEP 545: https://peps.python.org/pep-0545/#setup-the-documentation-contribution-agreement |
That wouldn't be any different from the core problem.
and then
which is a tiny problem that hasn't produced an actual problems for the other projects yet. The link doesn't say "license" agreement. If it is OK enough to just put it in a README, making it so that everyone has to actively click through it is a hurdle. |
Please check the context of the quoted string. PEPs normally have some rationale and proposed changes before they conclude with specific commands. By "commands" I mean the contents in the section New Translation Procedure section in PEP545. It looks like Apache and MIT were considered, but they ended making CC0 mandatory with that CLA text. https://devguide.python.org/documentation/translating/ confirms this in the list item "Each translation is under CC0 and marked as such in the README (as in the cookiecutter)." |
@rffontenelle Maybe Docs WG monthly meeting would be a good place to start this conversation?
@comradekingu Would you care to create a thread on Python forum about modifying the license part of PEP 545? I think that would be the way to go with it further.
FYI I've requested the hosting for the (first) project through the Weblate billing module, and still waiting for the response. |
I've got the response from the Weblate representative.
I'll try to move the discussion about the topic to Python forum for the broader audience. |
Transifex:
One of options is to switch to Weblate (which supports both machine translations as suggestions and global translation memory propagation). Weblate has very good version control system integration – this switch would also solve #14 plus would remove the necessity of maintaining scripts to fetch the translations.
This issue is to track blockers for migrating the translation project to Weblate.
as we would set up a project per Python stable version, we'd like to have working translation propagation between the projects
The text was updated successfully, but these errors were encountered: