* Larry Wall ([EMAIL PROTECTED]) [080126 16:58]:
> Last night I got a message entitled: "yum: 1 Updates Available".
> After a recent exchange on PerlMonks about join, I've been thinking
> about the problem of pluralization in interpolated strings, where we
> get things like:
>
> say "Received $m message{ 1==$m ?? '' !! 's' }."
>
> Any other cute ideas?
I totally agree with many responses, that special support for the English
language is not preferred, certainly when it bothers developers for
other natural languages. Imagin that you wrote your code this way for
a website, and then your boss (always blame your boss) decides that the
site must be ported to Chinese for expansion...
It would be nice if Perl joined nearly all other Open Source applications,
in being multi-languaged. During the lightningtalks of last YAPC::EU,
I called for localization of error messages in Perl 5.12, but Perl6
improvements are welcomed as well.
My idea: Recently, I released Log::Report, which is a new translation
framework. It combines exception-handling with report dispatch and
translations. What's new: some module produces a text, but that module
was found on CPAN. Only the author of the main program knows how to
handle the text. So, delay translations until an output layer is reached.
Locale::TextDomain and gettext translate immediately, as does $! They
translate on the location where the report emerges. Log::Dispatch and
Log::Log4perl cannot influence the text production process.
What my new Log::Report does, is delaying translations to the moment
it reaches the dispatcher. Like this:
package main;
dispatcher SYSLOG => 'syslog', language => 'en-US',
charset => 'ascii', facility => 'local4';
dispatcher STDOUT => 'website', language => 'cn',
charset => 'utf8';
run_some_code(); # text both to syslog and stdout
package Someone::Elses::Package;
use Log::Report 'translation-table-namespace';
sub run_some_code()
{ # Locale::TextDomain compatible syntax, info ~ print
info __nx"Received {m} messages", $m, m => $m;
}
To syslog in English (what I understand), and to the website in Chinese
(what I do not understand) Of course, there are quite some more features
in the module.
The translation tables can have gettext syntax, database driven, or maybe
a module with Perl routines from complex languages. (Only the first is
implemented on the moment, but the framework is present).
The provided try() is also implemented as dispatcher, which collects
the messages from the block, and has not yet been translated:
try { error __"help!" };
if($@) # an Log::Report::Dispatcher::Try object
{ my $exception = [EMAIL PROTECTED]>wasFatal;
$exception->throw # re-cast
if $ex->message !~ m/help/; # ignore call for help
}
When someone starts coding, it is more and more uncertain in which
languages it will be used later. So, it would be nice to help people
to avoid mistakes which may block an easy conversion.
For instance, best if texts are produced in as large blocks as possible,
outside the program file. We know how to do that: a template system.
Templates themselves are easily translatable. About a zillion or two
CPAN modules implement a Locale::TextDomain-like HASH-based substitution
system in templates.
Translations are impossible for syntaxes like this:
print "Received $m messages"
because the $m is already filled-in before print is called. For this
reason, a lookup in the translation table is impossible.
It would be nice to not translate above string into
print 'Received '.$m.' messages'
but
report info => 'Received {m} messages', m => $m,
linenr => __LINE__, ..etc..
(of course, some \Q\E like meta-syntax, not {})
Print() works internally more like printf(). No problem. Without
translation tables defined, it just takes what it got as first argument.
In the infrastructure, we need a reason for each message, like syslog
levels. Print, warn, and die have implied reasons (resp info, warn
and error). Everyone is tricking trace and verbose levels, so we need
a few more useful levels.
Concluding:
- hopefully, there is a way to simplify the work for all of us who do
need to support many languages within one application
- create one standard, so all CPAN modules integrate in the same way
- let's try to get Perl to handle languages!
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
