Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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


Context


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.