[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: Pål Eivind J Nes [mailto:email@example.com] > Sent: Tuesday, May 22, 2012 5:44 PM > To: Rodolfo M. Raya > Cc: Josep Condal; firstname.lastname@example.org > Subject: Re: [xliff-comment] XLIFF 2.0 Core finished? > > >> Any tool processing XLIFF should treat missing and empty > >> target-elements the same as above. There is no information, so we > >> should default to giving none. > >> > >> Feel free to set me straight. :) > > > > Any tool that sees that a <target> element is missing can offer to insert a > <target> element in the XLIFF file as a container for the translation of the > sibling <source> element. Notice that a <target> element is a container for a > translation, not a container for a copy of <source>. There are, of course, > cases in which the source text and its translations are the same, like when > the source text is a brand name. These cases are exceptions, not the rule. > > I concur. <target> should never be a copy of <source>. However, I see that > users might opt for a string compared to none at all. Should we allow > mechanisms for users to say that non-translated strings are good or not? If a user does not want to translate a segment, then user can leave the segment with just <source> and no <target>. There is nothing wrong with that. Regards, Rodolfo -- Rodolfo M. Raya email@example.com Maxprograms http://www.maxprograms.com