[openbeos] Re: Coding Guidelines, translations

  • From: "Marcus Overhagen" <dos4gw@xxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sat, 10 Nov 2001 02:55:52 +0000

"Jean Schwerer" <j-schwerer@xxxxxxx> wrote:


>[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 was the main reason why I never used SpLocale. I didn't like to do all 
this :)

>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, 
No, this is stupid. We should not need to do it. If I have, for example, a 
media add-on,
that want's to display some text, for example in the Media Preferences panel,
you can't use this approach!

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

Yes, It would be better to have something like BMediaRoster:

class BTranslationRoster
{
        public:
                static BTranslationRoster *GetRoster();

                void Translate(BString *buffer, const char* original);

                BString Translate(const char* original);

                //please NEVER RETURN ANY STATIC BUFFER, this is not thread 
save!
                // NO const char *Translate(const char *)

        private:
                BTranslationRoster();
                ~BTranslationRoster();
};

        GetRoster() could than do the initialization, and connect to the 
translation server.

In the App, you would do this:

#include <TranslationRoster.h>

//global
BTranslationRoster*translation = BTranslationRoster::GetRoster();
#define XLT(a) (translation->Translate(a)).String()


void Somefunc()
{
        BString s;
        translation->Translate(&s,"Do as you please");
        fSomeControl->SetText(s.String());

        //or:

        //using the #define XLT(a) (translation->Translate(a)).String()

        fSomeControl->SetText(XLT("Do as you please"));
        fSomeOtherControl->SetText(XLT("This looks nice"));
}

>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).
No more static buffers!

regards
Marcus

Other related posts:

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