[openbeos] Re: Coding Guidelines, translations

  • From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sat, 10 Nov 2001 01:32:48 -0500

[snip]

>[Ithamar]
>>However, by keeping one copy of (preferrably US- 
>>English) strings in the executable, the program can even function
>>without any of the translated files available
>
>Thanks for the other languages ;o)
>The usual problem with that kind of design is the same that affects BeOS's 
>GUIs: they're not 
>resizable. Draw the parallel to the memory space: when developers tend to give 
>one language 
>the precedence over other languages, they will be tempted to allocate in 
>memory the size of the 
>string in their language of choice, thus turning out to be a nightmare when 
>they want to add 
>localization, because all allocations have to be reviewed. Their memory 
>allocations are not 
>"resizable".
>As far as I'm concerned, I would have loved to see localization the way 
>SpLocale does it added 
>within the API as an extension of existing classes. e.g. [assuming myString is 
>a BString object] 
>instead of calling myString.String() one would call 
>BString::SetDictionary(&userWish) at the 
>beginning of the program and then myString.TranslatedString() when needed (the 
>nice thing being 
>that BString already takes care of malloc for you).

Everyone needs to remember, though, that localization is more than text.
Money, dates, numbers and more need to be localized. Plus the whole up and down 
and right to left text.
As well as resizing (as Jean alluded to above) and more.

As a person working on a BeOS GUI app, I far more succinctly appreciate the 
need for better GUI
placement tools. I think that this has to be WAY up on our plate for R2.


>Jean
> 
>
>

Other related posts:

  1. Home
  2. haiku
  3. Archive
  4. 11-2001