locale::maketext::tpj13.3

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

hard things possible\*(R", and see also the role it played in the
MIDI::Simple language, discussed elsewhere in this issue [TPJ#13].
.PP
Consider our first stab at an entry in our \*(L"phrasebook of functions\*(R":
.PP
.Vb 8
\&  sub I_found_X1_files_in_X2_directories {
\&    my( $files, $dirs ) = @_[0,1];
\&    $files = sprintf("%g %s", $files,
\&      $files == 1 ? \*(Aqfichier\*(Aq : \*(Aqfichiers\*(Aq);
\&    $dirs = sprintf("%g %s", $dirs,
\&      $dirs == 1 ? "r\exE9pertoire" : "r\exE9pertoires");
\&    return "J\*(Aqai trouv\exE9 $files dans $dirs.";
\&  }
.Ve
.PP
You may sense that a lexicon (to use a non-committal catch-all term for a
collection of things you know how to say, regardless of whether they're
phrases or words) consisting of functions \fIexpressed\fR as above would
make for rather long-winded and repetitive code \*(-- even if you wisely
rewrote this to have quantification (as we call adding a number
expression to a noun phrase) be a function called like:
.PP
.Vb 6
\&  sub I_found_X1_files_in_X2_directories {
\&    my( $files, $dirs ) = @_[0,1];
\&    $files = quant($files, "fichier");
\&    $dirs =  quant($dirs,  "r\exE9pertoire");
\&    return "J\*(Aqai trouv\exE9 $files dans $dirs.";
\&  }
.Ve
.PP
And you may also sense that you do not want to bother your translators
with having to write Perl code \*(-- you'd much rather that they spend
their \fIvery costly time\fR on just translation.  And this is to say
nothing of the near impossibility of finding a commercial translator
who would know even simple Perl.
.PP
In a first-hack implementation of Maketext, each language-module's
lexicon looked like this:
.PP
.Vb 10
\& %Lexicon = (
\&   "I found %g files in %g directories"
\&   => sub {
\&      my( $files, $dirs ) = @_[0,1];
\&      $files = quant($files, "fichier");
\&      $dirs =  quant($dirs,  "r\exE9pertoire");
\&      return "J\*(Aqai trouv\exE9 $files dans $dirs.";
\&    },
\&  ... and so on with other phrase => sub mappings ...
\& );
.Ve
.PP
but I immediately went looking for some more concise way to basically
denote the same phrase-function \*(-- a way that would also serve to
concisely denote \fImost\fR phrase-functions in the lexicon for \fImost\fR
languages.  After much time and even some actual thought, I decided on
this system:
.PP
* Where a value in a \f(CW%Lexicon\fR hash is a contentful string instead of
an anonymous sub (or, conceivably, a coderef), it would be interpreted
as a sort of shorthand expression of what the sub does.  When accessed
for the first time in a session, it is parsed, turned into Perl code,
and then eval'd into an anonymous sub; then that sub replaces the
original string in that lexicon.  (That way, the work of parsing and
evaling the shorthand form for a given phrase is done no more than
once per session.)
.PP
* Calls to \f(CW\*(C`maketext\*(C'\fR (as Maketext's main function is called) happen
thru a \*(L"language session handle\*(R", notionally very much like an \s-1IO\s0
handle, in that you open one at the start of the session, and use it
for \*(L"sending signals\*(R" to an object in order to have it return the text
you want.
.PP
So, this:
.PP
.Vb 2
\&  $lang\->maketext("You have [quant,_1,piece] of new mail.",
\&                 scalar(@messages));
.Ve
.PP
basically means this: look in the lexicon for \f(CW$lang\fR (which may inherit
from any number of other lexicons), and find the function that we
happen to associate with the string \*(L"You have [quant,_1,piece] of new
mail\*(R" (which is, and should be, a functioning \*(L"shorthand\*(R" for this
function in the native locale \*(-- English in this case).  If you find
such a function, call it with \f(CW$lang\fR as its first parameter (as if it
were a method), and then a copy of scalar(@messages) as its second,
and then return that value.  If that function was found, but was in
string shorthand instead of being a fully specified function, parse it
and make it into a function before calling it the first time.
.PP
* The shorthand uses code in brackets to indicate method calls that
should be performed.  A full explanation is not in order here, but a
few examples will suffice:
.PP
.Vb 1
\&  "You have [quant,_1,piece] of new mail."
.Ve
.PP
The above code is shorthand for, and will be interpreted as,
this:
.PP
.Vb 8
\&  sub {
\&    my $handle = $_[0];
\&    my(@params) = @_;
\&    return join \*(Aq\*(Aq,
\&      "You have ",
\&      $handle\->quant($params[1], \*(Aqpiece\*(Aq),
\&      "of new mail.";
\&  }
.Ve
.PP
where \*(L"quant\*(R" is the name of a method you're using to quantify the
noun \*(L"piece\*(R" with the number \f(CW$params\fR[0].
.PP
A string with no brackety calls, like this:
.PP
.Vb 1
\&  "Your search expression was malformed."
.Ve
.PP
is somewhat of a degerate case, and just gets turned into:
.PP
.Vb 1
\&  sub { return "Your search expression was malformed." }
.Ve
.PP
However, not everything you can write in Perl code can be written in
the above shorthand system \*(-- not by a long shot.  For example, consider
the Italian translator from the beginning of this article, who wanted
the Italian for \*(L"I didn't find any files\*(R" as a special case, instead
of \*(L"I found 0 files\*(R".  That couldn't be specified (at least not easily
or simply) in our shorthand system, and it would have to be written
out in full, like this:
.PP
.Vb 10
\&  sub {  # pretend the English strings are in Italian
\&    my($handle, $files, $dirs) = @_[0,1,2];
\&    return "I didn\*(Aqt find any files" unless $files;
\&    return join \*(Aq\*(Aq,
\&      "I found ",
\&      $handle\->quant($files, \*(Aqfile\*(Aq),
\&      " in ",
\&      $handle\->quant($dirs,  \*(Aqdirectory\*(Aq),
\&      ".";
\&  }
.Ve
.PP
Next to a lexicon full of shorthand code, that sort of sticks out like a
sore thumb \*(-- but this \fIis\fR a special case, after all; and at least
it's possible, if not as concise as usual.
.PP
As to how you'd implement the Russian example from the beginning of
the article, well, There's More Than One Way To Do It, but it could be
something like this (using English words for Russian, just so you know
what's going on):
.PP
.Vb 1
\&  "I [quant,_1,directory,accusative] scanned."
.Ve
.PP
This shifts the burden of complexity off to the quant method.  That
method's parameters are: the numeric value it's going to use to
quantify something; the Russian word it's going to quantify; and the
parameter \*(L"accusative\*(R", which you're using to mean that this
sentence's syntax wants a noun in the accusative case there, although
that quantification method may have to overrule, for grammatical
reasons you may recall from the beginning of this article.
.PP
Now, the Russian quant method here is responsible not only for
implementing the strange logic necessary for figuring out how Russian
number-phrases impose case and number on their noun-phrases, but also
for inflecting the Russian word for \*(L"directory\*(R".  How that inflection
is to be carried out is no small issue, and among the solutions I've
seen, some (like variations on a simple lookup in a hash where all
possible forms are provided for all necessary words) are
straightforward but \fIcan\fR become cumbersome when you need to inflect
more than a few dozen words; and other solutions (like using
algorithms to model the inflections, storing only root forms and
irregularities) \fIcan\fR involve more overhead than is justifiable for
all but the largest lexicons.
.PP
Mercifully, this design decision becomes crucial only in the hairiest
of inflected languages, of which Russian is by no means the \fIworst\fR case
scenario, but is worse than most.  Most languages have simpler
inflection systems; for example, in English or Swahili, there are
generally no more than two possible inflected forms for a given noun
(\*(L"error/errors\*(R"; \*(L"kosa/makosa\*(R"), and the
rules for producing these forms are fairly simple \*(-- or at least,
simple rules can be formulated that work for most words, and you can
then treat the exceptions as just \*(L"irregular\*(R", at least relative to
your ad hoc rules.  A simpler inflection system (simpler rules, fewer
forms) means that design decisions are less crucial to maintaining
sanity, whereas the same decisions could incur
overhead-versus-scalability problems in languages like Russian.  It
may \fIalso\fR be likely that code (possibly in Perl, as with
Lingua::EN::Inflect, for English nouns) has already
been written for the language in question, whether simple or complex.
.PP
Moreover, a third possibility may even be simpler than anything
discussed above: \*(L"Just require that all possible (or at least
applicable) forms be provided in the call to the given language's quant
method, as in:\*(R"
.PP
.Vb 1
\&  "I found [quant,_1,file,files]."
.Ve
.PP
That way, quant just has to chose which form it needs, without having
to look up or generate anything.  While possibly not optimal for
Russian, this should work well for most other languages, where
quantification is not as complicated an operation.
.Sh "The Devil in the Details"
.IX Subsection "The Devil in the Details"
There's plenty more to Maketext than described above \*(-- for example,
there's the details of how language tags (\*(L"en-US\*(R", \*(L"i\-pwn\*(R", \*(L"fi\*(R",
etc.) or locale IDs (\*(L"en_US\*(R") interact with actual module naming
(\*(L"BogoQuery/Locale/en_us.pm\*(R"), and what magic can ensue; there's the
details of how to record (and possibly negotiate) what character
encoding Maketext will return text in (\s-1UTF8\s0? Latin\-1? \s-1KOI8\s0?).  There's
the interesting fact that Maketext is for localization, but nowhere
actually has a "\f(CW\*(C`use locale;\*(C'\fR" anywhere in it.  For the curious,
there's the somewhat frightening details of how I actually
implement something like data inheritance so that searches across
modules' \f(CW%Lexicon\fR hashes can parallel how Perl implements method
inheritance.
.PP
And, most importantly, there's all the practical details of how to
actually go about deriving from Maketext so you can use it for your
interfaces, and the various tools and conventions for starting out and
maintaining individual language modules.
.PP
That is all covered in the documentation for Locale::Maketext and the
modules that come with it, available in \s-1CPAN\s0.  After having read this
article, which covers the why's of Maketext, the documentation,
which covers the how's of it, should be quite straightfoward.
.Sh "The Proof in the Pudding: Localizing Web Sites"
.IX Subsection "The Proof in the Pudding: Localizing Web Sites"
Maketext and gettext have a notable difference: gettext is in C,
accessible thru C library calls, whereas Maketext is in Perl, and
really can't work without a Perl interpreter (although I suppose
something like it could be written for C).  Accidents of history (and
not necessarily lucky ones) have made \*(C+ the most common language for
the implementation of applications like word processors, Web browsers,
and even many in-house applications like custom query systems.  Current
conditions make it somewhat unlikely that the next one of any of these
kinds of applications will be written in Perl, albeit clearly more for
reasons of custom and inertia than out of consideration of what is the
right tool for the job.
.PP
However, other accidents of history have made Perl a well-accepted
language for design of server-side programs (generally in \s-1CGI\s0 form)
for Web site interfaces.  Localization of static pages in Web sites is
trivial, feasable either with simple language-negotiation features in
servers like Apache, or with some kind of server-side inclusions of
language-appropriate text into layout templates.  However, I think
that the localization of Perl-based search systems (or other kinds of
dynamic content) in Web sites, be they public or access-restricted,
is where Maketext will see the greatest use.
.PP
I presume that it would be only the exceptional Web site that gets
localized for English \fIand\fR Chinese \fIand\fR Italian \fIand\fR Arabic
\&\fIand\fR Russian, to recall the languages from the beginning of this
article \*(-- to say nothing of German, Spanish, French, Japanese,
Finnish, and Hindi, to name a few languages that benefit from large
numbers of programmers or Web viewers or both.
.PP
However, the ever-increasing internationalization of the Web (whether
measured in terms of amount of content, of numbers of content writers
or programmers, or of size of content audiences) makes it increasingly
likely that the interface to the average Web-based dynamic content
service will be localized for two or maybe three languages.  It is my
hope that Maketext will make that task as simple as possible, and will
remove previous barriers to localization for languages dissimilar to
English.
.PP
.Vb 1
\& _\|_END_\|_
.Ve
.PP
Sean M. Burke ([e-mail]) has a Master's in linguistics
from Northwestern University; he specializes in language technology.
Jordan Lachler ([e-mail]) is a PhD student in the Department of
Linguistics at the University of New Mexico; he specializes in
morphology and pedagogy of North American native languages.
.Sh "References"
.IX Subsection "References"
Alvestrand, Harald Tveit.  1995.  \fI\s-1RFC\s0 1766: Tags for the
Identification of Languages.\fR
\&\f(CW\*(C`ftp://ftp.isi.edu/in\-notes/rfc1766.txt\*(C'\fR
[Now see \s-1RFC\s0 3066.]
.PP
Callon, Ross, editor.  1996.  \fI\s-1RFC\s0 1925: The Twelve
Networking Truths.\fR
\&\f(CW\*(C`ftp://ftp.isi.edu/in\-notes/rfc1925.txt\*(C'\fR
.PP
Drepper, Ulrich, Peter Miller,
and Franc\*,ois Pinard.  1995\-2001.  \s-1GNU\s0
\&\f(CW\*(C`gettext\*(C'\fR.  Available in \f(CW\*(C`ftp://prep.ai.mit.edu/pub/gnu/\*(C'\fR, with
extensive docs in the distribution tarball.  [Since
I wrote this article in 1998, I now see that the
gettext docs are now trying more to come to terms with
plurality.  Whether useful conclusions have come from it
is another question altogether. \*(-- \s-1SMB\s0, May 2001]
.PP
Forbes, Nevill.  1964.  \fIRussian Grammar.\fR  Third Edition, revised
by J. C. Dumbreck.  Oxford University Press.