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 |
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 |
"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 |
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 |
Free forum by Nabble | Edit this page |