[yast-devel] Managing SUSE translations in unified way
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/
Tomáš Chvátal wrote:
Hello guys,
Let me tell you a "shorty" bit about my hackweek project.
It is a very welcome effort. I just updated my translation-update-upstream generated files archive: http://ftp.suse.com/pub/people/sbrabec/translation-update-upstream/README http://ftp.suse.com/pub/people/sbrabec/translation-update-upstream/ Volunteers that would be able to merge Novell contribution back to upstream would be very welcome. It would need: - A tool to simplify the merge. - Native speakers from that are able to review differences of translations, pick the better one and communicate with the upstream translation community. Let me to introduce translation tools in short: translation-update-upstream: Collects strings from upstream and LCN and creates best-effort pot files for build-time update of packages (translation-update-upstream is a build dependency of the package and while called from the spec file, it updates translations in the unpacked sources). gnome-patch-translation: Collects strings from SUSE specific patches (not only GNOME) and creates translation domain (gnome-patch-translation.pot) from them. translation-update: Collects strings from LCN and creates install-time update packages. (It does not need rebuild of packages, but translation are installed twice then (old in package and new in translation-update)). -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Stanislav Brabec wrote:
I just updated my translation-update-upstream generated files archive: http://ftp.suse.com/pub/people/sbrabec/translation-update-upstream/README
Now it was finally synced correctly. I forgot to mention: http://ftp.suse.com/pub/people/sbrabec/lcn-upstreaming/tools/ -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Tomáš Chvátal <tchvatal@suse.cz> 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. 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. 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 ;) ). 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. 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).
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... -- 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: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Karl Eichwalder wrote:
It is often more important rather difficult to identify obsolete stuff...
This script is capable to create list of all actually used po domains: http://ftp.suse.com/pub/people/sbrabec/translation-update-upstream/SLE11-SP3... Note that it is not capable to find domains in use that had no translations in the time of release. You need a complete RPM (binary) repository mirror in your local file system. Its primary target was identifying interested stuff in the git.gnome.org, but it could be easily used for LCN purge. I will re-run it and put outputs to generated-outputs directory. It will be named create-tlst-temp-all-po-projects.lst (If it is useful for other purposes, I can remove the "-temp-" in the next version and stop deleting it after use.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (3)
-
Karl Eichwalder
-
Stanislav Brabec
-
Tomáš Chvátal