-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Am 26.11.2017 um 01:51 schrieb Andrew David Wong:> On 2017-11-25
10:08, Desobediente wrote:
>> 2017-11-25 10:00 GMT-02:00 tokidev <
tok...@posteo.de>:
>
>>> Hello, Desobediente,
>>>
>
>> Hey.
>
>
>>> @Desobediente: Thank you for your reply. I'm somewhat confused
>>> by it and have some questions. So, let's check it.
>>>
>
>> Indeed, I have trouble even if it's e-mail communication. but
>> let's clarify.
>
>
>>> @all: Sorry for my long emails. Since texts are often
>>> ambiguous, I try to make clear what I want to say as well as in
>>> any way possible, thus, resulting in longer emails.
>>>
>
>> I was trying to avoid that, but since you're from my religion,
>> let's do it
>
>
>>> Here, you write that the put-it-together with Git is "better".
>>> What do you mean by "better"? Better than what?
>>>
>
>> Better for the people involved in the Tails translation project.
>> Like I said, being the most important part the site being built
>> with ikiwiki.
@Desobediente: I see, okay, it's a Tails thing. Not related to Qubes OS.
>>> I've read the Tails' website about translation. As far as I
>>> can see, it uses other means than we do with the Qubes OS doc
>>> (see below), but it also has its advantages and disadvantages
>>> (like the use of Git for inexperienced translators).
>
>
>> On the contrary, the inexperienced translators are presented to
>> transifex, it's the core people, familiar and comfortable with
>> git which uses it.
@Desobediente: I don't get it due to English problems, sorry.
I guess you want to say that
- - the core developers of Tails are familiar with Git and use it and
- - the Git-inexperienced translators don't need to use Git and can
translate using the Transifex interface instead.
>>> Git is nice, I know, but in general, there is always a
>>> trade-off, thus, there is never a "best" solution. The Qubes OS
>>> team made some decisions in the past, already well before I
>>> appeared. So, we have to deal with these
>>> decisions/restrictions. One example is that Qubes OS uses
>>> Jekyll instead of Ikiwiki.
>>>
>
>> Jekyll is as straightforward to collaborators than ikiwiki,
>> because both are markdown compilers, it really matters most for
>> the sysadmin trying to put things togheter in the backend (in
>> this case, its' handled by github anyway)
@Desobediente: Okay.
>>> I'm confused here. In the previous paragraph, you praised Git.
>>> But here, you don't. So, what do want to say?
>>>
>
>> That there's a separation between work being done by people
>> which find transifex easier and the people who find poedit,
>> gobby, git, etc. easier. That approach makes everyone translate
>> the way they can/want and also there are defined workflows to get
>> all work togheter for the website and the iso image.
@Desobediente: I see. This is what I've guessed above.
>> I didn't praised git on purpose, I said it is the best tool for
>> the backend people. On the other hand, the transifex is the best
>> tool for most non tech translators. Maybe I overtalked about git
>> because I'm a git person.
@Desobediente: Maybe. ;-)
>>> This looks like my thoughts on the need of a well-defined
>>> translation workflow: As long as there is no proven workflow,
>>> the Transifex translators shouldn't proceed in order to avoid
>>> mistakes when "translating URLs" and "translating YAML
>>> headers" etc.. So, I think we have the same idea, don't we?
>>>
>
>> I think that too.
@Desobediente: Nice!
>>> Please note: The translation effort via Transifex already
>>> started around May 2016 [9] but without a dedicated workflow
>>> AFAIK. So, since then, the translators have access to "do
>>> things their own way", as you (Desobediente) said, over a year
>>> now.
>
>
>> Which I don't think it's a desirable thing. People must have a
>> limit on their freedom to do what they want so things can stay
>> sufficiently organized for everyone. Rephrase that sentence with
>> your favorite philosophical group work's motto if you wish, but
>> that's the main idea.
@Desobediente: Sorry, I've English problems again.
I just wanted to say that currently there is chaos at Transifex, due
to the lack of an appropriate workflow and of translation rules. So,
IMHO, it's better to pause that until we've both a workflow and
translation rules.
>>> Many old strings have been translated meanwhile, but also many
>>> mistakes happened like translating untranslatable YAML header
>>> key words, wrong URLs and such.
>
>
>> This is such a thing that could be avoided if we had a chart
>> explaining how the workflow should be done
Exactly. As I just mentioned.
>>> And not a single translated word appeared and appears online
>>> on the Qubes website.
>>>
>
>> I suppose it's our task to send work to mr. Wong so he can
>> update the site directly. Or any of us could send pull requests
>> to the git repository as well, and it would be eventually
>> accepted (see, git rocks! can't avoid it!)
I see, I see, you really love Git. And it rocks indeed, yeah! ;-) But
this here is not Tails. This is Qubes OS and things happen differently
here.
The current rough idea is that translations will be made *exclusively*
via Transifex. So, currently, Qubes OS won't accept translations that
have been made using Git branches (this is different from the Tails
workflow). Since Qubes OS doesn't have enough people involved in
translation, they cannot afford to review and accept/reject
Git-branch-made translations. If Qubes OS had a lot more of helping
hands, like Tails has, this could be an additional way. But currently,
they can't afford it.
>>> So, seen from the perspective of the translators, they
>>> translate in a potentially wrong way and even if they translate
>>> correctly, their results don't show up on the target (Qubes)
>>> website. Thus, it's very likely that the translation folk turn
>>> sour, as Alain-Olivier pointed out in his email I referred you
>>> to.
>>>
>
>> I'm not sure I got that e-mail. I haven't accessed my riseup
>> e-mail, will check later.
Indeed, it has been sent to your riseup account.
Subject is "Fwd: Re: L10n".
Date/time is 29.10.2017 21:17 (CET).
>>> So, analogously to what Alain-Olivier proposed, I suggest to
>>>
>>> 1. temporarily close access for the translators (with a hint
>>> that this is only temporarily), 2. specify a translation
>>> workflow, 3. build an appropriate infrastructure (automated
>>> upload/download of source files to/from Transifex etc.), 4.
>>> test it and 5. finally reopen access for the translators with
>>> references to the workflow specification.
>>>
>>> @all: What are your thoughts on this?
>>>
>
>> Is step 1 necessary for the rest? Because when we close it,
>> people can/will understand it various ways. And not always will
>> the communication be perfect as to what was the reason for
>> closing their access. If we could skip that step it would be
>> smoother I think. But I don't have an answer as to what is the
>> best way to do step 1 in a smooth way nor how can we do without
>> it, altought I believe it can be done both ways.
@Desobediente: Step 1 IS necessary for not to hurt the translators'
feelings.
Imagine you're a translator at Transifex. You spend many days in
thoroughly translating. After a couple of weeks later, you visit the
Qubes OS website and wonder why you can't see your work there. So, you
ask the Qubes OS developers where your hard work is. And the only
correct (and honest!) answer is that the stuff you translated is much
too old (there are much newer versions of the texts while the old
stuff you translated is totally outdated) or it contains a lot of
mistakes (like incorrect URL translating, wrong YAML front matter
translating etc.). How would you feel now?
Also note that closing access does NOT mean saying "We don't like your
work." or something. We just could thank them for their hard work and
say that due to unsolved problems we need some time to make
translations easier and errors avoid. Meanwhile the translators may
translate other projects on Transifex. When we're done, we can re-open
the access again.
I think that we are not the first project where such a step is
necessary. I could ask Transifex for help. I'm quite sure that they
know how to do it the smooth way.
> IMO, it sounds like the main consideration regarding Step 1 is how
> much time it would take to do the rest of the steps. If it'll only
> take a week, for example, then closing access probably isn't worth
> the trouble. But if it'll take more than a month, it's probably
> worth it.
@all: I think that it'll take more than a month, Andrew. Also remember
that the current stuff there is very old. So, current translations are
a waste of time anyway.
>
>
>> ---
>
>> I've read some things you've already done and it looks like it
>> needs more hands to continue it and not let it sit. I'm willing
>> to jump in, but I'm also short on time ATM.
>
>> This e-mail I'm using don't have write permission on the
>> qubes-translation googlegroups.
>
>
> Any idea why? I just verified the settings for qubes-translation.
> Everyone is allowed to post without restriction, even non-members.
> There are no messages caught in the spam filter, either, so I'm
> not sure why your messages aren't appearing on the Google Groups
> interface. It's possible that they're just delayed and will show
> up there eventually.
@Desobediente: Or do you mean access to a Google account?
Or is it due to blocked scripts (javascript etc.) or something?
How do you know that you don't have write permission? Are there error
messages? Where and when do they show up?
Regards
Tobias
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE9VOPt2yY9xS+XKzULaXvb25AsygFAloaj5QACgkQLaXvb25A
sygaihAAvWDNfWjiA9hd/Vg2hDwBCQcNG3hKuUunAK7zBt9aud70BpZB1bq70QdZ
3qo5rJPBSA1sp44BjiQBSdOis3oAsUQKR8JQ2NHtpDp0A8FQ1v4tSgz1c80fvZsp
vm+YVsKalM1mxACgtIt5jZQBzPyoAoLtKzzV4+w9B1u2aLRYzGhzD1PzxWILw2tF
NA+aL3GuV0ct/9clMbOrqM58XxphzQAVcYZmjWoVrUu/o1c2X9IFOlZ8ff7rtsSG
GpJ/4F1a3miEqDKkZ3xFOlzXrifQapmrVLfdIUZ1vS8Sv3fqZ+QRfpqGFuzlEuyO
fA/esSYECwdeGZTJPVMp8yP+ZzYIXFJDmaQGEoJ+KZj/gWbBFS/XO5aB5TI1mFLF
NGY9Ra0IDvkjL+wyWUWcegqNFZDD+UxneXTYoh6hc+4+SG9WL6fxIwTt/xcz9A+4
vFTLw463KTMdITp0bzH5QBXrIZQziANpAUn+tiIHjGkIt9v3vbmr51V39cUM1sMR
0WvXY6UMdUO6s+EwNdB4rbvPmVJPKo0XFnJgAREYAYdwMh9eJ0MsSs8I0dzSKJUZ
FNXttu1mCUemESXPkMr2vo+nrtBCd0frFTsNMdDF8ZOsrLY6HhZ2BRBp46ngdfe8
ldFhwtxow1GPd4CMJc0lemySSmzQyBqtDtB8CrV5VyHKSjlSekM=
=Qnst
-----END PGP SIGNATURE-----