Mailinglist Archive: opensuse-translation (94 mails)

< Previous Next >
[opensuse-translation] Re: Managing SUSE translations in unified way
  • From: Tomáš Chvátal <tchvatal@xxxxxxx>
  • Date: Tue, 09 Apr 2013 11:19:29 +0200
  • Message-id: <1565542.311CYc8KHF@bugaboo>
Dne Út 9. dubna 2013 08:29:56, Karl Eichwalder napsal(a):
Tomáš Chvátal <tchvatal@xxxxxxx> writes:
Let me tell you a "shorty" bit about my hackweek project.

I'm not that sure whether this all is actually wanted or even needed.
And, more important, it looks confusing to me. But if the openSUSE
community wants to go that way, it is fine with me. I'd guess the
openSUSE community than would administer and manage this process (e.g.,
updating the translation packages, in case that that is still needed),
and I could retire from it (which is also perfectly ok for me).

Check with the opensuse project management and especially with coolo
whether everthing is fine.

Some general remarks.

1/ The current infrastructure sure has some weak areas. Thus,
improvements are a good idea.

2/ In the context of translations, I'd avoid git as much as possible and
stick with svn.

It luckily does not matter that much because both can be accessed +- the same.

With the weblate you can even reduce the requirement to have svn/git installed
because user can just fetch the .po whenever he feels like working and then
upload it back and it will be merged automatically. No git merges/svn merges
forced to be done by user.

3/ I consider branches per release (openSUSE 12.1, openSUSE 12.2, etc.)
as a good thing. Sometimes teams decide to translate a term differently
from now on; but this does not mean you actually want to change past
releases accordingly; users are used to that translation (even if
"wrong") and translated documents or third party documentation might
make use of that "wrongly" translated term.

In the future (openSUSE 13.1(?)/SLE 12(?)) we already agreed to get rid
of the separate SLE* and opensuse* branches.

Actually the problem is that we have opensuse/sle branches even for software
that is released/branched independently and then put to the sle/opensuse.
Thats why I want to put some of the things into the git to be next to the
devel code (as already webyast is). The rest will be still branch by release
so we match the reality.

Btw this separate branches agreement would you mind to elaborate which
translations will be used then?
The pro ones or the community provided ones?

I also hope to take look on the tools Stanislav posted to show diff for
upstream application, because our task should be to provide this stuff up to
them and if they decide to not use it reflect the requests by them into our
translations because we are just having more people work on one translation
and it is bit wastefull :-)

4/ Re-arranging and renaming packages is always a PITA. Only do it if
it is really needed (and you have nothing better to do ;) ).

That I agree. It is PITA but I think it is long term worth the task as we
finally know what strings are release dependant and whatnot.
Also it seems that only package you do this way is the yast thingu rest is
already done with the src package together.

5/ Permanent merging and updating translation files during development
is bad; this only makes sense at the end of a release cycle. Of course,
this is my very personal opinion; if the community thinks different, go
for it.

Permanent merging is bad, but reviewed merging is pretty cool thing that
allows you to fix bugs even on "stable translations".
I know about software that had translations broken for 3 years stating it will
be fixed with next major bump where it is already fixed. Because translators
were to work only with trunk.
And also other way around. Everyone works on stable branch and forgets to
merge stuff. This tool will be just to easily visualise the possibilites to
merge while you are translating. And it will be up to you as translator to
decide if you want it to happen or not.

6/ I'd avoid the Web for the actual translation process as much as
possible; it will probably result in more but even worse translations ;)
(see topic 5). I'd rather go for a translation app (Android).

Yeah lots of people hate web, but I think the apps are even more crazy. I
tried to translate on android and my arms hurt pretty much, the touchscreen
thingy is not great for typing too much :-)

Also I bet we already have some projects that should be translated and are
not. If you happen to be aware of such project we can also add it to the
toolkit, just reply to this mail with its name and git repo.

It is often more important rather difficult to identify obsolete stuff...

Agreed that removing obsolete stuff is also important, but from looking on our
stats we have everything in pretty much translated state so more stuff wont
hurt kittens.

< Previous Next >
Follow Ups