[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Re-ordering of inline codes
Hi David, all, > IMHO, the only important difference between 0 and C is the > distribution of the burden of knowing the start of every > sequence. > With 0, that burden is with Modifiers, but only in cases when > a previously populated target had adjacent non-reorderable > sequences. For option 0 the burden of referring to the source is always there: To know the previous target is [NnNn-] and not [nnnn-] or vice-versa, you have to look at the source. For option C the extractor's burden of setting the start of each sequence is minimal since you have access to all information in the original format. >> In other words: Currently we can only compare the source >> and the different target states, not a previous target >> state with a new one. >> It is difficult to say if this is a major drawback or not. >> ...the mechanism as it is prevents you to implement a tool >> to verify a change without access to the source content too. > > I do not think this is an issue since source is REQUIRED. I think you are looking at the problem the wrong way. The problem is not whether or not the source is available to do a comparison. It is that the validation is done through a comparison. A tool should be able to validate the re-ordering of the codes in a given content based solely on information in that content. XLIFF is just an exchange format: we shouldn't force tool requirements such as a dependency to the source to validate a target re-ordering when it can be avoided. In addition, having a required source in the XLIFF unit doesn't solve the missing feature of allowing two adjacent separate sequences of non-reordereable codes in the source. One can look at this from the tools' viewpoint: A tool XYZ can create localizable content with information about re-ordering permissions for the inline codes. XYZ has no restriction on the features it can implement and may offer allowing the move of adjacent fixed sequences. Now XYZ offers also a way to export/import XLIFF 2.0 documents. Currently such tool has no way to store all the metadata it needs in that XLIFF file. Its solution: use a custom extension to indicate which canReordered='no' is first of a sequence... Do we really want that? Maybe for once we could try to apply the tools requirements to XLIFF rather than find a way for XLIFF to foist upon the tools some limitations. :) We cannot possibly think about all the localization process requirements. But I think should try to accommodate the ones we know about that are inexpensive to make provision for. Option C: - is a very small change to the current specification. - ask very little extra from the extractors - offers true self-contained validation vs. comparison. - simplifies greatly the implementation of the modifiers (no more dependency on source). - ensures a more complete set of functionalities for re-ordering (adjacent sequences) Do we really want to keep option 0? > ...it is more expressive, not sure however if this bit of expressivity > makes it better than 0, which is less demanding for Extractors.. In my experience the extractor is always the easiest part. Cheers, -yves
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]