[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,
For option 0 the burden of referring to the source is always there: To know the previous target is [NnNn-] and not [nnnn-] or
> 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.
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.
>> ...the mechanism as it is prevents you to implement a tool
>> 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.
>> to verify a change without access to the source content too.I think you are looking at the problem the wrong way.
>
> I do not think this is an issue since source is REQUIRED.
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]