Proposal: reorganizing i18n
André Miranda
andre42m at gmail.com
Tue Oct 10 03:54:23 CEST 2017
These ones:
https://mail.xfce.org/mailman/listinfo/xfce-i18n-br
https://mail.xfce.org/mailman/listinfo/xfce-i18n-cn
https://mail.xfce.org/mailman/listinfo/xfce-i18n-de
https://mail.xfce.org/mailman/listinfo/xfce-i18n-fr
https://mail.xfce.org/mailman/listinfo/xfce-i18n-pl
Instead, keep only:
https://mail.xfce.org/mailman/listinfo/xfce-i18n
All in all, I agree with the proposal, except B3, there's enough
friction already about self-hosted/proprietary services, let's see how
we settle for the git hosting then we talk about Transifex :)
Cheers,
Andre Miranda
On 10/09/2017 10:48 PM, Igor Zakharov wrote:
> Hi,
>
> What maillists are you talking about?
> I'm translating on transifex but have never used any maillist for that.
>
> Regards,
> Igor
>
> 09.10.2017, 20:41, "Pablo Roberto Lezaeta Reyes" <prflr88 at gmail.com>:
>>
>> On Tue, Oct 10, 2017 at 1:08 AM Vinzenz Vietzke <vinz at vinzv.de
>> <http:///touch/compose?to=vinz@vinzv.de>> 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 options 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.
>> --
>> Xfce.space | skyrocket your desktop usage
>> https://xfce.space <https://xfce.space/>
>> _______________________________________________
>> Xfce4-dev mailing list
>> Xfce4-dev at xfce.org <http:///touch/compose?to=Xfce4-dev@xfce.org>
>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>> <https://mail.xfce.org/mailman/listinfo/xfce4-dev>
>>
>>
>> _______________________________________________
>> Xfce4-dev mailing list
>> Xfce4-dev at xfce.org <http:///touch/compose?to=Xfce4-dev@xfce.org>
>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>> <https://mail.xfce.org/mailman/listinfo/xfce4-dev>
>>
>>
>> _______________________________________________
>> Xfce4-dev mailing list
>> Xfce4-dev at xfce.org <http:///touch/compose?to=Xfce4-dev@xfce.org>
>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>>
>
>
>
>
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20171009/11c6492e/attachment.html>
More information about the Xfce4-dev
mailing list