How to do multiple language support in Dolphin?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How to do multiple language support in Dolphin?

Christopher J. Demers
I did not anticipate this, but I may be having to support multiple languages
in my Dolphin application.  I have a vague memory of discussion about this
some time ago, but I can't seem to find any hits on the Google archive of
the group.  I would really appreciate it if anyone can help me find the
previous discussions (if there actually were any), or share some of their
own current experiences with supporting multiple languages in Dolphin.

Here are some things I am thinking about (off the top of my head):

1. I could use string resources and load them from language specific DLL's.
I feel like this might be the "official" way to do this, but I need to learn
more about how this strategy would mesh with Dolphin.  If I have to use
numeric IDs it would seem to impede readability on some level.

2. I could subclass controls likely to display text (primarily StaticText),
hook into a setter and predisplay initialization in order to do a kind of
dictionary look up.  The English phrase would be the key, and what ever
there translation was would be the value.  I could them mutate all my
StaticText's to my new class.  I would also have to do something about list
view columns I imagine.  So long as I don't have to add any instance
variables to my subclasses I don't think I would get into any trouble with
STB versions if OA changes class shapes.

Has anyone done anything like this?  Any regrets or success?

Thanks,
Chris


Reply | Threaded
Open this post in threaded view
|

Re: How to do multiple language support in Dolphin?

Chris Uppal-3
Christopher J. Demers wrote:

> I did not anticipate this, but I may be having to support multiple
> languages in my Dolphin application.  I have a vague memory of discussion
> about this some time ago, but I can't seem to find any hits on the Google
> archive of the group.  I would really appreciate it if anyone can help me
> find the previous discussions (if there actually were any), or share some
> of their own current experiences with supporting multiple languages in
> Dolphin.

Three threads that talk about this issue (they don't say much, but may give you
ideas):

    22 May 1997(!): "Localization Approach?"
    4 January 2001 "Building a string from incompatible objects."
    5 January 2001: "windows resources (dialogs)"

They are all in Ian's archive.

One idea that occurs to me is have a new object LocalizedString that:

    Contains a String and a Guid
    Forwards almost all messages to the String (DNU handling ?)
    STB's itself as the Guid and the String
    DeSTB's itself by finding the string by looking up the Guid in some
        registry, falling back to the STB-ed String if it can't find it.

The registry is (somehow) initialised to hold the localised versions of the
string.

You create the default registry by inserting Strings into it by converting your
existing code into expressions like:

=== OLD ==========
    myMethod
        "blah blah"
        aStream nextPutAll: 'Example'
        "blah blah"
=== NEW ==========
    myMethod
        "blah blah"
        aStream nextPutAll: ##('Example' localised)
        "blah blah"
================

The idea of String>>localized is that it looks up the String in a dictionary of
already LocalisedStrings, and returns the existing one if there is one,
otherwise it creates a new one with a new unique GUID.  By the time you had
recoded all your literal Strings, the compilation would have built up the
registry to contain localisable versions of them all.

You'd also have to convert the Strings in your existing View Resources into
LocalisedStrings.  Tedious.

Once you have converted all your code and resources to use LocalisedStrings,
you can then create new registries that map the GUIDs to translated Strings --
naturally your own English text is contained in the registered
LocalisedStrings, so translation shouldn't be harder than necessary.

Oh, yes, you'd also have to do a:
    LocalisedString allIstances do: [:each | each beLocalised]
at image startup in your deployed app, to translate the instances that were not
saved in STBed Resources.

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: How to do multiple language support in Dolphin?

Christopher J. Demers
"Chris Uppal" <[hidden email]> wrote in message
news:3f701751$0$33808$[hidden email]...
> Three threads that talk about this issue (they don't say much, but may
give you
> ideas):
>
>     22 May 1997(!): "Localization Approach?"
>     4 January 2001 "Building a string from incompatible objects."
>     5 January 2001: "windows resources (dialogs)"

Thanks, I will take a look.

> They are all in Ian's archive.
>
> One idea that occurs to me is have a new object LocalizedString that:
>
>     Contains a String and a Guid
>     Forwards almost all messages to the String (DNU handling ?)
>     STB's itself as the Guid and the String
>     DeSTB's itself by finding the string by looking up the Guid in some
>         registry, falling back to the STB-ed String if it can't find it.

This sounds like it is worth some expirimentation.
....
>
> You'd also have to convert the Strings in your existing View Resources
into
> LocalisedStrings.  Tedious.

I think I can probably automate this pretty well.

> Once you have converted all your code and resources to use
LocalisedStrings,
> you can then create new registries that map the GUIDs to translated
Strings --
> naturally your own English text is contained in the registered
> LocalisedStrings, so translation shouldn't be harder than necessary.
>
> Oh, yes, you'd also have to do a:
>     LocalisedString allIstances do: [:each | each beLocalised]
> at image startup in your deployed app, to translate the instances that
were not
> saved in STBed Resources.
>
>     -- chris

It seems that Smalltalk puts us in a nice position to add support for
multiple languages.  I don't think I would want to imagine what I would have
to do in VB or C. ;)

Chris


Reply | Threaded
Open this post in threaded view
|

Re: How to do multiple language support in Dolphin?

Chris Uppal-3
Christopher J. Demers wrote:

> > One idea that occurs to me is have a new object LocalizedString that:
> >
> >     Contains a String and a Guid
> >     Forwards almost all messages to the String (DNU handling ?)
> >     STB's itself as the Guid and the String
> >     DeSTB's itself by finding the string by looking up the Guid in some
> >         registry, falling back to the STB-ed String if it can't find it.
>
> This sounds like it is worth some expirimentation.

I got interested in this myself and put together a localisation package
following roughly the above lines.  I had to make complicate it a bit to allow
for testing in the image without prematurely "fixing" the localized Stings.  It
seems to work quite well as far as it goes, the DNU-based proxies do their job,
and the STBing seems to works fine.

However...

> ....
> >
> > You'd also have to convert the Strings in your existing View Resources
> > into LocalisedStrings.  Tedious.
>
> I think I can probably automate this pretty well.

Unfortunately, it seems that it is impossible to use a proxy based approach to
setting aspects of View Resouces -- there is so much double-dispatching going
on when setting View>>text:, for example, that the proxy gets lost and the
supposedly variable "string" gets "fixed" into the Resouces.  The problem is
worse when using the VC, but even modifying the Resource from code suffers from
the same problem.  I think that, even if we could find a way around specific
problems, the approach is too fragile to use with stored View Resouces in the
current MVP implementation.

Which is sad...

You can still set the View>>text (etc) from localized strings in #onViewOpened
(or wherever's convenient at runtime), so the approach isn't entirely a
failure.  But, if we're not saving these things into resources, then it's not
clear that there's a real need for the DNU-based stuff.  Easier to have code
looking like:

    self view title: ('My Application' localized).

and so on, where #localized just answers the translated Sting rather than one
of the, more complicated, proxies that I was playing with.

Ah, well.

    -- chris