I am sure, most of the people working with Fedora I18N, L10N from 5-6
year must be aware regarding Fedora L10N Steering Committee.  As far
as i know this committee was active around 2009 and very effective.
During Fedora G11N activity day discussions, we again felt there is
need for some kind of official committee to drive Fedora Globalization
activities. Fedora is growing faster with number of different domains
and G11N also need to adapt those changes quickly to remain on the track.
For this purpose and in line with , we were thinking of Fedora
Globalization steering committee. I have created initial proposal for
Its open for feedback, please feel free to share other active members,
discuss in your respective language groups. This is just initial
proposal and i am sure, we can improve and make it more effective with
g11n mailing list
I tried to create a new project in Weblate, but got an error saying I don't
have permissions to do so.
It was possible for anyone to create new projects in Zanata. Is this a new
workflow? If so, is there some process how to request new projects?
(opening ticket somewhere...?)
It would be really helpful if we keep project structure as:
1 source repo : 1 weblate project : 1 fedora package
Project components could be either
- fedora releases f32 f33, or
- git branches, or
- upstream releases
Dear translation team,
we are experimenting Weblate for a few months now.
It's time to say if you feel confident the tool can allow us to do our
job as a translation community.
Please share the language in which you translate and answer:
+1 to confirm Weblate is suitable for the Fedora translation community
+0 is sometimes used to indicate a disagreement but willingness to stand
aside, this should also be accompanied with an explanation
-1 to disagree, this should also be accompanied with an explanation
GO is if the sum of answer is greater than zero.
Please note: you can +1 and share your feedback about what is good and
what is to improve in Weblate.
Ludek, please use this UI to register to the mailing list:
You can also respond without registering using the same URL.
>>> 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.
> Absolutely. We are pushing our translations to Zanata/ Weblate approx.
> 4 times a year during the RHEL 7 and RHEL 8 localization schedules.
> Our scope is limited though, we focus on customer critical components
> such as: installation (anaconda, dnf), administration (cockpit,
> composer), storage, networking, selinux, comps.
Good, then, I should be able to create a component list for these
projects to make it easier to find.
> This is something which needs to be coordinated with the respective
> RHEL sub teams. If you need, I can provide you with contact
> information but I am no the person who has access to their git
> repositories, unfortunately.
What you can do: go in this list of issues to tell the team they can
migrate if they make sure it won't impact RHEL 8 localization schedules:
I'm unsure of what you call "storage" and "networking":
I have blivet in storage category:
Could you provide a more precise list?
selinux looks like to have one fork per platform, I feel like we should
probably merge the effort upstream instead of translating multiple time
the same content:
Could you contribute or invite RH dev team to contribute the discussion?
Another answer out of mailing list.
-------- Courriel original --------
Objet: Re: DNF and Anaconda ask to delay Zanata migration in March
Date: 2020-01-21 11:05
De: Luděk Janda <ljanda(a)redhat.com>
À: Jean-Baptiste Holcroft <jean-baptiste(a)holcroft.fr>
Cc: 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>,
Hi Jean-Baptiste, I am afraid my messages don’t get to the Fedora
translation project list because I am not subscribed there.
> On 20.01.2020, at 10:19, Jean-Baptiste Holcroft
> <jean-baptiste(a)holcroft.fr> wrote:
> 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?
I am comparing workloads in Zanata vs Memsource (our internal platform),
because we used to get PO files from Zanata. We had no experience with
Weblate till recently, that’s why I don’t have the comparison numbers
ready for that new platform.
>> 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
> 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?
Weblate is currently checking for example Leading/trailing colons,
periods etc. We are checking only Leading/trailing spaces. Weblate is
checking plurals in Asian languages, I wonder why because those
languages have no plurals. Checking missing plurals in French in words
such as fois, mois, etc does not make much sense either. Weblate is
checking English words in the target language which is also a sort of
annoyance in UI projects. We won’t be probably able to perform such
detailed check in Memsource.
>> 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.
Absolutely. We are pushing our translations to Zanata/ Weblate approx. 4
times a year during the RHEL 7 and RHEL 8 localization schedules. Our
scope is limited though, we focus on customer critical components such
as: installation (anaconda, dnf), administration (cockpit, composer),
storage, networking, selinux, comps.
Our aim is to have 100% Japanese completed. But partially we are
covering the other strategic languages too: Chinese (China), Korean,
French. It’s great to see our translations could be reused by the
> 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
> 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
> 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
This is something which needs to be coordinated with the respective RHEL
sub teams. If you need, I can provide you with contact information but I
am no the person who has access to their git repositories,
> We have much to learn from each other.