Re: [Fedora Weblate] New comment in ibus-typing-booster/app
by Mike FABIAN
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>
睡眠不足はいい仕事の敵だ。
4 years, 2 months
Fwd: Re: DNF and Anaconda ask to delay Zanata migration in March
by Jean-Baptiste
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
>
4 years, 2 months
Conflict issues with WebLate translations for libosinfo projects
by Fabiano Fidêncio
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/#ale...
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
4 years, 2 months
Re: DNF and Anaconda ask to delay Zanata migration in March
by Jean-Baptiste Holcroft
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
4 years, 2 months
DNF and Anaconda ask to delay Zanata migration in March
by Jean-Baptiste Holcroft
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
4 years, 2 months
Unable to upload POT file to any libvirt project component
by Daniel P. Berrangé
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 :|
4 years, 2 months
Info for a new organizer
by Luigi Votta
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
4 years, 2 months