FW: [xliff-comment] XLIFF and resizing information

Hi 
all,

 

Here 
are a few more comments from Nikolai that may be useful for the discussion on 
font, coord, etc.

 

cheers,

-yves

 

 

-----Original Message-----
From: Yves Savourel 
[mailto:]
Sent: Thu, January 09, 2003 3:34 
PM
To: Nikolai Tsepalov
Subject: RE: [xliff-comment] XLIFF 
and resizing information

Hi 
Nikolai,

 

Thanks 
for your comments. They will be useful for the discussion the group is currently 
having. Is it Ok if I post them on the XLIFF list so other can see them as 
well?

 

I've 
tried to answer some questions. Please, see below:

 

Cheers,

-yves

  
-----Original Message-----
From: Nikolai Tsepalov 
  [mailto:]
Sent: Tue, January 07, 2003 3:11 
  PM
To: 
Subject: RE: 
  [xliff-comment] XLIFF and resizing information

  

  
Hi Yves,

  
My phone line was broken for a few days so I could not 
  answer.

  
Thank you for respond. It answers my main question 
  about group coordinates localization.

  
As I understood, if any changes need to be made to a 
  locale version, they should go in to <translation unit> and then 
  <source> of this group.  I 
  believe this is rule not only for Windows resources but it is 
  general.

  
 

  
Here some questions and thought I have after reading 
  attached document. I don‘t need answers to them to continue my work, therefore 
  if you are busy skip them.

  
 

  
Take care,

  
Nikolai

  
 

  
 

  
2.2.2. Non-Unique 
  Identifiers

  
 

  
In my opinion converter definitely should warn user 
  and recommend making these IDs unique.

  
If user insists to use file with non-unique ID, the 
  best way is to generate pseudo IDs based on controls original text if control 
  has is. For instance take first ten chars of the text, capitalize them and 
  remove ampersands and other symbols.  
  

  
This way better than order or type based approach, 
  because text is that we care about the most, secondary, restype is not 
  reliable information (usually dialogs with large amount of text have a lot of 
  labels with exactly the same restype). Controls order in dialog also very 
  unreliable; it can be changed not only by controls deletion-addition but by 
  changing a tab order as well. 

  
Same approach works for menu’s POPUPs as well. It should not be based only on POPUP 
  order; if new POPUP was inserted in main menu all XLIFF IDs will be 
  broken.

  
 

  
Numeric XLIFF IDs.

  
 

  
As I see in document XLIFF’s 
  IDs are just a numbers. If leveraging algorithm should use only IDs and this 
  is the only they to go, because algorithm should not be particular format 
  aware, IDs should be much more informative.

  
 

  
How you can leverage 

  
 

  
<trans-unit id='2' resname='ID_FILE_NEW' restype='menuitem'>

  
<trans-unit id='3' resname='ID_SOME_NEW_ITEM' restype='menuitem'>

  
<trans-unit id='4' resname='ID_FILE_OPEN' restype='menuitem'>

  
<trans-unit id='5' resname='ID_FILE_SAVE' restype='menuitem'>

  
<trans-unit id='6' restype='separator' 
  translate='no'>

  
<trans-unit id='7' resname='ID_APP_EXIT'>

  
 

  
from 

  
 

  
<trans-unit id='2' resname='ID_FILE_NEW' restype='menuitem'>

  
<trans-unit id='3' resname='ID_FILE_OPEN' restype='menuitem'>

  
<trans-unit id='4' resname='ID_FILE_SAVE' restype='menuitem'>

  
<trans-unit id='5' restype='separator' 
  translate='no'>

  
<trans-unit id='6' resname='ID_APP_EXIT'>

  
 

  
without digging to resname level?
[YS] resname is the resource-ID of the 
  item. the 'id' attribute has a meaning only within the XLIFF file for the tool 
  that does the extraction or transformation. The names are not very clear I 
  agree... it's a long story of different opinions and 
  compromises.

  
 

  
RC resource file itself, with exception of not unique 
  dialog IDs and Popups, allows generating a file 
  scope unique IDs based on simple schema:

  
 

  
String table IDs are unique 
  by themselves.

  
Menu ID plus menu Item ID is 
  unique.

  
Dialog ID plus control ID is 
  unique.

  
 

  
So it will be something like <trans-unit id=' 
  'IDR_MAINFRAME__ID_FILE_NEW ' resname='ID_FILE_NEW' 
  restype='menuitem'>

  
This approach I’ve used for my leveraging programs at 
  Siebel Systems.  

  
 

  
 

  
Basic UI layout 
  specification.

  
 

  
As I understand with Windows resource (winres) 
  representation in XLIFF format you are trying to make XLIFF document 
  sufficient to regenerate locale version of resources without original ENU 
  source. This is not only difficult tack, but it also makes XLIFF editor tool 
  100% winres aware tool. This is fine with winres, as well as with any other 
  current and incoming Microsoft standards. Almost every single company will use 
  it. 

  
My question is: How do you plan to handle zillions of 
  single company specific formats?
[YS] Good question. the answer 
  is two fold: First we have looked at RC file more closely because the 
  overwhelming majority of the XLIFF users we know of are Windows users. Second, 
  Most of the non-Windows users are Java users (Sun is an XLIFF founder and 
  contributor for example) and they work with properties files that can be 
  mapped easily to XLIFF. However, in my opinion, we need "profiles" similar to 
  the document I sent you for many formats. My hope is that we can arrive at a 
  set of properties that can be use across formats. XLIFF 1.1 also allow the use 
  of different namespaces and there is a possibility to develop format-specific 
  sub set of information for whatever is not covered by the default 
  attributes.

  
This is definitely not easy, and a 
  working solution will have to go through a lot of 
  tries.

  
 

  
Let’s say some Software Development Company (SDC) has 
  application with localizable information in standard winres and in some 
  special repository. SDC needs to send localization kit to Software 
  Localization Company (SLC). With winres it’s fine. Both companies have some 
  commercial XLIFF editor (CATALYST 6.6J 
  for instance), so SDC convert RC in to XLIFF send it to SLC, done. 
But, what to do with unique SDC repository format? 
  Obviously only SDC can quickly and with good quality make converter from 
  repository to XLIFF. How currently SDC can make it?

  
Obviously coordinates and sizes are not enough for UI 
  representation, label control can hold much longer text than equal size check 
  box, and therefore we need styles.

  
For first look current XLIFF has everything  (coord, 
  font, 
  css-style, 
  style, 
  exstyle, 
  extype, 
  maxbytes, 
  minbytes, 
  size-unit, 
  maxheight, 
  minheight, 
  maxwidth, 
  minwidth, 
  charclass), 
  but if every SDC going to use its own styles names, nobody will understand 
  them. SDC_ComboBox will be unknown for 
  CATALYST.

  
 

  
I can see two ways to solve this problem. 
  

  
1. XLIFF may have some set of basic UI components 
  XLIFF_COMBOBOX, XLIFF_LABEL or something like it; let's call it Basic UI 
  (BUI). Each of these BUI elements should have set of attributes which allows 
  developer to describe company specific UI element as much as possible closer 
  to reality. For instance, for check box it should be not only size of check 
  box itself but also size and position of internal frame where text actually 
  locales.

  
So SDC can represent its repository as BUI and 
  CATALYST will understand it.
[YS] That is the idea the group is 
  trying to follow. See for example the work on defining attribute values for 
  datatype and restype.

  
 

  
2. Apparently SDC can try to represent repository 
  layout in Windows Resource format, but usually this is very difficult, for 
  instance Siebel Applets components looks way far from Windows 
  resource.