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: [xliff] <bin-unit> problem


Hi John & all,

The way I've been handling data for icon, bitmaps, etc. is by using a
corresponding <trans-unit>. For example, in your case I would do something
like this:

<bin-unit id='1' translate='yes' reformat='yes'
 mime-type='image/icon'>
 <bin-source>
  <external-file href="btnadvanced.gif"/>
 </bin-unit>
 <trans-unit id='0' coord='0;0;86;16'>
  <source/>
 </trans-unit>
</bin-unit>

If the icon size changes I would expect the localized document to be:

<bin-unit id='1' translate='yes' reformat='yes'
 mime-type='image/icon'>
 <bin-source>
  <external-file href="btnadvanced.gif"/>
 </bin-unit>
 <trans-unit id='0' coord='0;0;86;16'>
  <source/>
  <target coord='0;0;94;24'/>
 </trans-unit>
</bin-unit>

I guess you can generalize this as using the first <trans-unit> of a
'container' as the place to put data that go with the container. Here the
'container' would be the icon (with possible text in it).

Wouldn't that work for you John?

On a side note I'd like to remind everyone that this is a good example why
going through profiles of different formats would 'have been'/'be(?) better
before we close the next major version of XLIFF. I'm pretty sure we'll have
some surprises when trying to work with Windows resources such as
MESSAGETABLE, FONT, FONTDIR, GROUP_ICON, GROUP_CURSOR, MENUEX, etc. And that
is for Win32 resources only.

kenavo and have a great week-end,
-yves


-----Original Message-----
From: John Reid [mailto:JREID@novell.com]
Sent: Fri, February 07, 2003 2:07 PM
To: >
Subject: [xliff] <bin-unit> problem


Hi All,
I have just now come across a situation where we have icons that are being
localized. In doing this we need to keep track of the change in size of the
icon. However, the current definition of <bin-unit> does not have that
information. In the <trans-unit> we have the coord attribute to store that
info. Since we are at a 1.0 implementation, we could use a <prop> to give us
that info but I prefer the <context> since we can codify it and make it
understandable to translators, provided that the tools understand it.

   <bin-unit id="1" mime-type="image/gif" translate="yes" reformat="yes">
      <bin-source><external-file href="btnadvanced.gif"/></bin-source>
      <context-group name="translation">
        <context context-type="bin-coord">0;0;86;16</context>
      </context-group>
   </bin-unit>


The better solution would be to add coord as an attribute of <bin-unit> and
<bin-target>. After all, what  does reformat control for <bin-unit>? The
only attributes that could be reformatted are mime-type, restype, and
resname. We may need the other following attributes:

coord            <bin-unit> and <bin-target>
size-unit        <bin-unit> only
maxheight      <bin-unit> only
minheight       <bin-unit> only
maxwidth       <bin-unit> only
minwidth        <bin-unit> only

The above could then be expressed as follows.

   <bin-unit id="1" mime-type="image/gif" translate="yes" reformat="yes"
coord="0;0;86;16">
      <bin-source><external-file href="btnadvanced.gif"/></bin-source>
   </bin-unit>

If someone has come across this same problem and found a different solution,
I would appreciate the help. Otherwise, as much as I don't want to delay the
process, we may want to consider taking care of this now. What do you think?

thanks,
john



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


Powered by eList eXpress LLC