openinteract-help

[Openinteract-help] multiple languages in OI

[Chris M. <Chr...@te...>]

Hello,

I'm trying to think of a way to allow for a language selection in OI.  I've
had an idea or two, but I thought it might be best to 'consult the
oracle'...  Maybe there is a better way?  Maybe my idea is unworkable?  Note
that I have finally upgraded to 1.54...

So to provide to multiple languages for both logged in and not logged in
users, I need to have a persistent reference to a users language selection
throughout all requests.  This language selection needs to be accessible to
both handlers and templates/pages.  

Create a new directive in server.ini like 'fr' for French, and point it to
the main template.  My understanding is that this would have no other effect
than shoving this directive into $R->{ui}{directive} and I'm thinking I
should be able to get at that in my handlers and pass it into my templates
(and hack it into base_page).  I could then have all my templates branch on
this and have multiple language versions in each template.  If I wanted to
be really crafty I would use widgets heavily to avoid either duplicating
HTML code or having some really untidy branching.  The good bit is that this
is only needing to be done pages that non-admin types would see.  One
possible issue I see immediately is that I would not be able to use popup or
notmpl directives as well as the fr directive, which might prove to be a bit
annoying...

I also wondered about putting a ?lang=fr at the end of all my URLs and
parsing off that instead.... Would that amount to the same thing?

Is there a better way?

Chris McDaniel
Service Development Architect
TELUS Business Solutions
Voice.416.883.4610  Cell.416.676.4654           

Re: [Openinteract-help] multiple languages in OI

[Chris W. <ch...@cw...>]

On Wed, 2002-11-20 at 02:49, Chris McDaniel wrote:
> So to provide to multiple languages for both logged in and not logged in
> users, I need to have a persistent reference to a users language selection
> throughout all requests.  This language selection needs to be accessible to
> both handlers and templates/pages.  

The session should work -- even if a user isn't logged in they still get
a session. You could also just use a cookie if you like. And the session
data is accessible from the template:

 [% lang = OI.session.lang %]
 [% IF lang == 'fr' %] ...
 
> Create a new directive in server.ini like 'fr' for French, and point it to
> the main template.  My understanding is that this would have no other effect
> than shoving this directive into $R->{ui}{directive} and I'm thinking I
> should be able to get at that in my handlers and pass it into my templates
> (and hack it into base_page).

For the main template, it would probably be useful to define the
template name in the theme and then have the template selection routine
available for subclassing. So you could define something like:

package OpenInteract::UI::LanguageChoice;

use base qw( OpenInteract::UI::Main );

my $DEFAULT_LANGUAGE = 'en';

sub choose_template {
    my ( $class ) = @_;
    my ( $language );
    if ( $R->{auth}{is_logged_in} ) {
        $language = $R->{auth}{user}->language;
    }
    $language ||= $R->apache->param( 'lang' )
                  || $R->{session}{lang}
                  || $DEFAULT_LANGUAGE;
    my $R = OpenInteract::Request->instance;
    my $template = $R->{theme}->property_value( "template_$language" )
                   || $R->{theme}->property_value( 'main_template' );
    return $template;
}

I think I'll add that even if you don't find it useful :-)

> I could then have all my templates branch on
> this and have multiple language versions in each template.  If I wanted to
> be really crafty I would use widgets heavily to avoid either duplicating
> HTML code or having some really untidy branching.  The good bit is that this
> is only needing to be done pages that non-admin types would see.  One
> possible issue I see immediately is that I would not be able to use popup or
> notmpl directives as well as the fr directive, which might prove to be a bit
> annoying...

(The 'popup' and 'notmpl' directive stuff is an ugly hack. I hate even
thinking about them :-)

Using widgets is helpful but it doesn't really help with the labelling
issue. What we really need is a plugin for TT to be able to use one of
the gettext-like Perl implementations. This way you'd be able to do
something like:

 <tr>
   <td>[% Gettext.lookup( 'searchform.label.firstname' ) %]</td>
   <td>[% PROCESS form_text( name = 'firstname', size = 15 ) %]</td>  
  </tr>

And the right label gets looked up. We can do better integration but
this first step would be nice.

> I also wondered about putting a ?lang=fr at the end of all my URLs and
> parsing off that instead.... Would that amount to the same thing?

I think so. It would make it a pain to track your URLs though --
sessions (or cookies) are great for this kind of thing. 
 
Later,

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-help] multiple languages in OI

[Jochen L. <jl...@te...>]

Hi Chris,

it's been over a year ago when I first brought on the problem of
localization in OI. Now I can present a useable solution. :-)

You wrote:

> What we really need is a plugin for TT to be able to use one of the
> gettext-like Perl implementations.

In another non-OI project, I achieved this via a TT filter subroutine
that uses Locale::Maketext classes. This filter is used with text in a
default language:

  [% |loc %]Hello World![% END %]

Inserting values:

  [% |loc( name.last, name.first ) %]Greetings, [_2] [_1].[% END %]

Using a localization function:

  [% |loc ( article.date ) %]Written on [dateformat,_1][% END %]

The "loc" filter is implemented via a dynamic filter subroutine. This so
called "filter factory" is then connected to the TT object configuration:

sub maketemplate()
{
       my $locFilterFactory = sub {
                my ( $context, @args ) = @_;

                return sub {
                                my $text = shift;

                                # translate text
                                my $xltext = $self->loc( $text, @args );
                                ...
                                return $xltext;
                                };
        };

       my $config = {
                ...
                FILTERS => {
                        loc => [ $locFilterFactory, 1 ],
                        },
                    }
       my $template = Template->new( $config );
       ...
       return $template;
}

The $self->loc() method used in the anonymous sub above has to instantiate
a Locale::Maketext child class (eg. "MyL10N") that has itself a child class
for every language supported (eg. "MyL10N::de", "MyL10N::fr", etc.). These
language classes then contain a simple lexicon

  our %Lexicon = {
        'Hello World!' => 'Hallo Welt!',
        'Greetings, [_2] [_1].' => '[_2] [_1], sei gegruesst.'
        }

as well as localization methods (like the dateformat() method in the
example above that converts the ISO date format to a local one).

$self->loc() then finally calls MyL10N::gettext() -- which
automagically dispatches to its correct language child class (see
Locale::Maketext docs) -- and returns the translated text to the
filter. This text then replaces the default text used in the
template.

I think that this concept is very practical and could be integrated
into OpenInteract quite easily.

Best regards,

	Jochen

-- 
----------------------------------------------------------------
 *Jochen Lillich*, Dipl.-Inform. (FH) 
 Consultant/Trainer @ /TeamLinux GbR/
 Tel. +49 7254 985187-0                 http://www.teamlinux.de
----------------------------------------------------------------

Re: [Openinteract-help] multiple languages in OI

[Chris W. <ch...@cw...>]

On Thu, 2002-11-28 at 11:03, Jochen Lillich wrote:
> Hi Chris,
> 
> it's been over a year ago when I first brought on the problem of
> localization in OI. Now I can present a useable solution. :-)
> ...

Just a short note here (Thursday/Friday is a holiday in the US, and I'm
out the door on a short trip).

This is *exactly* the sort of thing I was hoping for. I don't think OI
should have any low-level functionality for this, but we can create some
bridges so that creating the lexicon can be automated -- read from
config/properties files, etc.

You should bundle this up and send it to CPAN. Do you have any plans to
do so?

More later...

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.