RE: Okapi Tikal Bug?

Hi Philip,

 

(CCing the Test mailing list rather than the main mailing list, since it’s more a testing problem)

 

I’m pretty sure the order of the attributes in the XML elements has no effects on how Tikal is processing <its:param>.

 

I’ve attached two input files: test1.xml (same astranslate9xml.xml) and test2.xml (same as test1.xml but with the version attribute placed first). They extract as test1.xml.xlf and test2.xml.xlf. Both results are the same except for the file names. I don’t get any exception or error.

 

The error you mention seems to be related to an XSL template which is not part of Tikal.

 

I’ve also run:

 

C:> tikal –x test1.xml

C:> tikal –m test1.xml.xlf –oe UTF-8 (to preserve the Japanese characters)

C:> tikal –x test1.out.xml

 

It goes without error, and both test1.xml.xlf and test1.out.xml.xlf are identical except for their filenames.

 

As for the re-ordering of the attributes in the merged file: I know it’s annoying when you want to compare, but there is nothing we can do about it. There are no provision to keep attributes in a given order in a DOM. Some XML parsers do a better job than other. But it’s out of our hands: the filter has no control about is done to the document until it is a parsed document. It’s the same as using single or double quotes for enclosing attribute values: we can’t know what was used in the input document as that information is lost in the parsing.

 

cheers,

-yves

 

 

 

From: Philip [mailto:Philip.Oduffy@ul.ie] 
Sent: Friday, January 18, 2013 2:12 PM
To: public-multilingualweb-lt@w3.org
Subject: Re: Okapi Tikal Bug?

 

Hi Yves,
   The extraction error is on our side and was caused by trying to re-extract the output file after it has been emerged back into it's original form.
The error was caused because merging back to it's original source format causes element attributes to be reordered in reverse alphabetical order, when we try to reextract this file it fails because the version tag has been changed from:



<its:rules xmlns:its= <http://www.w3.org/2005/11/its> "http://www.w3.org/2005/11/its" version="2.0"> 
 
to:
 
<its:rules version="2.0" xmlns:its= <http://www.w3.org/2005/11/its> "http://www.w3.org/2005/11/its"> 
 
this causes an exception in tikal on extraction. This masks the original error that we encountered:
 
Error on line 129 of intermediate.xsl:
  XPST0008: Variable LCID has not been declared
Failed to compile stylesheet. 1 error detected.
 
This error occurs when creating nodelist-with-its-information.xml by applying intermediate.xsl to translate9xml.xml.
 
While re-extracting a file that has been extracted and re-merged is not directly required for our testing. The reordering that occurs is not desirable, as extracting a file and re-merging the file results in a different output then the original without modification to the extracted file.
Regards,
Philip
 


On 18/01/13 19:08, Yves Savourel wrote:

Hi Philip,
 
I'm getting:
 
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2" xmlns:okp="okapi-framework:xliff-extensions" xmlns:its= <http://www.w3.org/2005/11/its> "http://www.w3.org/2005/11/its">
<file original="translate9xml.xml" source-language="en" target-language="fr" datatype="xml" okp:inputEncoding="UTF-8">
<body>
<trans-unit id="1">
<source xml:lang="en">Create a folder</source>
<target xml:lang="fr">Create a folder</target>
</trans-unit>
</body>
</file>
</xliff>
 
Without error when I try -x on translate9xml.xml with Tikal.
Which seems to be correct.
 
cheers,
-yves
 
 
From: Philip [mailto:Philip.Oduffy@ul.ie] 
Sent: Friday, January 18, 2013 10:25 AM
To: public-multilingualweb-lt@w3.org
Subject: Okapi Tikal Bug?
 
Hey All,
   The Okapi Tikal program I'm try to validate seems to have have a bug when run against the Translate9xml.xml
 
Translate9xml.xml:
<doc> 
  <its:rules xmlns:its= <http://www.w3.org/2005/11/its> "http://www.w3.org/2005/11/its" version="2.0"> 
    <its:param name="LCID">409</its:param> 
    <its:translateRule selector="/doc" translate="no"/> 
    <its:translateRule selector="//msg[@lcid=$LCID]" translate="yes"/> 
  </its:rules> 
  <msg lcid="409" num="1">Create a folder</msg> 
  <msg lcid="411" num="1">フォルダーを作成する</msg> 
  <msg lcid="407" num="1">Erstellen Sie einen Ordner</msg> 
  <msg lcid="40c" num="1">Créer un dossier</msg> 
</doc>
 
Okapi Error output:
Input: /var/www/converter/uploads/1c3927f182/testinput9xml.xml
 
ERROR: resolveVariable for variable LCID returning null
 
We think the bug arises because Tikal can't escape/populate the $LCID variable correctly. Does anyone know who we should notify from Okapi?
Thanks,
Philip

Attachments

Received on Friday, 18 January 2013 21:45:35 UTC