Mailinglist Archive: opensuse-translation (237 mails)

< Previous Next >
Re: [opensuse-translation] openSUSE Weblate
Hash: SHA256

On 2015-10-14 02:20, Alexander Melentev wrote:
2015-10-13 11:57 GMT+03:00 Richard Brown <RBrownCCB@xxxxxxxxxxxx>:
Carlos E. R. wrote:
They were not working because the developers were not doing
their part. So, they are not happy and they change it, good,
but destroying our side of the system, the side that was
working correctly, bad.

More 'us' vs 'them' - Stop it
Richard, please, stop pushing this "'us' vs 'them'" on Carlos and
all of us. We are all adult people here, we all understand there is
no 'versus' between devs and translators. Every team is doing its
part of the job for the sake of benefitting the project we all
love, everything is fine here. Just a lack of communication between
'us' AND 'them', which can lead to undesirable consequences for the
project as a whole. As you admitted in the following email,
"communication about Weblate could have been handled better", so I
suggest we all start to handle it better now. For instance, by
stopping false accusations like these:
As wonderful as things might have been from your perspective,
the reality is that the output of 'your' part was not working

Just look at Tumbleweed - Mostly untranslated, by your own

Just look at Leap - Untranslated, by your own omission
As it was already pointed out, the whole process was just not
fitting the needs of these new release types, so saying that this
situation is translators' own omission is an exaggeration. Once
again, consequent steps for translating openSUSE are like this:
Stage 1: 1.1) generate translation templates from the software
(handled by devs, semi-automated work) 1.2) publish translation
templates on i18n SVN (handled by devs, manual work) Stage 2:
1.3/2.1) generate translatable files from templates and push to
i18n SVN where translators can get them by language (handled by
translation coordinators: keichwa and sometimes community
volunteers including myself; manual/semi-automated work) 2.2) get
the files for your language and translate (handled by translators,
manual work) 2.3) push translated files back to i18n SVN where devs
can reach them (handled by translators, automated work: svn
commit) Stage 3: 3.1) get the translated files from i18n SVN and
push them for packaging for release (handled by devs/packagers,
manual/semi-automated work) So, Tumbleweed was not performing well
on stage 3 and Leap has never passed stage 1.

Lack of performance and lots of manual work are easily noticeable
in this 'old' process, so several developers decided to fix this
and came up with the new solution, which brings some automation to
stages 1 and 3. It is great, cause these stages failed most in the
old approach, and now they should be passed like a breeze. From
developers' point of view this should speed up the whole process
significantly, cause 4 out of 6 steps will be automated. From
translators point of view it is not that great because the price
for speeding up other stages is ruining the only automated step of
the old way and making harder others. Imagine we all are on the big
ship: devs are the central section at the very core of the ship,
translator's section is along a broadside. For historical reasons
we have some water of noticable level in our sections which slows
down the whole ship, but we somehow got used to it. Developers are
smart guys and craft a new pumping station that pushes the water
out of their section through the wall. Developers see the falling
water level in their section and expect the ship to go faster, but
it is not happening. Guess why? Because nobody asked the
translators sitting behind this wall, the water level in their
section is rising and the ship is still too heavy. Additional valve
to pour the water through the broadside would correct the whole
situation, but it was not included in this brand new pumping

Back to the real life: all the translators will be really grateful
for new tools that will fix the issues of the old way. There is
absolutely nothing wrong in taking action to make everyone's life
easier, but please consider that this introduced some problems,
which are severely more notable from translators' side: 1. Stealing
real content. "Never test on production" is a widely known
postulate. I don't know the correct idiomatic expression in
English, but here in Russia we call it "blood-written rule".
Release notes of upcoming Leap release will get near to zero new
translations, since it was taken out of "old but somewhat working"
SVN server and put to "not yet an open beta" weblate server which
no new translator is familiar with. 2. Scalability. When everything
will be migrated to weblate it will result in almost 200 separate
repos/projects. On currently deployed Weblate I saw no option to
mass-download files of one language from all (or subset of)
projects. Same for uploading. Managing that file by file in web UI
is too much for one individual. Can we expect some API/scripting
support on server side to be able to push a bunch of files at once
from command line? That would really become the needed "valve" to
speed everything up. 3. Communication. Knowing only by accident
about significant changes gone live was not a pleasant experience
and this thread was started in bad feelings. It is getting too big
for detailed discussion, and my previous questions about proper
ways to talk to weblate guys were not answered. I really would like
to see devs/translators communication improving. Can we organize a
separate technical discussion or even better an IRC meeting? I
clearly saw form this and other discussions (incl. ongoing in
yast-devel) that devs and translators have different understanding
and priorities of the same process, so some meeting/detailed
discussion would definitely help us to understand each other

I agree to all that :-)

- --
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith))
Version: GnuPG v2.0.22 (GNU/Linux)

To unsubscribe, e-mail: opensuse-translation+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-translation+owner@xxxxxxxxxxxx

< Previous Next >
This Thread