Re: [Libreoffice] [libreoffice-l10n] LO Pootle

Hi Andras,

On 2010-12-30 at 09:13 +0100, Andras Timar wrote:

> > BTW - would it help you if we got rid of the sdf files, and instead we
> > had .po files in the l10n git repository?  [For sure it would help us
> > who work with the git repos, because the sdf file format is just
> > something incredibly terrible for version control.]  Would you be able
> > to merge directly from the OOo Pootle, or from .po files produced by
> > that, or do you still need .sdf for part of your workflow?
>
> Assumption: translate-toolkit can convert translatable content back and
> forth without loss of information.

Yes, I assume the same thing :-)

> I believe this assumption is true. Translate-toolkit has been used for a
> long time by many teams. My suggestion is that all l10n teams should use
> Pootle to submit their translations. This does not mean that they must
> use Pootle to translate. They can use Pootle, offline PO editing tools,
> xliff, or edit sdf file directly - it does not matter. However at the
> end translations must be uploaded to Pootle in .po format. Pootle - with
> a git back-end - will contain the "master" copy of translations.

Sounds great to me.

> English sdf file should be produced regularly for Pootle update. l10n
> repository will be obsolete. Build should take .po files from git
> (Pootle back-end) and generate localized sdf files build-time.
>
> Problems:
>
> 1. How to import existing LibreOffice translations to Pootle?
>
> l10n repository contains monolingual (and sometimes outdated) sdf files.
> We can export up-to-date bilingual (en-US + translated) sdf files from
> the source, but we cannot make a difference between untranslated strings
> and strings that are intentionally same as en-US (URLs, code, function
> names, language names etc.). Sun stored translations in a database (not
> public) and they kept track of this information - this cannot be
> extracted from the source.

I think that with a simple heuristic, we might get quite good results:

- if there exists a language that has a translation => mark the string
as not translated
- if there no translation in any language, mark as fuzzy; it probably is
an URL or something

We can play a bit with the % of languages that have the translation for
the fuzzy / not translated at all split; I hope it might work reasonably
well.

> 2. How to merge translations from OpenOffice.org?
>
> I think it should be decided individually for each language team.
> Automatic merge should happen for only those languages that do not have
> LibreOffice translators. Of course technical support should be provided
> for all. Translators don't need to understand the technical details. I
> think members of this list have the knowledge, we can put together a
> good process.

Sounds good to me.

Thank you,
Kendy