[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Simplified XLIFF element tree
Hi David, I will not attend to the face to face meeting in Limerick so I prefer this issue to be discussed via email or in the next regular meetings. Let me summarize my position: - I don't care if some tools include unsegmented text in their XLIFF files if my tools can safely ignore it. - I don't want to include unsegmented text in the XLIFF files generated by my tools. - If unsegmented text is present in a file, I want it to be clearly separated from translatable segments. 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:13 AM > To: Yves Savourel; xliff > Subject: RE: [xliff] Simplified XLIFF element tree > > Hi all, > It seems that most of us are more or less comfortable with having an extra > layer for unsegmented, just extracted.. Same as Yves I believe that the > unsegmented should be obligatory. But people like Andrzej and Rodolfo may > have valid reasons for doing it the other way round..[although I agree with > Asgeir and Yves that Andrzej can have more robust relationship with xml:tm > in the new proposed setting] > > I believe that we do not get any further without some solid use case analysis > IMHO we need to figure out rather combinatorically what is the hierarchical > relationship of > > <group> > <extr-text> > <trans-unit> > > Which of them belong to XLIFF 2.0 core and how each of the possible > combinations captures various content lifecycle scenarios > > I suggest to not continue this thread until the f-t-f and Symposium in > Limerick. > I believe that supporting use cases should be presented there.. > > Rgds > dF > > > > David Filip > Director, Research > ============================== > www.moraviaworldwide.com > Phone: + 420-545-552-203 > Fax: + 420-545-552-233 > Mobile: + 420-731-492244 > E-mail: davidf@moraviaworldwide.com > ============================== > > Děkujeme, že zvažujete dopad tisku emailů na životní prostředí./ Thank you > for considering the environmental impact of printing emails. > > > -----Original Message----- > From: Yves Savourel [mailto:ysavourel@translate.com] > Sent: Tuesday, August 24, 2010 2:23 PM > 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. > > Cheers, > -ys > > > > --------------------------------------------------------------------- > 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]