[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-comment] XLIFF 2.0 Core finished?
> -----Original Message----- > From: Yves Savourel [mailto:firstname.lastname@example.org] > Sent: Tuesday, May 22, 2012 4:14 PM > To: 'Josep Condal'; email@example.com > Subject: RE: [xliff-comment] XLIFF 2.0 Core finished? > > > ...Actually, according to that wording, even an empty element > > <target></target> would be non-compliant unless the translation is > > precisely an empty string. > > > > For some reason, nearly all tools generating XLIFF, including the > > mainstream ones, are priming untranslated target strings with source > > strings. > > 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. Dictionaries define what a translation is and I haven't seen a definition that considers the original text as an "initial form". When XLIFF 1.2 specification was released there was no need to specify the meaning of "translation". Obviously, some developers didn't understand that part. I did not expect that there would be a need for defining what translation is, but XLIFF 2.0 will probably need to include a definition. Regards, Rodolfo M. Raya -- Rodolfo M. Raya firstname.lastname@example.org Maxprograms http://www.maxprograms.com