On Tue, 29 May 2001, Stephen Adkins wrote:
> Right. I have many more requirements I eventually want to support
> (such as internationalization). The trick is making the design such
> that it works in the simple case for simple things, while supporting
> advanced features for those who wish to use them. I think it is coming
> together pretty well.
I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right off the top. If
my widgets aren't multilingual then I'll have to go elsewhere. 75% of my apps are bi
and trilingual.
I think we should bite the bullet and start talkin Unicode and ISO-639 language codes
right at the beginning.
If a widget has a textual element to be used in rendering (ie/ label) it should have
as many language forms as the developer requires. If a language form is missing it
should kick down to a default language (EN-CA for example - otherwise words like
colour and flavour will be mispelled ;-) ).
Where is this language value coming from? The widget's container. You only care about
English? Then set it to "EN-US" and forget it.
$widget->container->language="EN-CA"
print $widget->label
"What is your favorite flavour of ice cream?"
$widget->container->language="EN-US"
print $widget->label
"What is your favorite flavor of ice cream?"
$widget->container->language="FR-CA"
print $widget->label
"...."
I'm sure you see the pattern.
Not every property should be considered polylingual but ones that contain textual or
language-specific visual elements should be.
Implementation strategies can be as simple as:
sub label {
my $self=shift;
my $lang=shift || $self->container->language;
if (exists $self->{'label'}{$lang}) {
return $self->{'label'}{$lang};
}
return $self->{'label'}{$self->container->language('default');
}
My personal strategy to date is to create meta data describing the class in general.
Accessor functions for properties are created dynamically via AUTOLOAD mechanism.
Based on metadata for class in question the AUTOLOADer will setup the accessor using
one of a few different behaviors.
In closing - although it seems like a drag in the beginning - it really makes sense to
develop applications and components to support multiple languages. It is a zillion
times more difficult to cobble in the fucntionality after the fact.
Jay
