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