Mailinglist Archive: opensuse-translation (71 mails)

< Previous Next >
Re: [opensuse-translation] Leap/SLE translations pushed to Tumbleweed?
On 2016-03-10 19:04, Karl Ove Hufthammer wrote:
Carlos E. R. skreiv 10. mars 2016 18:32:


On all the upstream projects where I participate, translators have no
access to the source tree. That's only for developers.

I have participated in several projects where the translators (at least
some of them) have commit access to the source tree.

Me in none. Only here, openSUSE, I have access to the translation svn
server. On the rest, I access by email, automated or fully manual.


For instance, with the "Translation Project"
...
Translation is only done once the developers submit a release, not for
work in progress (would be similar to factory).

IMHO, the way the ‘Translation Project’ works is far from ideal. Your
last comment is a case in point; it’s much better if the translators can
work on translations continuously, instead of just before a release (and
then have to translate a large number of strings at once). And having to
send e-mails to update translations is a pain.

I dislike working on a translation continuously. It is a pain. I
translate a string, and the next day a dev changes it and I have to
change it too. Once, a dev revised (sed?) all strings adding stops to
hundreds of sentences. I had to re-translate hundreds of strings. Of
course, trivial change, but still, many strings. Hours.

I prefer working on a project that is not changing. It is a personal
choice. That's why I don't translate factory (even if I could, which
currently I can't). Others do like to translate factory.

Aside that, the TP is quite bureaucratical, yes.


Check how KDE team work (upstream). I will not describe it, as I don't
work there, but they have directories where all files are stored for
translation. Other people here can describe the process (I think
somebody did, not very long ago).

I work as a translator for KDE. There the translators have commit
access, and fetch and commit translations using SVN. It works extremely
well. Translators just have to do a

svn up

to fetch the files, translate them and then do a

svn commit

But not against the source tree the devs use, but your own, for
translation, right?


The translations automatically appear in the released applications (it
feels almost like magic :) ). And the translations files are
automatically updated (with new/changes strings) each night¹. Easy
peasy, and no hassle for the translators. (And when an application is
renamed, moved, split into an application + library or have other
changes that need changes in the translation files (this happens
frequently), the nice people at KDE automatically do the needed changes
to all the translation files.)

What about different releases, how are they handled?


In KDE, all applications used to live in the same SVN repository. But a
few years ago they were split into multiple Git repositories, stored in
several different places (e.g., some at GitHub) (and a few applications
stayed in SVN). But it was decided that keeping the central SVN (not
Git) repository for translations would be best. So that’s what we use,
and it works perfectly. Each language has its own directory (and there’s
of course also a templates directory).

The other option would be for the translator to manually hunt down each
and every application and library (there are many hundreds) repository,
and manually fetch the source code and commit the translations to them
(or send pull requests), which would of course be untenable. Even having
to download the hundred of gigabytes of data from the repositories would
be difficult for most translators. But now they just have to type

svn up

To get all the latest translations files (for one’s language) to
translate. It’s even faster than launching a browser. :) Could anything
be simpler?

Yes, the methodology at KDE is wonderful :-)
I would love that here.


Footnote:
¹ I said that in KDE the translations files are automatically updated
(with new/changes strings) each night. Note that it’s also possible to
opt out of this (by placing a ‘magic’ file in one language’s translation
directory), and merge the translation files oneselves, if one prefers.
Some teams prefer this, and there are some advantages in getting to
decide when (and how) to update the translation files.


It gets a nuisance when your working copy doesn't match the copy on the svn.


--
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)

< Previous Next >
List Navigation
Follow Ups