in reply to Re: Translation modules and the importation of global language variables
in thread Translation modules and the importation of global language variables

Thanks for your reply hardburn.
Could you be more specific? What do mean by "proper module", a package?
I did forget to mention it was included in @INC, but how do you then routinely load the variables?
I would also like to use the same method for config files.
Some simple code extract would get me on track!
thanks again
  • Comment on Re: Re: Translation modules and the importation of global language variables

Replies are listed 'Best First'.
Re: Re: Re: Translation modules and the importation of global language variables
by hardburn (Abbot) on Oct 08, 2003 at 21:02 UTC

    Modules usually have a '.pm' extention, although there is this whole debate about identifying files by their extention being a bad thing. Modules and packages look the same if you squint enough, so there are probably no practical differences between your code and a 'proper module' as it is.

    Something like this is what I'm talking about:

    package My::Language::Dutch; use strict; my %language = ( blue => 'blauw', red => 'rood', ); sub get_word { my $class = shift; my $word = shift || return; return $language{$word}; } 1; # IMPORTANT -- modules have to return a true value at the end

    You put that somewhere in your @INC under a My/Languages directory, so that perl knows where to find it, and then use it like this:

    use My::Language::Dutch; my $blue_dutch = My::Language::Dutch->get_word( 'blue' );

    If you need to dynamically use a language at runtime, you'll have to fall back to require and some class name tricks:

    my $language = 'Dutch'; require "My/Language/$language.pm"; my $class = "My::Language::$language"; my $blue = $class->get_word( 'blue' );

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated