[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: XLIFF (was: Re: Options)
From:       "Renato Pavicic - Translator-shop.org" <renato () translator-shop ! org>
Date:       2006-06-04 18:49:43
Message-ID: 1041001817.20060604204943 () translator-shop ! org
[Download RAW message or body]

Hello Clytie,

Thanks for reply, but I knew all of that from before. I know the
general idea, but after 4 years in the army, I hate generals.

What I was wandering:
- Do you have THE xliff file?
- HOW do you test it after translation?
- what cat tool an I use (on windz) to translate xliff
- how many more programs do i have to install do use that app
- how many more programming languages do I have to learn
- can I use previous TM DB from like Trados
- DID ANYONE TEST THAT
- PLEASE, no general idea, rule, "read there" or "take a look"

Look, I've spent more time to understand how SVN works, than to figure
out how to translate PO file with ANY type of CAT tool. With that I
want to say how easy for me was to start translating PO. I have
private translating job, and I am NOT willing to learn any more of the
programming.

If I need to install some other java, python or similiar stuff and LEARN
those languages, than bye-bye!

Why? Cos I was trying to localize Nvu. Everybodey sayz it iz so-o-o
simple. Then I ask them "can you gimmie preped file, so I could just
translate, and not have to LEARN ANOTHER PROGRAMMING LANGUAGE!"
...... and..... no answer..... Becauza it iz so-o-o simple... yeah!
So-o-o simple that the developer of the app cannot prep me a file for
translation. :S 

Gentlemen, as I sad it before: It iz so-o-o simple to every programmer
to tell me what to do (in general), but they do not comprehend that an
average pro translator HAS TO KNOW MORE VARIOUS programming languages
that an average programmer!!

An excellen programmer, how many DIFFERENT prog languages does he/she
know? How many do I have to know? Following:
- python
- perl
- java
- c++
- c#
- html
- php
- varios db engines
and many more!

and, gotta know how to process:
- tmx
- ttx
- txt
- dvpjr
- xliff
- po
- go
- lng
- dll
- lsg
- cvs
- and god knows what else!
- and, are you tired of reading this list?
- do I have the right to be tired of working like this?

AND, every trans tool uses its own formats, databases, gui terminology
(there are as many terms for database as apps!), import and export,
testing (if possible), keyboard shortcuts, menu icons, menu items and
their order.......

My head is going to explode!

When you quoted xliff code, what am I supposed to do with it?!?!
Dunno, but I know what I will do... NOTHING!
Gimme tool, gimme file, gimmie option to use existent database or to
import and export within 5 minutus, or frankly my dear, I don't give a
damn.

Sorry if I reacted in a harsh way, but I cannot afford this any more.

If I don't hva cat tool, and ipom




Sunday, June 4, 2006, 10:02:49 AM, you wrote:


> On 04/06/2006, at 1:46 AM, Renato Pavicic - Translator-shop.org wrote:

>> I don't mind xliff if it's better for translators. Is it better for
>> translators? Or just for programmers?

> XLIFF is XML for translators. ;)

> It has specific tags which classify different parts of our job. It's
> very flexible, and practically transparent in use.

> One example of this is the TMX format, which is the XLIFF translation
> memory. Here's an example of the beginning of a TMX translation  
> memory doc (you don't necessarily see it this way, it's like X/HTML
> source in that respect):
> ___
> <?xml version="1.0" encoding="UTF-8"?>
> <tmx>
>      <header adminlang="en"
>          creationid="Clytie Siddall [clytie@riverland.net.au]"
>          creationtool="LocFactoryEditor TMX Export"
>          creationtoolversion="1.0" datatype="macres" o-tmf="AG3 WG/AD/
> LG"
>          segtype="block" srclang="en"/>
>      <body>
>          <tu srclang="en" tuid="1">
>              <tuv xml:lang="en">
>                  <seg>Pickle Lake</seg>
>              </tuv>
>              <tuv usagecount="1" xml:lang="vi">
>                  <seg>Pickle Lake</seg>
>              </tuv>
>          </tu>
>          <tu srclang="en" tuid="2">
>              <tuv xml:lang="en">
>                  <seg>
> gbiff2 could not load its user interface file (%s).\n
> Please make sure gbiff2 was installed correctly.</seg>
>              </tuv>
>              <tuv usagecount="1" xml:lang="vi">
>                  <seg>Trinh gbiff2 không t?i ðu?c t?p tin  
> giao di?n ngu?i dung c?a nó (%s).\n
> Hay ð?m b?o ða cai ð?t trinh gbiff2 cho ðúng.</seg>
>              </tuv>
>          </tu>
> ___

> You apply TMX just like applying PO compendia, except they're more  
> flexible and can handle a lot more specific information. You can see
> that it's just like any XML document, but with specific tags for  
> translation memory needs.
>>
>> I hope it's not like the stuff in mozilla. that's hard to translate
>> and even harder to test/distribute (if you never done it before! if
>> you did, that's another story. usually not my story)

> No, the whole idea of XLIFF is to avoid awkward barriers like the  
> Mozilla project translation format. It's a standard, and very easy to
> integrate and apply. My editor can convert a wide variety of  
> translation formats into and out of XLIFF, and Pootle can do even  
> more conversions, using the Translate Toolkit and po4a.
>>
>> I have never worked with xliff. could you please send me a sample?
>> Or, even better, could you point me to some small app, thet could be
>> translated via xliff?

> My translation editor (LocFactoryEditor for Mac OSX) handles both PO
> and XLIFF, doing what Pootle does, using XLIFF as the base and  
> displaying the PO files either in their normal form, or as XLIFF  
> docs. I wouldn't know the XLIFF were there, unless I asked to see it.
> Here's an example of a PO file string in PO format, then as I see it
> in LFE, then as LFE shows it to me in XLIFF if I ask for it:
> ___________
> 1. PO format:

> #. Type: text
> #. Description
> #: ../main-menu.templates:3
> msgid "Debian installer main menu"
> msgstr "Trinh ðon cai ð?t chính c?a Debian"
> ___________
> 2. Shown in my editor as a PO file (other panes etc. in the editor  
> give me a lot of other information about this string):

> po:2
> auto:   ?       Type: text
> auto:   ?       Description
> Original:       ?0      Debian installer main menu
> Vie?t:          Trinh ðon cai ð?t chính c?a Debian
> ___________
> 3. Shown in my editor as XLIFF:

> <trans-unit id=".po:2" ts="23">
>      <source xml:lang="en">Debian installer main menu</source>
>      <target xml:lang="vi">Trinh ðon cai ð?t chính c?a  
> Debian</target>
>      <note from="auto" priority="5">Type: text</note>
>      <note from="auto" priority="5">Description</note>
>      <context-group name="po-reference" purpose="location">
>          <context type="linenumber">3</context>
>          <context type="sourcefile">../main-menu.templates</context>
>      </context-group>
> </trans-unit>
> ____________

> XLIFF can handle a very wide variety of specific information, but  
> there's no need for you to see all the tags. The info will be handled
> by the editor, presenting you with the correct situation. But you can
> always see the exact data, any time you want.

> You can find out a lot more from the ITS page [1] and LISA [2], and
> there are already some useful tools based on XLIFF [3].

> There's a lot more to XLIFF than this, but I hope this has been of  
> some use. :)

> from Clytie (vi-VN, Vietnamese free-software translation team / nhóm
> Vi?t hóa ph?n m?m t? do)
> http://groups-beta.google.com/group/vi-VN

> [1] http://www.w3.org/International/its/

> [2] http://www.lisa.org/

> [3] http://xliff-tools.freedesktop.org/wiki/Projects/xlifftool
> http://sourceforge.net/projects/xliffroundtrip






-- 
Best regards,
 Renato

mailto:renato@translator-shop.org

www.translator-shop.org


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic