> -----Original Message-----
> From: Yves Savourel [mailto:]
> Sent: Tuesday, May 22, 2012 5:53 PM
> To:
> Subject: RE: [xliff-comment] XLIFF 2.0 Core finished?
>
> Hi Rodolfo, Josep, Pål, all,
>
> >> That's because, like Rodolfo interprets that the content of <target>
> >> can be blank, one can also interpret that a copy of the source is
> >> simply the translation in its initial form in a many steps process.
> >> After all the specification doesn't define what "translation" is.
> >
> > Well, actually my tools don't put <target> elements in untranslated
> > segments, not even blank ones. So, not all tools create invalid XLIFF
> > files.
>
> Actually they do. I can use the latest version of Swordfish (3.0-11 7DC-3-9) to
> save an XLIFF file that has both blank <target> elements and <target>
> elements with a copy of the source.
The original XLIFF that Swordfish creates doesn't have <target> elements. Users can add them at a later time as you did.
> The bottom line is that one or more attributes are the only way to indicate
> what exactly is in <target>.
>
> In 1.2 none of those attributes were required nor had default values, which
> make many valid 1.2 files difficult to interpret.
As I said before, that is not a problem with the specification. It is a problem with tools and how they are used.
> We simply need to come up with a good set of attributes/values and
> processing expectations in 2.0 to reflect the different states of the segments'
> translation.
The set included in XLIFF 1.2 was good enough for most cases. Perhaps XLIFF 2.0 should make them mandatory.
Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
