Re: [xliff] Re: XLIFF 1.2 Committee Draft Spec

["Rodolfo M. Raya" <rmraya@heartsome.net>]

Hi All,

Some details that need attention:

1) In section 3.2.5 the description of <mrk> element mentions the optional attribute equiv-text but the attribute is not included in the list of optional attributes for that element.

2) The example in section 2.5.2 is supposed to illustrate how to use attributes from XHTML. The name space declared in the listing corresponds to HTML 4.0 (which is not XML). The URI used to identify XHTML namespace is "http://www.w3.org/1999/xhtml"

3) <seg-source> is a new element born with old bad habits. It has an optional "ts" attribute that is deprecated. I don't see a reason for adding deprecated stuff to something new. 

4) <bin-target> has "restype" and "resname" attributes; <bin-source> doesn't. Those attributes are optional in <bin-unit> and I don't see a reason to override in the target something that is not required in the source. Keeping the attributes at <bin-unit> level should be enough, but if for some reason it isn't, the same reasons should be also valid for adding the attributes to<bin-source>

5) The first example in section 2.9 (Segmentation) is:

<source>Richard stepped out of the kitchen hut. He noticed a movement from the corner of his eye. A monkey had 
climbed on top of one of the workshop sheds, trying to get in by the ventilation shaft.</source>
<seg-source>
 <mrk mtype="seg">Richard stepped out of the kitchen hut.</mrk>
 <mrk mtype="seg">He noticed a movement from the corner of his eye.</mrk>
 <mrk mtype="seg">A monkey had climbed on top of one of the workshop sheds, trying to get in by the ventilation 
 shaft.</mrk>
</seg-source>

and the text below it says:

>     In the example above the space characters between the sentences are not included inside the <mrk> elements.
>     
Those spaces are relevant at translation time. IMHO, they should be included in the <mrk> elements. 

Given the new segmentation, CAT tools should offer the text enclosed in <mrk> elements to the translator instead of the content from <source>. If translators don't see the spaces, they can't correct them. Two special cases come to my mind:

• When translating from English to Chinese, the spaces between sentences should be removed. If a filter removed those spaces automatically, the reverse conversion filter may try to add them back also automatically. The result will be wrong.
• When translating to French, the spaces between sentences may need to be duplicated. In Canadian French or French from France (I don't remember in which one at this moment) it is considered good style to put two spaces between sentences. If an automatic filter adds only one, then the output may not look as nice as the translator spects.

FWIW, I've seen the problems described above happen in real life.

6) The last item in this list is a minor typographical error. In definition of <group> element there are two periods at the end of "within the same <file>.."

It's time to take a break now.

Best regards,
Rodolfo


On Mon, 2006-05-08 at 15:50 -0700, Tony Jewtushenko wrote:
>     Sorry folks - the archive I sent earlier omitted the 1.2 XSD 's.  The attached archive is complete... apologies for any inconvenience...
>      
>     Regards,
>     Tony
>     
>     Tony Jewtushenko <tony.jewtushenko@productinnovator.com> wrote:
> >         I've attached a revised version of the XLIFF 1.2 Committee Draft.  The revisions consist mainly of cleaning up some broken links, awkward language and revising both sample files (strict and transitional) to include an example of an mrk for protected content - see trans-unit id="_1_ski_2203".
> >     
> >          
> >     
> >         The plan is to create a ballot tomorrow to accept this spec along with recent revisions of HTML, Java Resource Bundle and PO/POT file representation guides.  Looks like we'll drop the .NET representation guide from our list of 1.2 deliverable. The ballot will commence tomorrow - 9 May and run for a week - ending a hour before our next TC meeting on 16 May.  If a serious problem is found before tomorrow and I am made aware of it before hand I will make an effort to fix it if possible, publish and proceed with ballot as planned. If a serious problem is discovered during balloting,  the ballot will be terminated, the fix made if possible, and we will vote on accepting the said work as Committee Spec via role call vote at the teleconference.
> >     
> >          
> >     
> >         We're in the end - game now,  so it would be very much appreciated if everyone could make an extra special effort to attend these next couple of teleconferences so we can complete our objectives successfully.  We're very close to reaching our goal and publicly publishing 1.2, so non-quorate meetings have an especially high cost now.
> >     
> >          
> >     
> >         Thanks, 
> >     
> >         Tony
> >     
> >         
> >         
> >     
>     
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--
The information in this e-mail is intended strictly for the addressee, without prejudices, as a confidential document. Should it reach you, not being the addressee, it is not to be made accessible to any other unauthorised person or copied, distributed or disclosed to any other third party as this would constitute an unlawful act under certain circumstances, unless prior approval is given for its transmission. The content of this e-mail is solely that of the sender and not necessarily that of Heartsome.