On 29 May 2001 [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.
I agree. I18L and L10N are very important these days.
> 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 ;-) ).
But it's not just textual elements that need to be multilingual. Where is
really gets hairy is with something like a price widget (what monetary
symbol is used, what decimal point, etc...). This isn't usually that hard
to do on one system (if it has good Locale support), but making it cross
platform and dependable will be more difficult. I have used the
Locale::Maketext module with some success in the past. It doesn't depend
on any system Locality libraries, you are required to build them yourself
for your specific needs.
Another thing to consider is how to handle language issues with
dynamically changing widgets. For example if a widget uses a select box
it could be filled in by one of three ways: hard-coded, config, or at run
time (through DB calls or something). If your application is
multi-language, then you need to provide multiple datasets to the widget
if it is a dynamically changing widget. This would probably be most
convenient by using closures:
my $dbh = <<database handle>>
$wc = Widget->controller();
$wc->language('fr_CA','fr','en'); # Tell the controller what language(s)
# you would like in order of precidence
my $get_categories = {
my $lang = shift; # will be one of (en, fr, fr_CA)
return $dbh->selectrow_array(q{
SELECT category
FROM categories
WHERE language = ?
ORDER BY category
}, $lang);
}
my $categories = $wc->widget("dynamic_select",
{ label => 'Category', dataset => $get_categories });
I don't think the widget should automatically check the users environment
(Language headers in the case of http), to decide what language to display
itself in. The reason for this is that I might only translate my website
into english and french, but the user has dutch as their preferred
language. The site should not display some parts in english/french and
it's widgets in dutch...
So by telling the controller what languages are acceptable, you can
restrict what it can do. Or perhaps the language should be decided by the
programmer at display time??
ie print $categories->display({language => 'fr_CA'});
That would get awful repetative if your displaying 20 widgets. But it
might be nice if you want to override a widget to display it in a
different language. Who knows what people might want :)
Handling the different language tags should probably be handled by
I18N::LangTags. You can pass it a string ($r->header_in('Language'), and
it will return an array of valid RFC1766-style language tags.
Sorry if it sound like I'm rambling, but I'm just throwing down thoughts
as they pop into my head :)
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
