-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello, Allan Nordhøy,
Thank you for your long and detailed email. I am not sure if I have
understood you correctly due to my lack of expressive English. So, as
a first step, in this email I would like to reflect how I have
understood you in a summarizing manner (and using simpler English),
rather than giving an answer to the content itself. Please evaluate
the correctnesses of my rewritings and correct them where necessary.
Am 29.01.2018 um 18:28 schrieb Allan Nordhøy:
> lørdag 16. desember 2017 15.33.15 UTC+1 skrev Tobias Killer
> følgende:
>> [proposing Alain-Olivier to archive the project]
>
> Given the benefit of the doubt, with no problem raised with either
language or content,
> let me try to lay it out more clearly. I think we can agree Qubes
> OS revolves around concepts of security that must be clear to
the user to work.
> Transifex does not allow for translation in a consistent manner
without extreme effort.
> (All of which could be automatic with a different tool.) The way I
> see this means this very concept of security, is in jeopardy. That
> is in a best case scenario.
"Qubes OS focuses on security which must clear to the user if it shall
work.
Translations via Transifex are not consistent and not efficient.
(Another tool would meet it.)
I see the whole concept of security be in danger, in the best case."
>
> Accounting for malice, preventing outright sabotage or attack
> could
be achieved in not accepting
> what is assumed to be bad translators into the project. Though not
> a bad idea, it is no safeguard on its own. While this is
> essentially the only equivalent stopgap in preventing
ill intent on Transifex,
> it moves the extreme effort over to the role of allowing people
> in.
Or vetting people
> beforehand, as it were.
"One could prevent attacks by rejecting translators who seem to be
harmful. But this alone is not sufficient since it just moves the
problem of the extreme effort."
>
> To have an actual overview of what goes on, you need the tool to
> communicate _when_ change happens, and what it consists of.
> Speaking
here of basic
> changes to strings. New translations and changes. Other platforms
> have this essential ability, Transifex does not. In any case, this
> is no less an extreme effort on part of the
translator,
> but at that, one that has to do with translation. For a project
> like
Qubes OS, this
> is where I would like to offer my services, as a translator.
"For an up-to-date overview about the translation progress, you need a
tool that calls you on changes in detail. Transifex is not able to do
this. Other platforms do.
This is where I would like to offer my services, as a translator."
>
> As someone trying to make sure also the source strings reflect my
concerns for quality,
> a lot of my time gets sunk into the way Transifex handles the link
between
> a string in the platform, where it exists in the codebase, and
> where
that
> codebase is hosted. If I am beginning to sound repetitive in
pointing out that
> this is fixed on other platforms, then yes; Such is life, in the
every single day
> of someone wanting to bridge the gap between translators and the
projects
> that are translated.
"I am also concerned if the source strings are of a reasonable quality.
I have thought a lot about
(1) the way how Transifex links strings between a project's codebase
and their internal representation within Transifex and
(2) where that codebase is hosted."
>
> There could be a lot more people doing it, and it could be less
technical.
> The people doing it now could be doing so more efficiently. Carring
> out this many-fly swatting operation means getting rid of
Transifex.
"Getting rid of Transifex has some advantages:
(1) more helping people,
(2) more efficient work and
(3) less technical manner."
>
> One would think Transifex could just fix its issues, but no, that
fly is grinning
> out of reach. Transifex does not listen to user input, nor honour
> their service
contracts.
> No amount of feasible effort or money changes that. Nor is
> Transifex
libre software,
> so one is dealt a hand of looking at alternatives, if not only for
> the reasons described.
"Transifex
(1) does not solve its problems,
(2) does not listen to its users,
(3) does not honor the users' service contracts and
(4) is not free/libre software.
This cannot be changed by more effort or money.
Also, these reasons motivate to look for alternatives."
>
> When Qubes OS couldn't exist without the ecosystem and freedoms of
> libre software, why would a community revolving
around it
> not integrate and function better given the same liberties?
[[Sorry, I do not understand what you want to say. Please rewrite this
paragraph using simpler English. Thank you!]]
>
> Translators, and I speak for myself in no uncertain terms, often
have difficulty
> adapting to new ways in that they are technical in nature, and
highly technical in they are
> complex.
"In my view, it is difficult for translators to deal with complex and
high-technical systems."
>
> Fortunately this is where eventualities turn out for the better,
> both Pootle and Weblate have excellent and humble developers that
> listen,
react quickly,
> and are great people at that. The people i know in Qubes are no
different.
"Fortunately, the developers of Pootle and Weblate
(1) are excellent,
(2) are humble,
(3) listen to their users and
(4) react quickly on issues.
The developers of Qubes OS are this way, too."
>
> Qubes OS in particular is a rather large and complex project, in
> the
early days
> of establishing its own language, and communicating that to
translators, making matters worse,
> but also making benefits of switching platform higher.
[[Sorry, I do not understand what you want to say. Please rewrite this
paragraph using simpler English. Thank you!]]
>
> If you have a lot of people changing only a few strings, this is
something that would
> otherwise be valuable, but with Transifex turns out to be the
opposite, for reasons described.
> When relying so heavily on extreme effort on part of every single
translator to arrive
> at any meaningful finality, it stands to reason micro-managing
"drivers by" does the opposite
> of sharing the load. These individuals are in turn discouraged
> from
translating,
> and the cycle continues. There would be a lot more valuable
> translators if communication wasn't so broken. Not only just the
> automatic
feedback, but also the messaging.
"If you have many people who translate only a few strings on Transifex
then that work is useless for the reasons described.
Relying on a hopefully extreme effort to be made by each single
translator will also not share the load but accumulate it.
This will discourage the translators and so on.
If communication via messaging and automatic feedback worked well then
more translators would be there."
>
> Granted, messaging is not something tackled well ore even
implemented on other platforms,
> but it is not an unthreaded mess like on Transifex.
"Messaging on other platforms, if available, is not that chaotic as it
is on Transifex."
>
> The spying nature of Transifex, in the scripts it loads, similar
> to
Google Groups, is also one Qubes OS
> could do without, for reasons why the Qubes OS makes sense.
"Scripts loaded from Transifex spy, similar to those from Google Groups.
Qubes could get rid of it for security reasons."
>
> Do not assume I can't detail what I describe as extreme effort
> looks
like in practice.
> It would however only serve as a manual on the many ways in which
Transifex is futile,
> for reasons the argument of time spent needlessly doing things is
> valid.
"I can describe what I mean with extreme effort in detail.
But there are many more reasons, besides wasting the time, why
Transifex is pointless."
>
> I am not trying to say I have said this earlier, I am trying to say
> it again.
>
> ~kingu
>
Kind regards,
Tobias Killer
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE9VOPt2yY9xS+XKzULaXvb25AsygFAlpx4DUACgkQLaXvb25A
syjTCA//T+lnjl7D+nh3jdrHm0nqp1dM6eV05PoadOxEsthLsmQq3GVWbF4f8LLu
De4FKtZS1bAmtjgYgGXbElv3ps7b9JpNFz0L29LBgJLvQ9XUmulTSVenXr/CkuVV
s+dhXFJ/VgJ71Oozp2GA4N7q80o67Ct5U7BTV6KlY1wK4k2r9KwXnJxriYM4Yrbs
HhXHvyNIa1bEmN03duZFBTFxSqHTt8SYIil7qmE72Cqb0teJnERWBgL5UiWdjea9
suTtbFf3bVJV1zeEFFVJpj3PmxWm2WQA/qCkD/keFcMXouPuvzyO83aN5w4FojsR
EkCdVTc+DPWjhtLHWWmOxUX7bu7teUwBz8scolzTGx7TLGmMpvpDuwLk59GJ51Vx
3JumEW0mihwLPl+k2cp3GTz48rWt2mH1VulCQ5M5zlsCvreRml3Vnu3K8AEDTza+
AwjVFyRJIinOLwExXq+hY5lwNwInAgQ7TbW043GKvZFWJ7y5OJDxT194DMrC/OSC
GKpulWET7lAgTHl/RMD2qLf5XmRYsrGuW8uYE4OPP6f4Dwk4cFCvnU3eY1lgm73F
bvHy5nCXLJ3ugOFQ+9S+VX8eQbSzRd3XSmOKwkz+Fxwgfv1BxQMdHf6ClNKbK01+
YyL3Da2cyuk2G/2Joe8lgXAMitko9u0U2PbL4oKoEOqcSvmmYkc=
=TJHI
-----END PGP SIGNATURE-----