trans January 2020

trans@lists.fedoraproject.org

31 participants
32 discussions

Info: new URL for Weblate is translate.fedoraproject.org
by Jean-Baptiste Holcroft 21 Jan '20

21 Jan '20

Dear translators, as you all gave your support to using Weblate in production, the URL will change. You don't have anything to do as a redirection will be done. New URL: https://translate.fedoraproject.org/ Previous URL: https://translate.stg.fedoraproject.org/ This may impact some automation if someone use the API to interact with Weblate. If so, only the URL has to be changed. As far as I know, no upstream project is using API. All other automation should have no change, please let me know if some action is required. Have a nice day, Jean-Baptiste

3 2

Re: [Fedora Weblate] New comment in ibus-typing-booster/app
by Mike FABIAN 20 Jan '20

20 Jan '20

Adolfo Jayme Barrientos <noreply(a)weblate.org> さんはかきました: > ## Source string > > translator-credits > > ## Comment > > **[@mfabian](/user/mfabian/ "Mike FABIAN")** : please remove the character > limit in this string; it’s nonsensical. I stumbled over this as well, I don’t know where this limitation comes from, I didn’t set any limitation. I would remove it if I knew how to do it. -- Mike FABIAN <mfabian(a)redhat.com> 睡眠不足はいい仕事の敵だ。

3 5

Fwd: Re: DNF and Anaconda ask to delay Zanata migration in March
by Jean-Baptiste 20 Jan '20

20 Jan '20

Somehow, this message isn't available in translation mailing list history. People can't read the message I'm answering to. Here is a forward for archive purpose. -------- Message transféré -------- Sujet : Re: DNF and Anaconda ask to delay Zanata migration in March Date : Mon, 20 Jan 2020 04:37:33 +0100 De : Luděk Janda <ljanda(a)redhat.com> Pour : Jean-Baptiste <jean-baptiste(a)holcroft.fr> Copie à : duffy(a)fedoraproject.org, Fedora Translation Project List <trans(a)lists.fedoraproject.org>, Matej Marusak <mmarusak(a)redhat.com>, jkonecny(a)redhat.com, Michal Konecny <michal.konecny(a)packetseekers.eu>, mblaha(a)redhat.com <mblaha(a)redhat.com> Hi Jean-Baptiste, I think I answered already on 15 February. My copy pasted answer from that day follows. Let me know if you need anything else you need to clarify from me. Thanks, L Hi all, > On 15 Jan 2020, at 08:19, Matej Marusak <mmarusak(a)redhat.com > <mailto:mmarusak@redhat.com>> wrote: > > > > On Tue, Jan 14, 2020 at 9:45 PM Jean-Baptiste > <jean-baptiste(a)holcroft.fr <mailto:jean-baptiste@holcroft.fr>> wrote: > > Le 14/01/2020 à 16:25, jkonecny(a)redhat.com > <mailto:jkonecny@redhat.com> a écrit : > > Translators in RHEL using their tools. One of the benefit is > that this > > way they can share translations between products. That is not > possible > > in Weblate as far as I understand. > > I feel that this assumption is wrong, or requires more details. > That’s just a small misunderstanding. We prefer to translate in our internal platform because this way we can share RHEL UI translation memory with other projects such as RHEL documentation, our translators working on docs can easily verify the appropriate UI strings translation when necessary. We can also leverage easier our past translations from other projects / other RHEL components. I do not have numbers for Weblate, but comparing Zanata with our internal platform - when sharing TM in our internal platform we are to reduce workload by ~20% (e.g. Cockpit in Korean, Zanata workload: 1107, Memsource workload: 802). We also have access to our MT engines (DeepL) that speed up delivery. Etc. > Anyway, it looks like Ludek Janda was able to import a list of files > easily: https://translate.stg.fedoraproject.org/changes/?user=ljanda > > Hey all, > I would like to mention our experience with this migration. (not the > migration itself, that is a long story as we did not like the "common" > weblate workflow) > I migrated 3 Cockpit projects from Zanata to Weblate last week not > realizing that there is a translation phase going on. > Yesterday Ludek pushed updates into Zanata. So I talked to him and > learned that they don't use Zanata as translation platform - they just > pull source file from it and push translated files there. > Although I agreed that they can finish this phase in Zanata and then I > would do a manual sync into Weblate, Ludek tried Weblate and said it > was easy to push there, so he did exactly that. > > So yes, he was able to do that, but it is important not to break their > workflow in the middle of a translation phase. But after he tried > Weblate yesterday, maybe he would be willing to do this also for other > projects? Yeah, it was surprisingly easy, thanks, Matej, for giving me that opportunity. Challenging part seems to be the GA check. I will need to align our internal QA tools to highlight the same errors as in Weblate. Because Cockpit and Composer already moved to weblate, we can definitely finish our translations there. But in general I would really prefer to have RHEL 8.2 translation cycle finished first (18 February) and migrate after that. The list of affected components (with some translation work in 8.2) * anaconda * cockpit * composer * dnf * dnf-plugins-core * libdnf * NetworkManager * policycoreutils * pykickstart * setroubleshoot-plugins * sssd * subscription-manager * syspurpose Thanks, Ludek > On 17.01.2020, at 19:23, Jean-Baptiste <jean-baptiste(a)holcroft.fr > <mailto:jean-baptiste@holcroft.fr>> wrote: > > Ludek, as RHEL Localization Manager and the one asking to DNF and > Anaconda to delay migration, could you please answer the different emails? > > > I see no reasons to delay, and ask you the help us in this migration > by being an enabler: telling all Red Hat teams to fully support this > community effort. > > > Added in CC, Mairin as FCAIC. > > > Le 15/01/2020 à 08:19, Matej Marusak a écrit : >> >> >> On Tue, Jan 14, 2020 at 9:45 PM Jean-Baptiste >> <jean-baptiste(a)holcroft.fr <mailto:jean-baptiste@holcroft.fr> >> <mailto:jean-baptiste@holcroft.fr>> wrote: >> >> Le 14/01/2020 à 16:25, jkonecny(a)redhat.com >> <mailto:jkonecny@redhat.com> >> <mailto:jkonecny@redhat.com> a écrit : >> > Translators in RHEL using their tools. One of the benefit is >> that this >> > way they can share translations between products. That is not >> possible >> > in Weblate as far as I understand. >> >> I feel that this assumption is wrong, or requires more details. >> >> Anyway, it looks like Ludek Janda was able to import a list of files >> easily: https://translate.stg.fedoraproject.org/changes/?user=ljanda >> >> Hey all, >> I would like to mention our experience with this migration. (not the >> migration itself, that is a long story as we did not like the >> "common" weblate workflow) >> I migrated 3 Cockpit projects from Zanata to Weblate last week not >> realizing that there is a translation phase going on. >> Yesterday Ludek pushed updates into Zanata. So I talked to him and >> learned that they don't use Zanata as translation platform - they >> just pull source file from it and push translated files there. >> Although I agreed that they can finish this phase in Zanata and then >> I would do a manual sync into Weblate, Ludek tried Weblate and said >> it was easy to push there, so he did exactly that. >> >> So yes, he was able to do that, but it is important not to break >> their workflow in the middle of a translation phase. But after he >> tried Weblate yesterday, maybe he would be willing to do this also >> for other projects? >> >> MM >

1 0

Conflict issues with WebLate translations for libosinfo projects
by Fabiano Fidêncio 20 Jan '20

20 Jan '20

We've migrated to using WebLate a week or so ago and we've been facing some issues related to merge conflicts, probably due to some misconfiguration on our side, which we'd need some help to solve. Firstly, we're receiving MRs on our GitLab directly changing po/*po files. is that expected? If so, what would be the best way to: 1) Avoid things like https://translate.stg.fedoraproject.org/projects/libosinfo/libosinfo/#alert… 2) If we fail to avoid such, what would be the best way to have them solved without actually doing a merge? libosinfo projects do *not* use merge, just rebase is used. Last but not least, I've failed to understand what's the best way to use `wlc` command line tool. `wlc lock` just returns me "Error: No object passed on command line!". But what shall I pass? `wlc lock --help` tells me that: "object Object on which we should operate (project, component or translation)". `wlc lock $project_name` just returns me a bunch of errors like: ``` fidencio@laerte ~/src/upstream/libosinfo $ wlc lock libosinfo Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 157, in _new_conn (self._dns_host, self.port), self.timeout, **extra_kw File "/usr/lib/python3.7/site-packages/urllib3/util/connection.py", line 84, in create_connection raise err File "/usr/lib/python3.7/site-packages/urllib3/util/connection.py", line 74, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 672, in urlopen chunked=chunked, File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 387, in _make_request conn.request(method, url, **httplib_request_kw) File "/usr/lib64/python3.7/http/client.py", line 1252, in request self._send_request(method, url, body, headers, encode_chunked) File "/usr/lib64/python3.7/http/client.py", line 1298, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/usr/lib64/python3.7/http/client.py", line 1247, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/usr/lib64/python3.7/http/client.py", line 1026, in _send_output self.send(msg) File "/usr/lib64/python3.7/http/client.py", line 966, in send self.connect() File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 184, in connect conn = self._new_conn() File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 169, in _new_conn self, "Failed to establish a new connection: %s" % e urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7fe76b9e5610>: Failed to establish a new connection: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 449, in send timeout=timeout File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 720, in urlopen method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2] File "/usr/lib/python3.7/site-packages/urllib3/util/retry.py", line 436, in increment raise MaxRetryError(_pool, url, error or ResponseError(cause)) urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='127.0.0.1', port=8000): Max retries exceeded with url: /api/projects/libosinfo/ (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe76b9e5610>: Failed to establish a new connection: [Errno 111] Connection refused')) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/bin/wlc", line 10, in <module> sys.exit(main()) File "/usr/local/lib/python3.7/site-packages/wlc/main.py", line 703, in main command.run() File "/usr/local/lib/python3.7/site-packages/wlc/main.py", line 567, in run obj = self.get_object() File "/usr/local/lib/python3.7/site-packages/wlc/main.py", line 280, in get_object obj = super(ComponentCommand, self).get_object() File "/usr/local/lib/python3.7/site-packages/wlc/main.py", line 262, in get_object return self.wlc.get_object(path) File "/usr/local/lib/python3.7/site-packages/wlc/__init__.py", line 145, in get_object return self.get_project(path) File "/usr/local/lib/python3.7/site-packages/wlc/__init__.py", line 150, in get_project return self._get_factory("projects", path, Project) File "/usr/local/lib/python3.7/site-packages/wlc/__init__.py", line 131, in _get_factory data = self.get("/".join((prefix, path, ""))) File "/usr/local/lib/python3.7/site-packages/wlc/__init__.py", line 118, in get return self.request("get", path) File "/usr/local/lib/python3.7/site-packages/wlc/__init__.py", line 82, in request r = self.invoke_request(method, path, params, files) File "/usr/local/lib/python3.7/site-packages/wlc/__init__.py", line 104, in invoke_request files=files, File "/usr/lib/python3.7/site-packages/requests/api.py", line 60, in request return session.request(method=method, url=url, **kwargs) File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 533, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 646, in send r = adapter.send(request, **kwargs) File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 516, in send raise ConnectionError(e, request=request) requests.exceptions.ConnectionError: HTTPConnectionPool(host='127.0.0.1', port=8000): Max retries exceeded with url: /api/projects/libosinfo/ (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe76b9e5610>: Failed to establish a new connection: [Errno 111] Connection refused')) ``` So, I've been using the WebUI but would be nice to understand the workflow of the CLI tool. Best Regards, -- Fabiano Fidêncio

3 5

Re: DNF and Anaconda ask to delay Zanata migration in March
by Jean-Baptiste Holcroft 20 Jan '20

20 Jan '20

Le 2020-01-20 04:37, Luděk Janda a écrit : > That’s just a small misunderstanding. We prefer to translate in our > internal platform because this way we can share RHEL UI translation > memory with other projects such as RHEL documentation, our translators > working on docs can easily verify the appropriate UI strings > translation when necessary. We can also leverage easier our past > translations from other projects / other RHEL components.I do not > have numbers for Weblate, but comparing Zanata with our internal > platform - when sharing TM in our internal platform we are to reduce > workload by ~20% (e.g. Cockpit in Korean, Zanata workload: 1107, > Memsource workload: 802). We also have access to our MT engines > (DeepL) that speed up delivery. Etc. Thanks your answer. What is unclear here: you say you are not using Zanata internally and then compare Zanata vs Weblate. Could you please elaborate? Which tool are you using internally and how is it related to fedora.zanata.org? Is there RHEL requirements for translate.stg.fedoraproject.org? > Yeah, it was surprisingly easy, thanks, Matej, for giving me that > opportunity. Challenging part seems to be the GA check. I will need to > align our internal QA tools to highlight the same errors as in > Weblate. Good to see it was easy. Why would you like to "highlight the same errors as in Weblate"? What can of tests does the RHEL internal QA tools runs on a release? > Because Cockpit and Composer already moved to weblate, we can > definitely finish our translations there. > > But in general I would really prefer to have RHEL 8.2 translation > cycle finished first (18 February) and migrate after that. Could we turn things around and see the situation as an opportunity? Since I joined Fedora in 2015, I never had an opportunity to contribute a RHEL release, and being able to see RHEL translators' work/feedback always were really limited. Here, with your translation import for Cockpit in Weblate, I was able to see Red Hat contributions for the first time. I would love to: 1. see all projects to migrate to translate.stg.fedoraproject.org 2. announce your schedule in Fedora blogs so community contribute to RHEL From past translations I did, I consider 95% of translation done for RHEL are the same strings that what we have in Fedora. 3. see RHEL work imported back into translate.stg.fedoraproject.org 4. work with you a retrospective of this collaboration so we can improve To migrate a project to Weblate: * allow Weblate configuration: choose the git repository for Weblate that will handle pot and po files (it can be dedicated for translation or shared with source code) run `zanata pull` (using zanata python client) make sure there is no translation files with no translations (use pocount from translate-toolkit) from there, translation can start. load: about 30 minutes per project in your team and 10 minutes of configuration on my side * allow to package releases: change your make files load: a few hours for your teams to make sure all automation works well We have much to learn from each other. Jean-Baptiste

1 0

[Fedocal] Reminder meeting : L10N
by jibecfed＠fedoraproject.org 19 Jan '20

19 Jan '20

Dear all, You are kindly invited to the meeting: L10N on 2020-01-20 from 13:00:00 to 13:30:00 Europe/Paris At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Localization meeting https://www.timeanddate.com/worldclock/converter.html?iso=20190916T150000&p… More information available at: [https://fedoraproject.org/wiki/L10N/Meetings](https://fedoraproject.org/wik… Source: https://apps.fedoraproject.org/calendar/meeting/9620/

1 0

DNF and Anaconda ask to delay Zanata migration in March
by Jean-Baptiste Holcroft 17 Jan '20

17 Jan '20

Dear translators, Anaconda[1] and DNF[2] gave the same answer today: "Please can you delay migration and start after February 18? We are in the middle of RHEL 8.2 localization cycle, our team is working in Zanata and I want to minimize potential risk. Thanks." It kinda bothers me a little bit. Please share your thoughts. First assumption: the answer only concerns Anaconda and DNF projects. 1. Aren't we suppose to be upstream translation community for DNF and Anaconda? What does the RHEL localization cycle have to do here? Why March? 2. Fedora 32 schedule says string freeze is supposed to be reached at end of January [3] 3. Whatever external translators are helping RHEL: why wouldn't they be able to upload translations using Weblate? Same if centralized by a Red Hat employee. why wouldn't dev team use po merge features? 4. Migrating to Weblate for a translation team means to have a git repository to host translation, which only implies development teams Anyone with insights or advice on how to handle this? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1785028#c9 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1787204#c4 [3] https://fedoraproject.org/wiki/Releases/32/Schedule

5 5

Unable to upload POT file to any libvirt project component
by Daniel P. Berrangé 16 Jan '20

16 Jan '20

When we first setup the libvirt-glib project, I was able to use $ wlc upload --method replace -i libvirt-glib.pot libvirt-glib/master/en to upload the .pot file into the "en.po" file on the server, which was marked as the base language for translation. Since then, the libvirt-glib project was renamed, and libvirt & libvirt-sandbox were added as further components. Now when I try to upload the .pot, weblate is not accepting any of the strings. At first I thought I was still hitting the upload size limit, but debugging I see this is not the case. $ wlc upload --method replace -i libvirt-glib.pot libvirt-glib/master/en Error: Failed to upload translations! Despite failing, it *has* made some change in the git repository, because I now see this new commit: commit 56edd0b79dd3f4c296626afabaed67d04d56c1ed Author: Daniel P. Berrange <berrange(a)redhat.com> Date: Mon Jan 13 21:20:53 2020 +0000 Translated using Weblate (English) Currently translated at 0.0% (0 of 31 strings) Translation: libvirt/libvirt-glib Translate-URL: https://translate.stg.fedoraproject.org/projects/libvirt/libvirt-glib/en/ diff --git a/en.po b/en.po index a4e737c..750982c 100644 --- a/en.po +++ b/en.po @@ -1,9 +1,7 @@ # Libvirt package strings. # Copyright (C) 2019 The Libvirt authors # This file is distributed under the same license as the libvirt-glib package. -# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. -# -#, fuzzy +# Daniel P. Berrange <berrange(a)redhat.com>, 2020. msgid "" msgstr "" "Project-Id-Version: libvirt-glib 3.0.0\n" @@ -12,7 +10,7 @@ msgstr "" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL(a)li.org>\n" -"Language: \n" +"Language: en\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" In addition the weblate UI is reporting errors for libvirt-glib now [quote] Duplicated translation The component contains several translation files mapped to single language in Weblate. The following occurrences were found: Language Language codes English en, en Please fix this by removing one of the duplicated strings from the translation files. [/quote] The same has happened to the git repos for libvirt and libvirt-sandbox too. The error goes away if I put the project back to "gettext (monlingual)" but I'm still unable to upload the pot file to en.po again. I'm thinking about what has changed since I was first succesfully able to upload: - The project now has three separate components each with their own git repo - The "Automatic translation" and "Language consistency" addons have been installed My guess is that possibly the language consistency addon has caused the problem. I think perhaps it has tried to synchronize the "en.po" file across the three repos and this confused things, now preventing me treating it as the string base file. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

2 3

Info for a new organizer
by Luigi Votta 16 Jan '20

16 Jan '20

Hello I was a volunteer as an IT translator few years ago. In the meanwhile, some people gone and new are come, but as I can see, there is no active organizer at this time, to give rights and approvals for new comers. A volunteer proposed and self applied for this role. How are your groups organized? How can we assign him the necessary rights to go? Thank you in advance for informations. Luigi Votta

3 4

Fedora websites are now readonly in Zanata
by Jean-Baptiste 15 Jan '20

15 Jan '20

Dear translators, for your information, the Websites projects are now readonly in Zanata. Work is going on to migrate to Weblate, you can register to this issue if you want to follow-up or help: https://pagure.io/fedora-web/websites/issue/79 You are really welcome to help if you know scripting. Jean-Baptiste

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

trans January 2020