[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] XLIFF 2.0 Core
Hi all, It's been a while since I've made a contribution to this group, but I have a few observations: 1. I think "match" has a strong TM bias. To me, a (TM) match refers to the source while an MT string provides an alternative translation (for the target). What about "candidate"? The candidate type could then be defined using an attribute. 2. I fully agree with Rodolpho. If "note" and "match" are moved to a different namespace, it should be an official one. 3. I think it's very important to know whether something has already been segmented (this echoes one of Yves' earlier comments: "If there is a need to know whether a content has been through a segmentation process or not, we could also have an attribute for this."). Indicating the type of segmentation (sentence/word) at the attribute level seems useful. Kind regards, Johann Johann Roturier Principal Research Engineer, SES EMEA Shared Engineering Services Symantec Corporation www.symantec.com Office: (353) 1 861-7102 johann_roturier@symantec.com -----Original Message----- From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com] Sent: 07 April 2011 15:07 To: xliff@lists.oasis-open.org Subject: RE: [xliff] XLIFF 2.0 Core Hi Yves, SDLXLIFF files are plagued of custom elements around segments. I added multiple <ignorable> before and after a segment to support that. We could have matches at <unit> and at <segment> level but I'm not sure it is necessary. If you have a match at <unit> level generated from a paragraph, it can be segmented with the same mechanism you use to split the extracted text into <segments>. It's OK for me to move <match> and <note> to a different namespace, as long as it is an official namespace defined by the XLIFF TC. I can extend the XML Schema to include <xliff> and <file> elements. If there is agreement, I would create a separate schema for <match> and <note> and another one for a generic <inline> element (it would be a placeholder until the subcommittee finishes the definition of inline markup). I think that the core should not have <header> or equivalent. Do we agree? Regards, Rodolfo -- Rodolfo M. Raya <rmraya@maxprograms.com> Maxprograms http://www.maxprograms.com > -----Original Message----- > From: Yves Savourel [mailto:ysavourel@translate.com] > Sent: Thursday, April 07, 2011 10:25 AM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] XLIFF 2.0 Core > > Hi Rodolfo, all, > > Thanks for the XSD, it's very handy. > > I like the more specific <match> instead of the all-purpose <alt-trans>. > It makes sense to specialize the elements. > But I don't think candidate matches should be part of the core. (Same for > <note>). > To me the core would be just the data needed to extract, translate and > merge, with possibly a few meta-data like resname, restype, etc. that could > be considered as basic properties. > > Another though about <match>: We probably need to handle also the cases > where there are match candidates offer for both the whole unit and for each > segment, instead of just for each segment. Tools like WorldServer offer such > feature for example. > > Handling the "outside" extra spaces/codes with <ignorable> looks good. > Do we have a case for allowing multiple <ignorable> at each ends? I cannot > think of any tool that would have more than one inter-segment span. Not a > big issue: allowing 0 or more just makes it a bit less simple to handle. > > -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 --------------------------------------------------------------------- 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]