> > the idea presented in Java would be really great to port over to
> > the Palm Pilot. i thought the concept was done with overlays,
> > however it does not support locals fully.. there should be a
> > difference between english if you are in the US or if you are
> > in UK or even AU :P
>
> Overlays depend on the current locale, which is specified by both the
> language _and_ the country. Thus English in the US is the enUS
> locale, while English in Australia is the enAU locale.
hmm.. i believe the demonstration was just for french (by david)
i should have asked this when i was there :)) hehe. i have not
yet played with overlays (as gcc is not ready for 3.5 yet) :P
> If you were really interested in allowing users to select a UI locale
> which isn't the same as the device's system locale, then you could do
> the following:
>
> 1. Add an xprf=0 resource to your app, with the 'disable overlays'
> bit set. This means that when your application is launched, no
> overlay will be opened, even if one exists that matches the system
> locale.
>
> 2. Provide your own UI in the app for selecting from available
> overlays. You can get the list of potential overlays by calling
> DmGetNextDatabaseByTypeCreator, where the type = 'ovly', and the
> creator is the same as your application.
>
> 3. Call OmOverlayDBNameToLocale() to map from the returned DB name to
> the locale, if you want to display the locale in a user-friendly
> manner.
>
> 4. When the user picks a locale, open that overlay DB with read-only access.
>
> A few caveats...
>
> A. You won't be able to use DmGet1Resource to load resources that
> might be in the base application. When an overlay is opened by the
> system, DmGet1Resource is smart enough to look in both the overlay
> and the base DB. Generally this isn't much of a problem, since
> one-deep calls are very rarely required.
>
> B. You'd need to verify that the overlay selected is appropriate for
> the current version of your base application. When the system opens
> an overlay, it uses checksums to verify that the overlay is
> appropriate for the base, as otherwise an overlay/base mismatch could
> result in invalid resource data being loaded from the overlay. For
> example, you update the base application, and the updated version has
> a modified form with extra buttons, but the overlay still contains a
> localized version of the older form with fewer buttons.
>
> The easiest way to do this verification yourself would to be make
> sure you always bump the version number field in the app (base) DB
> header with each new release, and keep the overlay DB header's
> version number in sync.
>
> C. An odd-ball case is making sure that the overlay's locale uses a
> character encoding that matches the device's character encoding. You
> wouldn't want to let the user pick the Japanese overlay when running
> on a Latin-based device, for example.
maybe someone could put this in the knowledge base? my main interests
for "internationalization" is to be able to run my program in different
languages on an english device.
for example, there are no "swedish", "finish" os's available. however
the users may prefer the program to be in that language. :)
cheers.
az
--
Aaron Ardiri
Java Certified Programmer http://www.hig.se/~ardiri/
University-College i G�vle mailto:[EMAIL PROTECTED]
SE 801 76 G�vle SWEDEN
Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
Mob: +46 70 656 1143 A/H: +46 26 10 16 11
