[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Simplified XLIFF element tree
----- "Andrzej Zydron" <azydron@xtm-intl.com> wrote: > For pre-segmented XLIFF systems: > > <group id='e1' extype='para'> > <trans-unit id='u1'> > <source>This is the first sentence.</source> > <target>Pierwsze zdanie.</target> > </trans-unit> > <trans-unit id='u2'> > <source>This is the second sentence.</source> > <target>Drugie zdanie.</target> > </trans-unit> > </group> > > For unsegmented XLIFF systems a solution might be: > > <group id='e1' extype='para'> > <extr-text id='e1'> > This is the first sentence. This is the second sentence. > </ext-text> > </group> > > The segmenting XLIFF editor would then generate the following: > > <group id='e1' extype='para'> > <extr-text id='e1'> > This is the first sentence. This is the second sentence. > </extr-text> > <trans-unit id='u1'> > <source>This is the first sentence.</source> > <target>Pierwsze zdanie.</target> > </trans-unit> > <trans-unit id='u2'> > <source>This is the second sentence.</source> > <target>Drugie zdanie.</target> > </trans-unit> > </group> I see a few flaws with this approach: 1) Having to duplicate source text ( -> same approach as <seg-source>) 2) No easy way of re-arranging segments 3) No easy way of storing data that is between segments 4) Every trans-unit in the file will be within a group element, even though it's one segment 5) It's going to be a pain to work with in editors and processing tools, as <trans-unit> elements would have to be created on demand based on if it segmented or not. And on re-segmentation, the <source> would change. 6) If <extr-text> is 'optional' it creates even more problems.. > The benefit of using 'group' in this way is that we are not inventing > new elements and is totally backwards compatible with XLIFF 1.2. The > last thing we want to do is to introduce any fundamental change to the > XLIFF structure. For non-segmenting systems we have the new optional > <extr-text> element. This should solve both problems. I think this touches on the core of this discussion. Part of what I and others will present over the symposium is really a major revision of XLIFF towards a 2.0 version, rather than minor backwards compatible changes. Tools that work with 1.x today will not work with 2.0 without modification. Great to see the discussion on 2.0 pick up! cheers, asgeir
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]