OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xliff-comment] XLIFF 2.0 Core finished?


On Tue, May 22, 2012 at 10:36 PM, Rodolfo M. Raya
<rmraya@maxprograms.com> wrote:
>> > 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.
>>
>> An original text is always initial. How else could one start?
>
> Start with original (or "initial") text stored in <source> elements. Put translations in <target> elements.

Exactly. Again, original text in <source>, any change or
interpretation in <target>.

>
>> 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?

-- 
Pål Eivind Jacobsen Nes


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]