[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Discussing the LibO translation workflow (was: Re: [libreoffice-l10n] Translating LibO 3.3)


У уто, 05. 10 2010. у 19:15 +0200, Kálmán „KAMI” Szalai пише:
> Hi Goran,
>
> Here is a documentation of old workflow for ooo-build. It maybe useful,
> or we can discuss & update the workflow & the document.
>
> http://cgit.freedesktop.org/libreoffice/build/tree/doc/localization.txt
>
> KAMI

Let us start this discussion.

As there are no more patches, there is no need to run the build twice to
extract the difference, right? We should stop to separate lo-build and
upstream messages and use the single SDF file.

I would like if we can make it easy for us translators to work by having
both POT and SDF template available in the Git. When it is time for a
string freeze period someone can run the build up to l10ntools, extract
SDF, convert it and push it into Git. This can be either in build/po or
preferably somewhere inside l10n/ and removing build/po from a tree.

The extracted POT file will be large and we should test how our tools
can handle this or we should split it into a directory tree using oo2po.

There is a real issue when splitting POT files into a directory tree
when messages get moved from one file to the other. Our tools
(pomigrate2 from Translate Toolkit) can not understand this and we get
fuzzy match while the same string was not changed, just moved around.
There are also some issues when we have the same filename in different
directories.

If we split the POT into a directory tree we should solve the issues by
having a better pomigrate2.

You can read this message from ooo-l10n-dev list for some background:
http://www.mail-archive.com/dev@l10n.openoffice.org/msg07836.html


The scenario for a developer would be to extract the strings, convert
and commit to Git with something like:

+ ./configure
+ build up to l10ntools
+ cd bin && ./extract-gsi -d en-US GSI-en-US.sdf
+ oo2po -P -i GSI-en-US -o po/pot
+ copy sdf and pot to l10n/

Translator can work on Pootle or whatever we decide to use, or take the
POT files from Git and work on PO in l10n/<lang>.

We should merge existing PO files when the POT is regenerated. I believe
Pootle will do this for us, and translators can do this manually but we
may also want to push the updated files into Git as well.

Our build process should compare if the PO files are updated and
regenerate the SDF automatically during the build. Developer can commit
this updated SDF file back or, if this is fast enough, we can even
decide to regenerate the SDF in the every build (just the languages that
are being built).

Other option would be to require from translators to deliver SDF (like
we do currently in the OpenOffice.org workflow) or the PO files would be
downloaded from Pootle and SDF will be generated and pushed into Git.

Whatever option is selected I would like to have PO files in the version
control, as a backup and for keeping a complete history. It is possible
that Pootle can work using Git repository giving a lot of new
possibilities for continuous translations integration.

Best regards,
Goran


--
To unsubscribe, e-mail to l10n+unsubscribe@libreoffice.org
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be deleted.

References:
[libreoffice-l10n] Translating LibO 3.3"Andre Schnabel" <Andre.Schnabel@gmx.net>
Re: [libreoffice-l10n] Translating LibO 3.3Goran Rakic <grakic@devbase.net>
Re: [libreoffice-l10n] Translating LibO 3.3Kálmán „KAMI” Szalai <kami911@gmail.com>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.