[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Source read only or modifiable?
Hi Rodolfo, all, > Normalizing spaces means modifying spaces. > It is a change that should not be allowed in > any stage if the xml:space attribute is set > to “preserve”. The question was: "Would a content *not* marked with xml:space=’preserve’ be considered modified if it gets normalized?" (in the context of having a "read-only" source). > Annotations using <mrk> alter source text. No more than <segment> elements. And we said re-segmenting was not considered a modification of the content. > If the tool that creates the XLIFF doesn’t add > <mrk> elements, then <mrk> elements should not be > present when the XLIFF returns to the original > tool for generating the translated file. I disagree. Like with <segment>, the merging tool can strip the <mrk>. By definition they are not part of the content to merge. This is how <mrk> is defined in 1.2 ("The <mrk> element is usually not generated by the extraction tool and it is not part of the tags used to merge the XLIFF file back into its original format.") and I certainly hope that the same principle will carry over in 2.0. > As we discussed the other day during the meeting, > changes done by a second tool should be temporary and > the original <source> restored before moving to the > next tool/stage. We discussed this when talking about inline codes (e.g. converting text to inline codes, i.e. adding codes). We were not talking about <mrk> at that time. > I proposed a solution for annotations some time ago > that used offsets stored as attributes in an element > outside <source> or <target>. Annotations don’t need > to alter the original source. They don’t need to be > inline elements at all, they can be optional elements > that live in a module. Your idea was discussed in the Inline Markup SC and unanimously found impractical for an XML exchange format. If XLIFF was a binary format in the other hands... But it's not. > There should not be any extra element added > during the translation process. Neither in <source> > nor in <target>. I disagree. We must be able to add/remove inline codes in the target. It's a basic requirement. Cheers, -yves