Aaron,
> > Hi,
> >
> > I'm considering producing globalised versions of a product -
>German, French,
> > Spanish, Italian etc. However the application was not originally
>built with
> > this in mind, so it will involve extra work (on top of the translation
> > work).
> >
> > I'd like to know if this is considered worthwhile? Have products with
> > alternative languages received enough extra sales to make it worth the
> > effort?
>
> at PalmSource London, David Fedor discussed the use of overlays
> to implement localization of applications on the palm pilot. the
> idea itself is interesting, however there was one major drawback.
>
> from what i understood, you MUST be running the "language version"
> of the os in order to see the overlay in action. the selection of
> the overlay depends solely on the language being used by the os
> itself.
That is currently the case.
> this would mean that a french overlay would not be available when
> using an english rom. the idea of the overlay itself is a very
> impressive one if i must say myself.
>
> for a contract i am working on, i am going to develop a similar
> system that will work like the Internationalization of Java
> applications on the desktop.
>
> basically it will require writing an API similar to the overlay
> API but use it to access a .PDB file (containing language sensitive
> information) depending on the localizatoin the user has selected.
>
> 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.
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.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200 (direct) +1 408-261-7550 (main)
