OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Re: [xliff] Conformance clause proposal

    Posted 06-01-2010 23:28 
    ----- "Rodolfo M. Raya"


  • 2.  RE: [xliff] Conformance clause proposal

    Posted 06-02-2010 13:16 
    Hi Asgeir,

Suppose that tool ABC creates XLIFF files with custom extensions.  John Translator receives one of those files and translates using XYZ. When he delivers the translated file, the client says that it is invalid because ABC can't open it. Common case today.

The maker of XYZ could use the schemas from ABC to ensure compatibility. Validating the file could reduce the number of errors caused by misinterpreted custom elements. This will not solve all problems, but will help.

There are cases when we don't have a solution. For example, there is a tool in the market today that doesn't read its own XLIFF files as XML. It fails in these two cases:

1) if you change this:


  • 3.  RE: [xliff] Conformance clause proposal

    Posted 06-03-2010 12:17 
    My hunch is that the problem isn't so much in making extension schemas public as it is creating them in the first place. If the XLIFF files are not processed with a validation XML parser, then there is little motivation to create the schemas.

Our extension schema is very simple, just a few custom attributes.





My frustration has been even being able to perform interoperability testing with the tools. Ektron is a CMS and so we are at the end points: extract and merge. We produce XLIFF documents for the translation tools and then consume translated XLIFF from the tools.

I've been able to do testing with Rodolfo's previous company Heartsome due to its low cost and Rodolfo's excellent responsiveness. We were able to fix a couple of problems.

When we started, Trados was most common, but it wasn't so much an XLIFF tool as it was an XML editor with an XLIFF DTD. It only supported XLIFF 1.0 and the file name extension had to be .xml, not .xlf. Additionally, the XLIFF had to prepopulate the TARGET element--since it was, after all, just an XML editor. My understanding is that SDL Trados no longer has these restrictions. I've not used it, but I did some interoperability testing with SDL last year.

Part of the problem at Ektron is that we are separated from the translator. We sell a product to our customer who then chooses a translator and most likely, the customer doesn't know what tools the translator is using. Even worse, sometimes the translator, if used to working with Word documents and  unaccustomed to translating software, may not be familiar with XLIFF. I've heard of one translator who wanted to charge their client (our customer) extra to reformat the XLIFF into their proprietary format.

Recalling the recent blog discussion on the quality of translation standards, I believe the fault lies in the lack of adoption by the industry as a whole (no vendor in particular) than it does with the standard itself. Interchange standards, by their nature, require at least two companies to cooperate closely. It's an investment not easily made by management comfortable working independently within their existing processes. 

If any tool vendors are willing to perform interoperability testing, please contact me.

Doug


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content