[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Simplified XLIFF element tree
Hi David, I don't like and don’t use <seg-source> plus <mrk mtype="seg">. I don't want to use anything like that. Regards, Rodolfo -- Rodolfo M. Raya <rmraya@maxprograms.com> Maxprograms http://www.maxprograms.com > -----Original Message----- > From: David Filip [mailto:DavidF@MoraviaWorldWide.com] > Sent: Tuesday, August 24, 2010 10:08 AM > To: Rodolfo M. Raya; xliff > Subject: RE: [xliff] Simplified XLIFF element tree > > My assumption was that using <trans-unit> as container for segmented > source would render <seg-source> obsolete along with <mrk mtype="seg"> > and "mid", but this can only be achieved if unsegmented is driven to an > obligatory <extr-text>. > Isn't that attractive for you, Rodolfo? You do not seem to love <seg-source> > and <mrk>, do you? > > -----Original Message----- > From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com] > Sent: Tuesday, August 24, 2010 2:33 PM > To: 'xliff' > Subject: RE: [xliff] Simplified XLIFF element tree > > > > -----Original Message----- > > From: Yves Savourel [mailto:ysavourel@translate.com] > > Sent: Tuesday, August 24, 2010 9:23 AM > > To: 'xliff' > > Subject: RE: [xliff] Simplified XLIFF element tree > > > > Hi Rodolfo, all, > > > > >> It seems it would be simpler to have one element for each extracted > > >> unit, and the un/segmented information inside that element: Any type > > >> of parser can access all of it at once, no need for linking or other > > >> extra mechanism; finding/fixing/editing files is easier; etc. > > > > > > > > > Please keep unsegmented information separate from translatable > > segments. > > > Like Andrzej, I don't plan to put unsegmented text in my XLIFF files. > > > A common parent for unsegmented/segmented would be annoying > unless > > it > > > is optional. > > > > > > Unsegmented text should be optional, as it is not needed for translating > > > a segmented XLIFF. Unsegmented text should not be in the core XLIFF > > > module, it should live in a separate optional namespace. > > > > > > Having the un-segmented text not part of the core and living in a separate > > optional namespace is a strange idea. > > > > The first goal of XLIFF is to represent extracted text, not segmented > > extracted text. > > The representation of the segmentation is what should be optional. > > Text should be segmented in order to be translated. Unsegmented text is > not required for translating. > > In the last sample tree I sent I included elements for holding unsegmented > text (<extr-text>) and elements for holding translatable text (<trans-unit>). > > I don't plan to include unsegmented text in the XLIFF files generated by my > tools. I hope you don't force me to include it, because if you do, I will have to > seriously consider discarding support for XLIFF 2.0. It would be perfectly fine > for me if you include unsegmented text in the XLIFF files generated by your > tools, as long as I can safely ignore it. > > Regards, > Rodolfo > -- > Rodolfo M. Raya <rmraya@maxprograms.com> > Maxprograms http://www.maxprograms.com > > > > --------------------------------------------------------------------- > 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]