OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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]