dealing with tags

[Manuel Souto Pico]

Hello,

I have to review some translated XLIFF en-gl files with many many tags and I have some difficulties. Some segments have 98% of tags and 2% of text to review.

This is what happens with the different tools that I have.

1. - OLT 1.3.0: I can't use it because it crashes all the time
2. - OmegaT 2.0.5: I can't import the XLIFF so that the English appears in the source and the Galician in the target language (the Galician appers in the source segment).
3. - Qt Linguist 4.5.2 and CafeTran 2009120801: they don't protect the tags and they are not even colored differently from the text, so it's very difficult to know what is the text that must be reviewed and what is the tag that must not be touched.
4. - Virtaal and Transolution: I am not able to run Python applications in mac.

Do you have any suggestion to overcome these problems? (especially problems 2 and 3). Or can you suggest another freely available tool that I'm not aware of that would meet my requirements?

Eternally grateful,
Manuel

[Jean-Christophe Helary]

On 17 déc. 09, at 08:25, Manuel Souto Pico wrote:

> 1. - OLT 1.3.0: I can't use it because it crashes all the time

Send the file to the OLT developer.

> 2. - OmegaT 2.0.5: I can't import the XLIFF so that the English appears in
> the source and the Galician in the target language (the Galician appers in
> the source segment).

Use Rainbow to convert your file:
http://mac4translators.blogspot.com/2009/08/rainbow-xliff-and-omegat.html

> 3. - Qt Linguist 4.5.2 and CafeTran 2009120801: they don't protect the tags
> and they are not even colored differently from the text, so it's very
> difficult to know what is the text that must be reviewed and what is the tag
> that must not be touched.

I don't know.

> 4. - Virtaal and Transolution: I am not able to run Python applications in
> mac.

You should be. But Virtaal is a little bit non trivial to install on a Mac.
They have an IRC channel for support. You should ask there, they are very helpful.

Jean-Christophe Helary
---------------------------------
fun: mac4translators.blogspot.com
work: www.doublet.jp (ja/en > fr)
tweets: @brandelune

[Manuel Souto Pico]

Thanks a lot, Jean-Christophe!

I'll try out your suggestions :)

Cheers, Mannel

2009/12/17 Jean-Christophe Helary <jean.christ...@gmail.com>

--
You received this message because you are subscribed to the Google
Groups "Mac for Translators" group.
To post to this group, send email to
mac-for-t...@googlegroups.com
To unsubscribe from this group, send email to
mac-for-transla...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mac-for-translators?hl=en

[Jean-Christophe Helary]

On 17 déc. 09, at 09:22, Manuel Souto Pico wrote:

> Thanks a lot, Jean-Christophe!
>
> I'll try out your suggestions :)

If you can't use OLT, I think your best hope is OmegaT.

When you convert with a recent Rainbow snapshot, you will get a full OmegaT project with the following TMX files:

- project_save.tmx is the group of segments that were approved in the XLIFF. They are considered as translated and will show as such in OmegaT

- unaproved.tmx is the group of segments that were not explicitly approved in the XLIFF. They are considered as reference translation in OmegaT and you'll have to validate one by one as you enter the corresponding segments.

- alternate.tmx is the group of segments that were given as reference in the XLIFF. They are considered as reference translation in OmegaT.

I don't remember how Rainbow handles tags so you may have a similar number of tags in OmegaT.

Jean-Christophe

[Rodolfo Raya]

Use Swordfish instead.

If you want comfortable reading, open the file in Swordfish and
"Preview Translation" (press F5). Text will be displayed in your
browser with or without tags (your choice).

Regards,
Rodolfo
--
Rodolfo M. Raya <rmr...@maxprograms.com>
http://www.maxprograms.com

[Chris Moore]

Or use AppleTrans… which let's you see the styled text as styled text
and doesn't use any kinds of tagging systems.

More info: http://howtoappletrans.blogspot.com/2009/12/preface-why_16.html

Chris Moore

2009/12/17 Rodolfo Raya <rmr...@gmail.com>:

[Jean-Christophe Helary]

On 17 déc. 09, at 18:02, Rodolfo Raya wrote:

>> Do you have any suggestion to overcome these problems? (especially problems
>> 2 and 3). Or can you suggest another freely available tool that I'm not
>> aware of that would meet my requirements?
>
> Use Swordfish instead.

Swordfish has a free demo that runs unlimited for a month, but besides for that I don't see how it qualifies as a "freely available tool".

[Jean-Christophe Helary]

On 17 déc. 09, at 18:04, Chris Moore wrote:

> Or use AppleTrans… which let's you see the styled text as styled text
> and doesn't use any kinds of tagging systems.

AppleTrans does not do XLIFF.

>> On Wed, Dec 16, 2009 at 9:25 PM, Manuel Souto Pico <m.sou...@gmail.com> wrote:
>>> Hello,
>>>
>>> I have to review some translated XLIFF en-gl files

[Elmars Sumanis]

2009/12/17 Manuel Souto Pico <m.sou...@gmail.com>

3. - Qt Linguist 4.5.2 and CafeTran 2009120801: they don't protect the tags and they are not even colored differently from the text, so it's very difficult to know what is the text that must be reviewed and what is the tag that must not be touched.

It is very strange to hear that, in CafeTran, tags "are not even colored differently from the text"... In my version of CafeTran (2009120601), XLIFF tags are shown as numbers (in different color from text), and the application warns about lack of tag in the Target window.

Did you open the XLIFF file as Project?

Greetings,

Elmars

[Manuel Souto Pico]

Dear all, 

I'm really thankful for all your replies. 

Briefly: AppleTrans doesn't seem to support XLIFF, no. SwordFish is not free and I've already used the free month long ago (by the way, I think it's a great tool but the user interface --the fix-sized segment windows, mainly-- really puts me off). 

About CafeTran, Elmars: are we both refering to the same kind of tags? I meant so-called inline tags, those you have inside the <source> or the <target> elements. 

For example, how does your CafeTran version handle the file attached? (if no attachements are allowed, I'll send it in the body of the mail later).

Thank you all once again. 

Cheers, Manuel

2009/12/17 Elmars Sumanis <elma...@gmail.com>

[Jean-Christophe Helary]

On 18 déc. 09, at 01:21, Manuel Souto Pico wrote:

> For example, how does your CafeTran version handle the file attached? (if no
> attachements are allowed, I'll send it in the body of the mail later).

Or send directly to Elmars.

[Yves Savourel]

Hi Manuel,

> ...

> For example, how does your CafeTran version handle the
> file attached? (if no attachements are allowed, I'll send
> it in the body of the mail later).

> ...

In the file attached you have XLIFF elements the '<' and '>' of the inline elements are
escaped. If this true (and not some accidental issue with the attachment), that may
explain some behaviors you see.

For example you have:

"<source>&lt;bx clone="no" id="oPARAGRAPH.0.null" rid="PARAGRAPH.0.null"/&gt;..."

Where is should be:

"<source><bx clone="no" id="oPARAGRAPH.0.null" rid="PARAGRAPH.0.null"/>..."

Any XLIFF editor or processor will see the content of this <source> has text, no inline
code.

Cheers,
-yves

[Manuel Souto Pico]

Hi Yves, 

Yes, I noticed that, but I thought that line tags should be represented that way to distinguish them from the tags that make the structure of the XLIFF document.

I also thought about replacing &lt; and &gt; but these are very complex files and I don't understand everything in their structure. I'm afraid to make them unusable or not being able to restore these characters to their original entity reference before delivering.

I didn't know either that that was the problem. I'll give it a bit more thought and will retry with the tools above-mentioned.

Thanks a lot!

Manuel

2009/12/17 Yves Savourel <yv...@opentag.com>

[Yves Savourel]

> Yes, I noticed that, but I thought that line tags should
> be represented that way to distinguish them from the
> tags that make the structure of the XLIFF document.
> I also thought about replacing &lt; and &gt; but these
> are very complex files and I don't understand everything
> in their structure. I'm afraid to make them unusable or
> not being able to restore these characters to their
> original entity reference before delivering.

They are indeed complicated-looking files :)

You can replace "&lt;bx " by "<bx ", "&lt;ex " by "<ex ", and all "&gt;" by ">". That
should make this file a real XLIFF document.

Note the "&gt;" by ">" replaces *all* escaped '<' even if there are legit escapes, but
it's OK: '<' does not need to be escaped in XML (except in very specific CDATA cases which
you don't have here).

Keep well,
-ys

[Manuel Souto Pico]

Thanks, Yves and Elmars,

See below. 

2009/12/17 Yves Savourel <yv...@opentag.com>

> Yes, I noticed that, but I thought that line tags should
> be represented that way to distinguish them from the
> tags that make the structure of the XLIFF document.
> I also thought about replacing &lt; and &gt; but these
> are very complex files and I don't understand everything
> in their structure. I'm afraid to make them unusable or
> not being able to restore these characters to their
> original entity reference before delivering.

They are indeed complicated-looking files :)

You can replace "&lt;bx " by "<bx ", "&lt;ex " by "<ex ", and all "&gt;" by ">". That
should make this file a real XLIFF document.

Do you mean mine are fake? ;) 

I had a look at the elements whose angle brackets were referenced (is that the right way to say that they are &coded;?). It seems I could do s/&lt;/</ and s/&gt/>/ and I'd have a document I can work with in CafeTran. To restore it, I think it would suffice doing 

s/<(/?)(bx|b|span|br|ex)(>| [^>]+>)/\&lt;\1\2\3\&gt;/

and then diff-compare the new file with the original one to check that nothing else needs to be restored (some things will).

The problem is that I would need to check what elements are affected by this in each document that I work with.

And doing this is really a pain :( 

Note the "&gt;" by ">" replaces *all* escaped '<' even if there are legit escapes, but
it's OK: '<' does not need to be escaped in XML (except in very specific CDATA cases which
you don't have here).

I didn't understand this paragraph, sorry. If you want to explain, I'm interested.

Thanks again, Yves.

Regards, Manuel 

[Yves Savourel]

>> You can replace "&lt;bx " by "<bx ", "&lt;ex " by "<ex ",
>> and all "&gt;" by ">". That
>> should make this file a real XLIFF document.
>
> Do you mean mine are fake? ;) 

Kind of :) It does not have its inline codes coded properly. With "<bx " and "<ex "
written "&lt;bx " and "&lt;ex " the codes are really text from an XML (and XLIFF)
viewpoint.

> It seems I could do s/&lt;/</ and s/&gt/>/ and I'd have a
> document I can work with in CafeTran. To restore it, I
> think it would suffice doing 
> s/<(/?)(bx|b|span|br|ex)(>| [^>]+>)/\&lt;\1\2\3\&gt;/

Don't replace all "&lt;" by "<": in many case the content has '<' that should be escaped.
Replace only the ones just before "bx " and "ex " (in this file <bx...> and <ex...> are
the only inline codes you have).

> And doing this is really a pain :( 

Yep. Complain to whoever generated the document. That won't solve the problem, but you'll
feel better :)

>> Note the "&gt;" by ">" replaces *all* escaped '<' even if
>> there are legit escapes, but
>> it's OK: '<' does not need to be escaped in XML (except
>> in very specific CDATA cases which
>> you don't have here).
>
> I didn't understand this paragraph, sorry. If you want to
> explain, I'm interested.

I was just saying that the character '>' does not need to be escape in 99% of the case
(including in your file), so you can safely change all "&gt;" by '>' (and don't have to
convert it back).

Good luck,
-ys

[Manuel Souto Pico]

Hi again, 

I'm afraid it's not so simple. I've searched for

&lt;([eb]x[^&]+)/&gt;

and replaced it with

<$1/>

The result when I try to import the XLIFF file in OLT or CafeTran is the same, the project failed to load. I get a message saying: 

The prefix "cba" for attribute "cba:alignment" associated with an element type "bx" is not bound. 

I think this is becoming more like the topic for an XLIFF discussion list and not for M4T, but still I'd dare send a sample trans-unit before and after that edit if you want to look at it.

I thought XLIFF was simple... :(

Thank you very much, and keep well.

Manuel

2009/12/17 Yves Savourel <yv...@opentag.com>

>> You can replace "&lt;bx " by "<bx ", "&lt;ex " by "<ex ",

--

[Yves Savourel]

I’ve attached the “fixed” XLIFF of your initial example. It’s a valid XLIFF 1.1 file. For example, it passes XLIFFChecker, the nice open-source validator Rodolfo is providing to the community (http://www.maxprograms.com/products/xliffchecker.html). I can also process it with Rainbow.

 

The issue with the ‘cba’ thing is probably related to how CaféTran deal with namespaces. There are alas quite a few XLIFF tools that don’t deal very well with namespaces, maybe CaféTran is one of them.

 

Hope this helps,

-ys

[Marian Dougan]

Dear all -

I've decided to use my gmail address for the Mac for Translators

Group so grateful if you could change it to douga...@gmail.com

My new work address is m...@dnalanguage.com

Thanks!

Marian

--

DNA Language
t/f: +44-(0)141-942-0919
m: ++44-07733-327691
e: m...@dnalanguage.com
w: www.dnalanguage.com
b: wordstogoodeffect.wordpress.com

http://groups.google.com/group/mac-for-translators?hl=en<xliff_test_for_cafetran.xlf>

[Manuel Souto Pico]

Yes, I forgot to mention that, assuming that CafeTran and OLT's error messages come from an internal XLIFF checker alike Rodolfo's tool, as the message I get in those tools is exactly the same as the one I get from XLIFFChecker, that is: 

Validating: <file>.xlf 

 * Error while validating:

[Fatal Error] 151:305 The prefix "cba" for attribute "cba:alignment" associated with an element type "bx" is not bound.

Selected file is not valid XLIFF.

The original file, however, is perfectly valid according to XLIFFChecker. This is line 151 (fixed), quoted in the error message: 

        <source><bx clone="no" id="oPARAGRAPH.0.null" rid="PARAGRAPH.0.null"/><bx clone="yes" id="oPHRASE.0.null" rid="PHRASE.0.null" cba:alignment="LEFT" cba:bold="true" cba:supersubscriptbaseliney="0" cba:fontcolor="-1" cba:fontname="Arial" cba:italic="false" cba:fontsize="18" cba:underlined="false"/>Discussion Forum<ex id="cPHRASE.0.null" rid="PHRASE.0.null"/><ex id="cPARAGRAPH.0.null" rid="PARAGRAPH.0.null"/></source>

So as you can see, there's nothing wrong there. The good news is that I've been able to fix it, in a moment of clairvoyance. Just adding the xmlns:cba namespace to the root element <xliff>. So, yes, thanks Yves, it did help, because it made me think about what is differnet among the two files :) 

Now I can open the file both in OLT and CafeTran, but in OLT (the tool I was supposed to use for this) tags are not shown, and that makes me think whether it is possible now to remove the tags unwittingly (if you don't see them, and you delete the area where a inline tag should be, then you might delete the tag as well). Fortunately there's a format check, but I wonder how well it works. I'm running some tests on that. 

So, this is one step forward, but OLT keeps crashing in Mac, and in CafeTran I can only see up to 8 segments. I'll ask for help tomorrow if I don't find a way through. 

Thank you all very much, really. I have learned something today :) 

Cheers, Manuel