At 10:04 AM 5/29/01 -0700, [EMAIL PROTECTED] wrote:
>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.
Sounds kinky.
Anyway, I think there are two things that have to be gotten straight.
1) I18L support should exist immediately such as being able to render a
Chinese label.
2) Multilingual support is VERY different from I18L and is MUCH more
complex. I vote no on supporting this.
I think it can be supported through a custom subclass of what you have been
describing as a container/controller for the widgets. I think if it is done
at the widget level it is bloating the widget set and I honestly don't see
why a widget should know about languages.
I should rather configure my widgets in French and other widgets in English
etc... And then I tell a multilingual container subclass about all my sets
of widgets and then using a setLocale(), then the getWidget() method will
return the appropriate configured language widget.
You also would need a Widget Config that is multilingual and can configure
the multi languages very easily.
But please do not touch the core widget api itself. Please please keep it
lightweight.
>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.
Just don't make the core library have to support multilingual. This is just
another bloated thing I don't want. It's fine for the hooks to exist, but
not the logic.
I don't mind if you make a subclass to support multiple sets of widgets as
described above, but please do not add so much that this becomes a huge
project.
