Mailinglist Archive: opensuse-translation (237 mails)

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

On 2015-10-10 23:06, Alexander Melentev wrote:
2015-10-10 20:48 GMT+03:00 Tomáš Chvátal <tchvatal@xxxxxxx>:

Hi, Tomáš. Before I start my inline ranting I'd like to let you
know how grateful I am for your extensive explanations, we all have
missed them from the beginning. Really, I mean it, thank you so


full and official announcement of the beta will be going at some
point next few weeks. We just needed to "steal" some of the
projects already being translated to ensure good live testing.

And one of the "stolen" projects is RELEASE NOTES exactly a few
weeks before the release when there is still no single translator
familiar with this new and not still established process. How do
you expect to have any release notes translated in time for this
release? I really would like to see the genius eyes of the guy who
decided to do exactly that in this specific moment.

The plan is to have weblate for all the stuff, because it will by
this per- project git repository solve most of the trouble we are
having wrt longstanging SLE issues and now inherited by Leap

We thought really hard about the problem and the fact that
weblate actually is open-source and can be glued to internal
infrastructure was the winner.

Yes, we all know this FOSS mantra "who codes decides", but I
really don't think that trading devs headaches for translators'
headaches is a way to go.

And this decision was made without even commenting with us... :-(

Yes, It is not "those who do it decides", as we were told. They don't
consider us part of "those who do". We don't code. :-//

Now for the concerns raised over the thread:

1) po translations will be allowed even externaly, ie. direct git
commits 2) weblate allows mass-download and mass upload, so you
can use the tool even for some checks if you don't want to do
direct commits

Having more than one way to push translations in is pure evil cause
it leads to conflicts. Code developers might think that git access
for everybody might be a good idea and is managable, but in case
of translations in terms of quality and consistency it is a road to
hell: there are substantial differences between collaborating on
code and collaborating on translations. Before making such
"game-changing" decisions it might be a good idea to
consult/collect feedback from the guys who have real experience
with this "game". Lack of such communication at the very start of
significant change is really frustrating.

I concur.

So you can try the translating as of now and collaboration will
be deployed in close future. If you find any problems with the
tool, like crashes where we didn't noticed them, or something
does not behave like it should please sent sbrabec an email about
it or file a ticked in bugtracker.

Please be more specific as we still have no valid info about
authors of this decision and proper ways of communication with
them. For instance, I once was denied to fulfill my NEEDINFO
request to coolo, cause the email address I picked for this was not
the one coolo expected (while still being valid coolo's address).
So, what is the correct sbrabec's address for this? What is the
correct bugtracker/component for such "early bird" bug reports?
Where exactly was the discussion about all this held and how we can
take part in it and make comments and requests? Who should we
discuss the solution architecture with, i.e. this easily
foreseeable scalability/managability issue I described earlier
about a single translator VS 150+ repos? I am really interested in
all this.

Yes, I concur.

Well... I will not do any testing, not this time :-(

I require first that all the procedures be documented at
site, in text fit for dummies. I'm not going to do the investigating
on how to do things, not this time, sorry. I'm too tired. Those that
did this without asking or telling us, now will have to go further and
explain it all to us.

I need procedures documented on how to work this with lokalize (the
kde tool), or equivalent (poedit?). I need to know how to download ALL
the .po and .pot files to my computer: one directory for all the POTs,
and another directory for all the POs, one per language. In a command
or two. And there have to be different sets for different openSUSE
versions: 13.2, leap, tumbleweed, etc. Ie, an structure that
functionally replicates what we now have on SVN.

I also need to know how to control who can commit translations of what
file. Ie, to assign a file to a particular translator. And this needs
to be done manually, by the coordinator, or automatically
(autoassignation). Both methods are supported by Vertaal.

When all is documented, I will read and evaluate. Then I will consider
whether I keep contributing as translator, or not.

I'm too tired to do the investigation myself...

PS: Did you know that some of those PO translations in SVN were
not used for like 7 years? Now they are :)
It is good that new tools can solve old issues. Now let's ensure
they will not create more new issues and I think we'd better do it
together =)


- --
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