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

Subject: Re: [xliff] reformat discussion

Hi Tony,

I guess I may have jumped the gun slightly and perhaps should have verified and clarified my thoughts further before sending them.
Your described approach will indeed work in the absence of text, though I still think it is somewhat inelegant. This is mainly due to the fact that the source information for translation is contained in the <trans-unit> as opposed to the <source>. Also I consider an empty <source> to be misleading and un-intuitive.
However, its much to late for this discussion now, especially in the light of Doug's recent proposal to solve the 'reformat' requirement.


Mark Levins
IBM Software Group,
Dublin Software Laboratory,
Airways Industrial Estate,
Dublin 17,
Phone: +353 1 704 6676
IBM Tie Line 166676

Tony Jewtushenko <Tony.Jewtushenko@oracle.com>

24/01/2003 15:44

Mark Levins/Ireland/IBM@LOTUSINT, xliff@lists.oasis-open.org
Re: [xliff] reformat discussion

Hi Mark and all:
"XLIFF does not currently provide a mechanism for  the localization of localizable data in the absence of text. It is also  inelegant and unintuitive in its approach to modifiable data associated with  text and lacks the ability to indicate the presence of modifiable or, more  importantly, non-modifiable data".  

Unless I'm missing something,   XLIFF already provides an adequate means for localizing localizable  data in the absence of text.  If a trans-unit is marked as  "translate=no",  and the source and target are left empty of text  (ie,  absent of text),  then why can't the coord,  style,   css-style, etc.,  attributes be specified at the trans-unit (indicating  source value) and,  if different,  the target (indicating  localized value) level?  Some of this issue was covered by the recent  xliff comments mailing list discussion,  but I thought the only issue  remaining unresolved is identifying attributes that could or couldn't be  changed in the target.  There were some additional discussions  about defining standard profiles to be used as templates for specific  resource types,  but that doesn't specifically preclude support for  "localizable data in the absence of text".
Can you please expand on your statement?   We (at Oracle) make frequent use  of text-absent trans-units,  and once the reformat issue is  resolved (per, say,  Doug's suggestion) I don't grok any remaining  limitations that would limit XLIFF from supporting any "localizable data in  the absence of text".  In fact,  the solution is quite elegant and  easy to read,  in my opinion,  and I'm not sure that significant  architectural changes at any point in the future would improve it.  Why  doesn't </source translate="no"></target coord=x,y,x1,y1>  work?
----- Original Message -----
From:  Mark  Levins
To: xliff@lists.oasis-open.org
Sent: Thursday, January 23, 2003 6:00  PM
Subject: [xliff] reformat  discussion

Following the recent emails from Yves, John and Matt  (via Tony) and Tony I figured I'd add a few of my own thoughts...  

Both Yves and John have tabled very  strong arguments for the deferral of the changes to our next major release. I  fully agree with the need to get XLIFF out there and published formally as  soon as possible. However, in the light of the amount of time it has taken to  'rubber-stamp' XLIFF 1.0 under the umbrella of OASIS as XLIFF 1.1, I am  concerned as to when the specification might formally address the problem of  localization of non-linguistic data. Somehow we managed to overlook this  requirement in the original specification and this omission is also out of  line with our mission statement. I would very much like to include a new  method for handling meta-data in XLIFF 1.1 as I see it as providing for richer  support of the whole localization process than just 're-formatting'.  

John mentioned that the problem we are  trying to address has not been properly formally expressed. This is how I  would state it: "XLIFF does not currently provide a mechanism for the  localization of localizable data in the absence of text. It is also inelegant  and unintuitive in its approach to modifiable data associated with text and  lacks the ability to indicate the presence of modifiable or, more importantly,  non-modifiable data".

Extending  then from Matt's recent reformat summary I think we can use a slight variation  of option 4 as stated in his mail (i.e. 'Combined'). I would like to use more  intuitive naming though, for example, something along the lines of  <extended-source> and <extended-target> or <ex-source> and  <ex-target> etc instead of <source-info> and  <target-info>.
Matt had stated  that this option would require the most complex schema definition but I don't  think that there's any real obstacle here.
I have included a modified excerpt from the schema for the  <trans-unit> element to demonstrate that the changes are not  exorbitant.

         <xsd:complexType name="ElemType_trans-unit">
                                          <xsd:element name="source" type="xlf:ElemType_source"/>
                                          <xsd:element name="target" type="xlf:ElemType_target"  minOccurs="0"/>
                                          <xsd:element name="ex-source"  type="xlf:ElemType_ex_source"/>
                                          <xsd:element name="ex-target" type="xlf:ElemType_ex_target"  minOccurs="0"/>
                         ...rest of sequence removed for brevity
                 <xsd:attribute name="id"  type="xsd:NMTOKEN" use="required"/>
                ... removed  attributes for brevity ...
                 <xsd:anyAttribute  namespace="##other" processContents="lax"/>

Finally,  as I've just received Shigemichi's mail, I would like to second his thoughts  and change my previously stated preferred option from #2 to #4. I also think  Shigemichi summarizes the backward/forward compatibility issue very well and  the combined option fits here (IMHO).


Mark  Levins  
IBM Software Group,
Dublin  Software Laboratory,
Airways Industrial  Estate,
Dublin 17,
Phone: +353 1 704 6676
IBM  Tie Line 166676  

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC