Story
The idea is that: I finally realized that, no matter how hard I try, I can never get a never-failure "maketext". A common wrapper like:
sub __ { return $LH->maketext(@_) };
always fails if $LH is not initialized yet. For this reason, "maketext" can hardly be employed in error handlers to output graceful error messages in the natural language of the user. So, I have to write something like this:
sub __ {$LH = MyPkg::L10N->get_handle if !defined $LH;return $LH->maketext(@_);}
But what if "get_handle" itself fails? So, this becomes:
sub __ {$LH = MyPkg::L10N->get_handle if !defined $LH;$LH = _AUTO->get_handle if !defined $LH;return $LH->maketext(@_);}package _AUTO;use base qw(Locale::Maketext);package _AUTO::i_default;use base qw(Locale::Maketext);%Lexicon = ( "_AUTO" => 1 );
Ya, this works. But, if I always have to do this in my every application, why should I not make a solution to the localization framework itself? This is a common problem to every localization projects. It should be solved at the localization framework level, but not at the application level.
Another reason is that: Programmers should be able to use "maketext" without the knowledge of object-oriented programming. A localization framework should be neat and simple. It should lower down its barrier, be friendly to the beginners, in order to encourage the use of localization and globalization. Apparently the current practice of Locale::Maketext(3) does not satisfy this request.
The third reason is: Since Locale::Maketext::Gettext(3) imports the lexicon from foreign sources, the class source file is left empty. It exists only to help the "get_handle" method looking for a proper language handle. Then, why not make it disappear, and be generated whenever needed? Why bother the programmers to put an empty class source file there?
How neat can we be?
imacat, 2003-04-29