RE: [xliff] reformat discussion

Hi 
all,

 

I like 
Doug's last proposal too. If it answers Mat's requirements it would allow us to 
move forward and have a 1.1 where the reformat problem would be addressed 
without a major re-hauling of the structure.

 

For 
localizable data without text, I think I would concur with Tony. RC files 
are good examples of documents with such data and so far I haven't seen any 
problem that would require a major structural change. It's sure not very 
elegant, but I'm afraid we have given up on XLIFF grace some time 
ago.

 

The 
only thing I can think of for complex data is that I'm not sure we do have all 
the attributes we would need to represent all the different properties of a 
given resource, especially beyond RC files (color was mentionned, and I think I 
recall some options in RC's menuex that might be also somehow problematic, 
anybody looked at representing Mac or Motif resources in XLIFF?). This is why 
maybe having more work done on those profiles (how various formats are 
represented in XLIFF) before closing a revision heading for being formalized as 
an OASIS standard would [have] be[en] nice.

 

kenavo,

-yves

 

 

 

  
-----Original Message-----
From: Tony Jewtushenko 
  [mailto:]
Sent: Fri, January 24, 2003 
  8:45 AM
To: Mark Levins; 
  
Subject: 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?

  
 

  
Regards,

  
Tony

  
 

  
    
----- Original Message ----- 

    
From: 
    Mark 
    Levins 

    
To:  
    

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

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). 
    

Regards,

Mark Levins 
    
      
      

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