Upgrading OpenOffice.org to XLIFF

HI EVERYONE 

XLIFF IS THE STANDARD [1] FOR PROFESSIONAL TRANSLATION, AND
IS  
BECOMING THE STANDARD FOR FREE-SOFTWARE TRANSLATION.

IT IS XML FOR TRANSLATORS: EXTREMELY EASY TO MANIPULATE, AND
RICH  
WITH METADATA CAPABILITIES WHICH SAVE US A LOT OF TIME.

COMPARED EVEN TO PO FORMAT, XLIFF HAS SERIOUS ADVANTAGES. IT
IS  
EXACTLY WHAT WE NEED TO MANAGE THE COMPLEX BACKGROUND OF AN 

OPENOFFICE.ORG TRANSLATION FILE.

IT ALSO HANDLES DOCUMENT TRANSLATION EXTREMELY WELL, AND
ENHANCES TM  
CAPABILITY.

THERE ARE A NUMBER OF FREE-SOFTWARE TRANSLATION TOOLS
ALREADY  
AVAILABLE FOR XLIFF [2], AND POOTLE IS BASED ON XLIFF. MY
OFFLINE  
EDITOR, LOCFACTORYEDITOR, IS ALSO BASED ON XLIFF: I EXPECT
POOTLING,  
THE WORDFORGE OFFLINE EDITOR, IS AS WELL.

THERE ARE A GREAT MANY ADVANTAGES TO SWITCHING TO XLIFF.
WHEN CAN WE  
START? 

FROM CLYTIE (VI-VN, VIETNAMESE FREE-SOFTWARE TRANSLATION
TEAM / NH�M  
VI{�T H�A PHz�N M{�M T{� DO)
HTTP://GROUPS-BETA.GOOGLE.COM/GROUP/VI-VN

[1]
HTTP://WWW.OASIS-OPEN.ORG/COMMITTEES/XLIFF/DOCUMENTS/XLIFF-

SPECIFICATION.HTM

[2] E.G.
HTTP://XLIFF-TOOLS.FREEDESKTOP.ORG/WIKI/PROJECTS/XLIFFTOOL
HTTP://SOURCEFORGE.NET/PROJECTS/XLIFFROUNDTRIP

Hi Clytie,*,

On 8/9/07, Clytie Siddall <clytieriverland.net.au>
wrote:
> [...]
> There are a great many advantages to switching to
XLIFF. When can we
> start? 

German-lang team already uses xliff for the translation
work
(but one of the main reasons was as well, that there is a
java-based editor
that can be used on whatever platform (share TM,
reviews,...)

https://open-language-tools.dev.java.net/
editor/about-xliff-editor.html

ciao
Christian

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

Can I suggest OmegaT in this context?

http://sourcef
orge.net/projects/omegat

Regards 

Vito
-------- Original-Nachricht --------
Datum: Thu, 9 Aug 2007 12:32:51 +0200
Von: "Christian Lohmaier" <clophopenoffice.org>
An: devqa.openoffice.org
Betreff: Re: [qa-dev] Upgrading OpenOffice.org to XLIFF

> Hi Clytie,*,
> 
> On 8/9/07, Clytie Siddall <clytieriverland.net.au> wrote:
> > [...]
> > There are a great many advantages to switching to
XLIFF. When can we
> > start? 
> 
> German-lang team already uses xliff for the translation
work
> (but one of the main reasons was as well, that there is
a java-based
> editor
> that can be used on whatever platform (share TM,
reviews,...)
> 
> https://open-language-tools.dev.java.net/
editor/about-xliff-editor.html
> 
> ciao
> Christian
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
> For additional commands, e-mail: dev-helpqa.openoffice.org

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free
SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/
de/go/freemail

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

On 9 ao�t 07, at 17:17, Clytie Siddall wrote:

> There are a number of free-software translation tools
already  
> available for XLIFF [2], and Pootle is based on XLIFF.
My offline  
> editor, LocFactoryEditor, is also based on XLIFF: I
expect  
> Pootling, the Wordforge offline editor, is as well.

The problem with Pootle is that is converts XLIFF from PO.

My understanding is that the original strings are stored in
XML, they  
are converted to a non XML format (SDF) loosing there all
their XML  
"abilities", then converted to PO and then to
XLIFF, leading to a  
mess of non encapsulated code sequences in the translation
strings.

Similarly, the TMX that we were sent were "false"
TMX based on the  
SDF files.

It would be better if the XLIFF and TMX directly came
directly from  
the original XML format. That we we'd have something
extremely useful.

The current process (conversion through PO) removes all the
benefit  
one could have from working with and XML based format.

Jean-Christophe


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

Vito,

See my reply to Clytie.

The problem with using XLIFF is not a tool problem, but
merely a  
conversion problem. The intermediate conversion to PO with
the  
translate-toolkit tools removes all the benefit from working
with an  
XML based format.

Also OmegaT is not the best way to work with XLIFF
currently. OLT is  
cumbersome and not easy to use but as far as XLIFF 1.0 is
concerned  
it does the job properly. For OmegaT to be efficient in this
process,  
it would be necessary that OOo adopts a TMX based
localization  
process: all the legacy versions are stored as TMX and all
the  
translations do _not_ take place on diffs but on the whole
source.  
That way it would be trivial to generate updated
translations without  
ever leaving an XML workflow.

The intermediate SDF conversion makes this very difficult to
happen  
as well as the second conversion to PO.

Jean-Christophe

On 9 ao�t 07, at 19:37, Vito Smolej wrote:

> Can I suggest OmegaT in this context?
>
> http://sourcef
orge.net/projects/omegat
>
> Regards
>
> Vito

> Von: "Christian Lohmaier" <clophopenoffice.org>
>> German-lang team already uses xliff for the
translation work
>> (but one of the main reasons was as well, that
there is a java-based
>> editor
>> that can be used on whatever platform (share TM,
reviews,...)
>>
>> https://open-language-tools.dev.java.net/editor/abou
t-xliff- 
>> editor.html

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

Back-Conversion to PO!? 

I did not know about that ... You're of course absolutely
right about losing everything.

Reminds me of a book we are writing - they insist on the txt
format ("... so that we can do it with Latex...")

Sigh

Regards

Vito


-------- Original-Nachricht --------
Datum: Thu, 9 Aug 2007 20:28:20 +0900
Von: Jean-Christophe Helary <fusionmx6.tiki.ne.jp>
An: devqa.openoffice.org
Betreff: Re: [qa-dev] switching to XLIFF

> Vito,
> 
> See my reply to Clytie.
> 
> The problem with using XLIFF is not a tool problem, but
merely a  
> conversion problem. The intermediate conversion to PO
with the  
> translate-toolkit tools removes all the benefit from
working with an  
> XML based format.
> 
> Also OmegaT is not the best way to work with XLIFF
currently. OLT is  
> cumbersome and not easy to use but as far as XLIFF 1.0
is concerned  
> it does the job properly. For OmegaT to be efficient in
this process,  
> it would be necessary that OOo adopts a TMX based
localization  
> process: all the legacy versions are stored as TMX and
all the  
> translations do _not_ take place on diffs but on the
whole source.  
> That way it would be trivial to generate updated
translations without  
> ever leaving an XML workflow.
> 
> The intermediate SDF conversion makes this very
difficult to happen  
> as well as the second conversion to PO.
> 
> Jean-Christophe
> 
> On 9 ao�t 07, at 19:37, Vito Smolej wrote:
> 
> > Can I suggest OmegaT in this context?
> >
> > http://sourcef
orge.net/projects/omegat
> >
> > Regards
> >
> > Vito
> 
> > Von: "Christian Lohmaier" <clophopenoffice.org>
> >> German-lang team already uses xliff for the
translation work
> >> (but one of the main reasons was as well, that
there is a java-based
> >> editor
> >> that can be used on whatever platform (share
TM, reviews,...)
> >>
> >> https://open-language-tools.dev.java.net/editor/abou
t-xliff- 
> >> editor.html
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
> For additional commands, e-mail: dev-helpqa.openoffice.org

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu
sparen! 
Ideal f�r Modem und ISDN: http://www.gmx.n
et/de/go/smartsurfer

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

On 9 ao�t 07, at 21:22, Vito Smolej wrote:

> Back-Conversion to PO!?

SUN: XML<->SDF<->PO<->XLIFF :Translators
SUN: XML<->SDF<->TMX :Translators

The PO->XLIFF and SDF->TMX conversions do not
encapsulate any code  
contents so we have all the code as translatable...

Even if PO were not used we'd still have:

XML<->SDF<->XLIFF
XML<->SDF<->TMX

Which is just as bad for the same reason: SDF removes all
XML benefit  
from the file since it flattens everything (with plenty of
ugly  
escapes) to text. And the current converters don't seem to
be smart  
enough to encapsulate all that anyway.

I have no idea why SUN can't do:

XML<->XLIFF(<->PO)
XML<->TMX


> I did not know about that ... You're of course
absolutely right  
> about losing everything.

I tried the last OOo 2.3 translation files with PO first and
gave up.  
Then I hacked the SDF to have something that looked like the
original  
XML and used OmegaT to translate. The results were very
satisfying,  
but the hack was a pain in the butt (it is documented on the
devl10n  
list).

JC
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

ACTUALLY, THIS SHOULD BE ON L10N-DEV. I THINK I SENT IT TO
THE WRONG  
LIST INITIALLY. SORRY. (I'M NOT QUITE SURE HOW THAT
HAPPENED... :S )

ON 09/08/2007, AT 10:32 PM, JEAN-CHRISTOPHE HELARY WROTE:

>
> ON 9 AO�T 07, AT 21:22, VITO SMOLEJ WROTE:
>
>> BACK-CONVERSION TO PO!?
>
> SUN: XML<->SDF<->PO<->XLIFF
:TRANSLATORS
> SUN: XML<->SDF<->TMX :TRANSLATORS
>
> THE PO->XLIFF AND SDF->TMX CONVERSIONS DO NOT
ENCAPSULATE ANY CODE  
> CONTENTS SO WE HAVE ALL THE CODE AS TRANSLATABLE...
>
> EVEN IF PO WERE NOT USED WE'D STILL HAVE:
>
> XML<->SDF<->XLIFF
> XML<->SDF<->TMX
>
> WHICH IS JUST AS BAD FOR THE SAME REASON: SDF REMOVES
ALL XML  
> BENEFIT FROM THE FILE SINCE IT FLATTENS EVERYTHING
(WITH PLENTY OF  
> UGLY ESCAPES) TO TEXT. AND THE CURRENT CONVERTERS DON'T
SEEM TO BE  
> SMART ENOUGH TO ENCAPSULATE ALL THAT ANYWAY.
>
> I HAVE NO IDEA WHY SUN CAN'T DO:
>
> XML<->XLIFF(<->PO)
> XML<->TMX
>
>
>> I DID NOT KNOW ABOUT THAT ... YOU'RE OF COURSE
ABSOLUTELY RIGHT  
>> ABOUT LOSING EVERYTHING.
>
> I TRIED THE LAST OOO 2.3 TRANSLATION FILES WITH PO
FIRST AND GAVE  
> UP. THEN I HACKED THE SDF TO HAVE SOMETHING THAT LOOKED
LIKE THE  
> ORIGINAL XML AND USED OMEGAT TO TRANSLATE. THE RESULTS
WERE VERY  
> SATISFYING, BUT THE HACK WAS A PAIN IN THE BUTT (IT IS
DOCUMENTED  
> ON THE DEVL10N LIST).

MY INITIAL EMAIL [A] WAS TO REQUEST THAT OPENOFFICE.ORG
CONVERT  
ENTIRELY TO XLIFF. THE SDF FORMAT IS EXTREMELY CUMBERSOME,
AND I'VE  
YET TO SEE ANY TRANSLATION BENEFIT IN IT WHATSOEVER. PO IS A
USEFUL  
TRANSLATION FORMAT, BUT XLIFF IS FAR SUPERIOR.

SO I'M NOT TALKING ABOUT CONVERTING BETWEEN SDF, PO AND
XLIFF, OR  
BETWEEN ANY COMBINATION OF THE THREE. I'M TALKING ABOUT
USING XLIFF  
AS THE BASE TRANSLATION FORMAT FOR OPENOFFICE.ORG.

TRANSLATORS CAN CHOOSE TO CONVERT BACK TO PO IF THEY LIKE,
SINCE WE  
ALREADY HAVE THE CONVERSION TOOLS, BUT THOSE OF US USING THE
XLIFF  
FORMAT WILL HAVE ITS MAJOR ADVANTAGES: AN XML STANDARD
DESIGNED FOR  
I18N. ITS METADATA CAPACITIES AND SHEER MANIPULABILITY ARE
WAY AHEAD  
OF PO FORMAT. (SINCE SDF FORMAT HAS NEITHER METADATA
CAPACITY OR ANY  
APPRECIABLE LEVEL OF MANIPULABILITY, I CAN'T COMPARE IT.)

IF OPENOFFICE.ORG ADOPTED OPENDOCUMENT, IT CERTAINLY SHOULD
ADOPT XLIFF.

SO, WHERE DO WE START? 

FROM CLYTIE (VI-VN, VIETNAMESE FREE-SOFTWARE TRANSLATION
TEAM / NH�M  
VI{�T H�A PHz�N M{�M T{� DO)
HTTP://GROUPS-BETA.GOOGLE.COM/GROUP/VI-VN

[A]
XLIFF IS THE STANDARD [1] FOR PROFESSIONAL TRANSLATION, AND
IS  
BECOMING THE STANDARD FOR FREE-SOFTWARE TRANSLATION.

IT IS XML FOR TRANSLATORS: EXTREMELY EASY TO MANIPULATE, AND
RICH  
WITH METADATA CAPABILITIES WHICH SAVE US A LOT OF TIME.

COMPARED EVEN TO PO FORMAT, XLIFF HAS SERIOUS ADVANTAGES. IT
IS  
EXACTLY WHAT WE NEED TO MANAGE THE COMPLEX BACKGROUND OF AN 

OPENOFFICE.ORG TRANSLATION FILE.

IT ALSO HANDLES DOCUMENT TRANSLATION EXTREMELY WELL, AND
ENHANCES TM  
CAPABILITY.

THERE ARE A NUMBER OF FREE-SOFTWARE TRANSLATION TOOLS
ALREADY  
AVAILABLE FOR XLIFF [2], AND POOTLE IS BASED ON XLIFF. MY
OFFLINE  
EDITOR, LOCFACTORYEDITOR, IS ALSO BASED ON XLIFF: I EXPECT
POOTLING,  
THE WORDFORGE OFFLINE EDITOR, IS AS WELL.

THERE ARE A GREAT MANY ADVANTAGES TO SWITCHING TO XLIFF.
WHEN CAN WE  
START? 

FROM CLYTIE (VI-VN, VIETNAMESE FREE-SOFTWARE TRANSLATION
TEAM / NH�M  
VI{�T H�A PHz�N M{�M T{� DO)
HTTP://GROUPS-BETA.GOOGLE.COM/GROUP/VI-VN

[1]
HTTP://WWW.OASIS-OPEN.ORG/COMMITTEES/XLIFF/DOCUMENTS/XLIFF-

SPECIFICATION.HTM

[2] E.G.
HTTP://XLIFF-TOOLS.FREEDESKTOP.ORG/WIKI/PROJECTS/XLIFFTOOL
HTTP://SOURCEFORGE.NET/PROJECTS/XLIFFROUNDTRIP

Clytie Siddall wrote:
>
> So I'm not talking about converting between SDF, PO and
XLIFF, or 
> between any combination of the three. I'm talking about
using XLIFF as 
> the base translation format for OpenOffice.org.
>
++

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

I HAVE SUBMITTED THIS AS AN ISSUE:

HTTP://QA.OPENOFFICE.ORG/ISSUES/SHOW_BUG.CGI?ID=80789

PLEASE ADD YOUR COMMENTS AND THE BENEFIT OF YOUR EXPERIENCE.


FROM CLYTIE (VI-VN, VIETNAMESE FREE-SOFTWARE TRANSLATION
TEAM / NH�M  
VI{�T H�A PHz�N M{�M T{� DO)
HTTP://GROUPS-BETA.GOOGLE.COM/GROUP/VI-VN

On Aug 17, 2007, at 10:28 PM, Clytie Siddall wrote:

> I have submitted this as an issue:
>
> http://qa.openoffice.org/issues/show_bug.cgi?id=80789
>
> Please add your comments and the benefit of your
experience. 

Thanks for the effort CLytie. I just added a comment. I hope
that  
will help.

Question: will Pootle be able to handle an XLIFF based
workflow ?

Cheers,

Jean-Christophe

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org