RE: [xliff] Translating XLIFF 1.2

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Tuesday, February 23, 2010 12:10 PM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Translating XLIFF 1.2
> 
> Good morning Rodolfo,
> 
> >> If a tool generates code where each <source> is an actual
> >> segment and does not uses <seg-source> to indicates that,
> >> it is still valid and following the specification, but it
> >> is simply not segmented from the view point of XLIFF. It's
> >> also sad because other tools won't be able to do much as
> >> far as manipulating segments in that file.
> >
> > Are you saying that tools that require <seg-source> are
> > unable to add it?
> 
> No. I'm saying that if <seg-source> is not there, that means the
> <source> has no segmentation information.
> 
> Another tool can read the file and apply its own segmentation, and if
> that specific <source> as only one sentence, find only one segment.
> 
> The problem is that because such file is not following the way XLIFF
> represents segmentation, the tool won't be able to see the different
> 'segments' as part of the same paragraph, and therefore won't be able
> to manipulate them as needed (e.g. let the translators join/resplit)
 

That's wrong. I've written tools that are able to merge/split segments without requiring <seg-source> or custom namespaces.


 
> > You said that segmentation belongs to translation domain,
> > so a translation tool that receives what you call an
> > "unsegmented" file should be able to "segment" it by
> > adding those <seg-source> you consider required for
> > interoperability.
> 
> I'm not the one calling or considering anything: the specification does
> :)
> 
> Segmentation is represented by <seg-source> (there is no fudging about
> that: I'm just reading the specification), therefore if it's not in the
> file, it means the file is not segmented.



That's again wrong. Nothing in the specs says that if a file does not use <seg-source> it is not segmented.

Segmentation can be applied to the source text and the resulting segments stored in <source> elements. 
 

> > If tools that use XLIFF 1.2 segmentation cannot segment
> > an unsegmented document, then something is wrong and it's
> > indeed a sad situation.
> 
> I have no idea where you are getting this from. Any tool can obviously
> apply some segmentation on the XLIFF it reads and use <seg-source> to
> represent it in the output.
> 
> What is sad is that if a tool creates XLIFF documents that use one
> trans-unit to store a single segment resulting from a segmentation, it
> does not follow the specification regarding segmentation and therefore
> does not allow other tools to be fully interoperable with its
> documents.


Where is it written in the specs that segmentation must be done using <seg-source>? 

The specification uses vague terms like "may be", "can", "typically" and "generally". It does not define what a segmented or unsegmented file is.

You indirectly admitted, the use of <seg-source> is optional. So, why do you say that applications that don't use <seg-source> don't follow the specification?



> Using that method is just like using a custom namespace with an non-
> XLIFF element that stored segment boundaries: It gives us a valid file,
> but uses a proprietary way of represent segmentation.


This statement is incorrect. The use of <source>/<target> is not a proprietary way of doing things. It's a way allowed in the specification. I strongly sugest you to read the definitions of <source> and <target>. Neither of them mention the word "segmentation" or <seg-source>. Those elements are described as the container for translatable text and translation. 


> The bottom line is that there is only one way to represent segmentation
> in XLIFF, it's the <seg-source> model. I personally think the
> specification is rather clear about it, but that it just my opinion. If
> there is another way described in the text, please point it to us.

There isn't only one way. There are many. I already gave you an example.

For start, there is no real need to "represent" segmentation in an XLIFF file. XLIFF is a container for translatable material. The required basics are holders for text to be translated and holders for the corresponding translation. The standard provides that in <source> and <target>.

If there is a need to represent segmentation, it can be done using <group> as I explained before. 

I see here a clear case of poor writing that reminds me the problem with SRX that required releasing a new version of the standard. The original authors failed to express their ideas in writing.

The intention of the people that added segmentation section was clear only for the authors. It was not properly described in the specification document.

The use of <seg-source> was left as optional when it should have been described as a required step in the translation process. 

All the justifications and explanations that you added in this mailing list are missing in the specification document.

The authors of the segmentation section did not consider that if something is optional, those that don't need it might not implement it. 

If representing segmentation using <seg-source> was considered essential for interoperability, it should have been written.

The specification lacks a clear explanation of the official workflow expected to be present in XLIFF based tools. If the intention is to require the use of <seg-source>, then "it may be important" is a poor choice of words for the introduction of Segmentation section.

All those ideas that you describe about the use of segmentation could have been useful, had they been written in the specs. 


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