If you have time it would be great if you'd update the release notes
translations in the 12.3 branch:
https://svn.opensuse.org/svn/opensuse-i18n/branches/openSUSE-12_3-Branch/lcn
--
Karl Eichwalder SUSE LINUX Products GmbH
R&D / Documentation Maxfeldstraße 5
90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-translation+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-translation+owner(a)opensuse.org
Hello guys,
Let me tell you a "shorty" bit about my hackweek project.
Currently our translation repositories are stored in internal svn and split by
branches per release. I want to tackle the issue where translations are
inconsistent among supported releases and also somehow consolide all the stuff
we are providing to have only one input channel with less space for
contributor confusion.
As I described this in my previous mail [1] I want to fire up the weblate
instance with help from Michal Cihar. But as people complained against web
translations only we will simply list the git repositories with access to
allow them merge requests on github or use the weblate only as interface to
obtain the .po files.
Items currently stored in svn [2]:
yast - obvious, in github
webyast - obvious, in github
lcn - merged repository for various tools zypper/bootloader/...
packages - repository for cd descs/etc...
Some of the packages do not have suse upstream (eg special kde translations
and so on). These will be migrated in the end to new github project (eg.
openSUSE/translations-3rdparty.git; if you have cooler name we will use it
:P).
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.
List of tasks to get this working
-------------------------------------------
Infrastructure side:
Deprecate translations mailinglists to keep only the opensuse-translation
where everyone should discuss, with per language lists the problem is if the
team goes inactive nobody notices, and we can have more active list where we
ingore threads that do not bother us. Eg we can have them prefixed by lang if
they matter only for those ([ru] Unable to translate foo due to xyz). [[Who
can actually sent deprecation mails and mark them read only?]]
Create new documentation on i18n which will contain the weblate instance and
provide links to git repositories and pull requests description for
contributors not wanting to use the weblate.
Suspending the translation repositories to read-only until migration is
complete. Note for translators, you can translate your stuff even in read-only
mode. Merging then will be possible in weblate or by hand into the new
location which will be described in the new repository listing. IMPORTANT:
this must be done ASAP, because without the disabled write access we shouldn't
start moving the files around.
Upstream/developers side:
Take the translations from the svn repository and create po/ folder in your
project root. Structure looks like this (some projects already have po folder
but the translations are in tarball, just throw away the tarball and unpack
it):
<snip>
yast2-network/po/cs.po
yast2-network/po/de.po
yast2-network/po/yast2-network.pot
</snip>
Modify spec-file of the package to count with the translations from here (I am
well aware it will create collisions in the start with the generic l10n
packages we will remove later on, so we should obsolete them and make the lang
pkg recommended).
Create new hook that updates the .pot file with each commit and regenerates the
.po files. I bet Michal already have some nice hook at phpmyadmin and he can
provide it so we don't need to write one stock each time.
Remove hooks that push into svn if there are some and it is not cron-based
server side. [[Anyone knows how this is done?]]
Update buildscripts to generate .mo files and to install them into right place.
Easy in distutils, for autotools you need gettext Makefile.in.in, I will
provide help and do the work where needed.
After we fire up testing weblate we will also need to add weblate key to be
able push to the repository. [[Michal could you please elaborate here how this
taks need to be done?]]
Of course you are not the ones who have to do the work, I will do the task if
asked/allowed to touch your repos (scarabeusiv account at github). I am just
pretty sure I will not be able to migrate all 205 repos in one week without
screwing up somewhere, so any help will be highly appreciated, specially when
you guys know your project much more than I do :-)
Packaging side:
We need to update the .spec files of the various translation modules like
yast2-translations to be split into specified packages (yast2-network-lang,...)
Packages that will be obsoleted and split are:
yast2-translations
[[I suck at searching in obs so if you see more of those that should be
adjusted please reply here and I will do whats needed]]
Possible future task that would make people happy:
Allow translations of wiki pages instead of having separate wiki instances for
each language. This stuff is messy and using weblate here would be so awesome.
Cheers
Tom
PS: keep reply-to on opensuse-translation so we don't clutter the discussion
on multiple places.
PPS: this is quite lengthy mail so if I forgot to mention something just slap
me and ask for more informations.
[1] http://lists.opensuse.org/opensuse-translation/2013-04/msg00000.html
[2] http://svn.opensuse.org/svn/opensuse-i18n/
Hi, Karl and all other local translators:
Please watch bug 801311:
https://bugzilla.novell.com/show_bug.cgi?id=801311
(There's also a software bug in it and has been assigned, so I can't
assign it to Karl at the same time)
Our yast/50-pot/gtk.pot is now only 48 strings, comparing to 321
strings in qt-pkg.pot
Some former commit before 12.3 destroyed all strings for the GTK interface.
(ViewVC is currently broken, so I can't tell which commit)
So we may have to re-do the work for a big update.
Just reserve some time in your schedule, or your locale will be broken
for the entire 12.3 life cycle!
Greetings
Marguerite
--
To unsubscribe, e-mail: opensuse-translation+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-translation+owner(a)opensuse.org
Hello guys,
after the last hackaton there were some questions about the summit and why
didn't I announce that I work on something like that. The reason was really
simple, I was not entirely sure if it is possible and how hard it will be.
Firstly let me explain what is summit. It merges various trees of translations
(sle11, opensuse12.3, Factory) and shows them only as one translation file
with desc for which branch is which. The obvious benefit for translators is
that you have to do the work only on one place and it gets populated in all
branches.
In the end after all the testing I have local svn checkout with semi working
merged tree for 3 languages, but during the automatic update testing it
crashes a lot, which ends up uncovering bugs in the pology package that is
supposed to do the summit handling. Due to this and lack of not much free time
I suspended my work on this and I plan to do a bit stuff following week during
Hackweek 9 [1].
But there is also one more option than just going with the pology, which would
allow us also to do fancy translations over web interface [2].
The benefits here are the same as with the summit for the translator, but the
thing should be more working as Michal Cihar is pretty smart guy and it would
reduce the need to rely on package I don't entirely understand.
The work on weblate side required is adding support for svn OR migrating our
translation infrastructure to git. And then just starting the weblate instance
and providing links.
After that we would probably discourage/disable the direct access to the po
files because you would loose all the fancy stuff like the branch merging when
you work around and not use the web interface. So please let me know how
strongly would you be against web-based translation approach.
Note that if you lack some cool feature on weblate side I bet we can bribe
Michal with some cookies to implement it. :-)
Cheers
Tom
[1] http://hackweek.suse.com/
[2] http://www.weblate.org/