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
As wonderful as things might have been from your perspective, the
reality is that the output of 'your' part was not working correctly
Just look at Tumbleweed - Mostly untranslated, by your own omission
Just look at Leap - Untranslated, by your own omission
As it was already pointed out, the whole process was just not fitting
2015-10-13 11:57 GMT+03:00 Richard Brown :
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:
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 station.
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 better.
---
Best regards, Minton.
--
To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-translation+owner@opensuse.org