[openbeos] Re: Coding Guidelines, translations

  • From: "Jean Schwerer" <j-schwerer@xxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sat, 10 Nov 2001 02:22:12 +0100

Hello,

[Helmar]
> It may be in the interest of OBOS and each
>app. developer that his/her app appears in as many languages
>as possible.

My useless 0.02 uros [you'll need to import a windows font to display that 
euro sign in BeOS 
:P] -> I share the same point of view.

One thing I'd like to add, though: it is very important to ensure a consistent 
user experience. If an 
application is only partly translated, then better display another language 
than mix two languages.
MacOS X has something approaching: if the application's in a given language, 
the finder menu will 
convert to that language.
I look for something a little more clever, and I strongly believe SpLocale is a 
very good exemple 
we should follow.

[DarkWyrm]
>Guys, we have such a beast already. SpLocale for BeOS has been abandoned; its 
>source has been released, and there shouldn't be any licensing issues (it's 
>free for free applications). I've used it and it would be easily incorporated 
>into an existing app.

For OBOS we need better than a "free for free applications" licence, but I 
think Bernard would 
probably not mind if we asked him to let us use and extend his SpLocale code 
under an MIT 
licence.
Bernard is now lurking towards AtheOS and QNX, trying to port SpLocale to 
AtheOS, and I don't 
think he feels strongly attached to the BeOS code anymore.

[DarkWyrm]
>For the uninitiated:
><shameless plug>
>It stores translations as attributes attached to a file and looks them up. 
>Locale files are stored in their own directory under home/config and are 
>internally located by use of queries.

Strings are stored as resources, not as attributes. It's easy to work with, if 
there's a problem or 
the user dislikes the translation it can always be edited with standard tools 
(in the worst case 
QuickRes :P), it can be moved to any file system and users have all languages 
within reach.
Additionally:
- it has a system-wide dictionary enabling developers to be lazy when it comes 
to common and 
usual entries ("file", "window", "folder", "about", "quit"...). In case of 
conflict, the application's 
dictionary gets precedence over the system dictionary.
- it automatically switches any newly installed application (provided it is 
SpLocale aware) to the 
user's favourite language.

[DarkWyrm]
>Incorporating it into an already 
>existing app involves three things: deriving the app's BApplication subclass 
>object from SpLocaleApp and not BApplication, calling SpTranslate() for any 
>strings needing translation and including the SpLocale.h header in any file 
>which makes that call.

This appears to me as the only drawback of SpLocale, but a major one: why on 
earth should we 
derive our app from SpLocaleApp? What if I have another functionality (say for 
example, 
SourisMaline's animated cursors) that also needs deriving from a non-standard 
Application class? 
I end up having an App I need to derive from SourisMalineApp, from SpLocaleApp, 
from 
WhateverOtherFunctionApp, etc. According to my individualistic egocentric self 
this is bad 
design. One shouldn't have to derive their application from anything else than 
BApplication.
Instead of forcing the developers to derive their applications from 
WhateverApp, we'd better tell 
the developer: you'll need to add a SpInit() call in your app's constructor.

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

Jean
 

Other related posts: