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