Proposal: reorganizing i18n

Pablo Roberto Lezaeta Reyes prflr88 at
Tue Oct 10 02:34:18 CEST 2017

> On Tue, Oct 10, 2017 at 1:08 AM Vinzenz Vietzke <vinz at> wrote:
>> Hi there,
>> I recently went through many parts of Xfce's i18n infrastructure and
>> documentation. To make it short: lot's of old stuff, many things
>> unmaintained but truly a lot of useful gems grown throughout the years.
>> So following up is my proposal for reorganizing i18n in Xfce, split into
>> two phases. I put it up on this list to reach more people.
>> A. Short term
>> 1. Dump mailing lists. One list (xfce-i18n) is enough and for
>> language-specific questions, discussions a short [LANG] tag added to the
>> email topic should do the distinction job.
>> Bonus: questions might be answered quicker as more people read them.
​Yes, 1 Mailist is enough and most (just most not all) project I know use
only one.​

>> 2. Before dumping email all lists subscribers directly and (of course)
>> telling them about. Plus asking them if they are on this list alread
>> and, which is even more important, if they would like to help out on
>> Transifex.
​There are cases of Transifex contributors not in any of the lists so if is
possible send a mail
to the contributos on transifex too could help them know that there is a
maillist or see that is
encouraged to at least be part if it.​

> 3. Transifex needs coordinators for every language. If there is no one
>> coordinating a language there should be some "super-coordinators" as
>> backup. These persons shouldn't be devs or at least not core devs.
>> Stacking work leads to problems.
​Yes a super-cordinator could go in hand since there are some languages
without cordinators
as you mentioned, also there are cordinators that are MIA too.​

> B. Long term (mostly RFC)
>> 1. Ease up the introduction process. Someone dropping by at Transifex
>> sees the need of some translation work in his language. If he decides to
>> register at TX, to join team *and* do work: yeah, cool!
>> But forcing him to additionally join the mailing list and introduce
>> himself is a major blocking thing. I guess it's something from the
>> pre-Transifex days where quality assurance had to be done manually. But
>> with the split of translators & reviewers over TX this should be obsolete.
​Well so far many aren't arealdy on the mailist so dropping it is ok.​

> 2. Wiki needs clean up. There are lots of really, really useful things.
>> But as well there is lots of ancient, outdated stuff. Unfortunately most
>> stuff is mixed so there needs to be manual work done.
>> TBD: a process of cleaning up, either dumping everything and rebuilding
>> or the other way around.
>> ​​
​Wiki just need a way to anyone to contribute, I have tryed sign-in,
log-ing but i failed... is
somewhat ​looked or need special permissions?

> 3. Revise the use of Transifex. It's not self hosted and it's
>> proprietary but it does the job. There are up- and downsides of it so in
>> the light of the Git hosting discussion TX should also be reconsidered
>> *openly*.
​I still remember why we move to transifex.
"Was because the self hosting was becoming so time consimong and we havent
updated the stuff and it was breaking" or something like that...
Returning to self host will be like return to the same thing that we move to
reduce the burder over the maintainers.

Also I thing with all we could ended trying to chew more that our maws can
handle, so
better see how the git-self-host-move go and then evaluate the option and
the option​s of move
and where to move with the translations.

> Generally speaking I'd step up for both doing "dirty jobs" as well as
>> coordination work.
>> Thanks for your time reading this!
>> Looking forward to your comments,
>> vinz.
>> --
>> | skyrocket your desktop usage
>> _______________________________________________
>> Xfce4-dev mailing list
>> Xfce4-dev at
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Xfce4-dev mailing list