locale::maketext::tpj13.3

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

test of \f(CW\*(C`($directory == 1)\*(C'\fR no longer does the job.  And it means
that where English's grammatical category of number necessitates
only the two permutations of the first sentence based on \*(L"directory
[singular]\*(R" and \*(L"directories [plural]\*(R", Arabic has three \*(-- and,
worse, in the second sentence (\*(L"Your query matched \f(CW%g\fR file in \f(CW%g\fR
directory.\*(R"), where English has four, Arabic has nine.  You sense
an unwelcome, exponential trend taking shape.
.PP
Your Italian translator emails you back and says that \*(L"I searched 0
directories\*(R" (a possible English output of your program) is stilted,
and if you think that's fine English, that's your problem, but that
\&\fIjust will not do\fR in the language of Dante.  He insists that where
\&\f(CW$directory_count\fR is 0, your program should produce the Italian text
for "I \fIdidn't\fR scan \fIany\fR directories.\*(L".  And ditto for \*(R"I didn't
match any files in any directories\*(L", although he says the last part
about \*(R"in any directories" should probably just be left off.
.PP
You wonder how you'll get gettext to handle this; to accomodate the
ways Arabic, Chinese, and Italian deal with numbers in just these few
very simple phrases, you need to write code that will ask gettext for
different queries depending on whether the numerical values in
question are 1, 2, more than 2, or in some cases 0, and you still haven't
figured out the problem with the different word order in Chinese.
.PP
Then your Russian translator calls on the phone, to \fIpersonally\fR tell
you the bad news about how really unpleasant your life is about to
become:
.PP
Russian, like German or Latin, is an inflectional language; that is, nouns
and adjectives have to take endings that depend on their case
(i.e., nominative, accusative, genitive, etc...) \*(-- which is roughly a matter of
what role they have in syntax of the sentence \*(--
as well as on the grammatical gender (i.e., masculine, feminine, neuter)
and number (i.e., singular or plural) of the noun, as well as on the
declension class of the noun.  But unlike with most other inflected languages,
putting a number-phrase (like \*(L"ten\*(R" or \*(L"forty-three\*(R", or their Arabic
numeral equivalents) in front of noun in Russian can change the case and
number that noun is, and therefore the endings you have to put on it.
.PP
He elaborates:  In \*(L"I scanned \f(CW%g\fR directories\*(R", you'd \fIexpect\fR
\&\*(L"directories\*(R" to be in the accusative case (since it is the direct
object in the sentence) and the plural number,
except where \f(CW$directory_count\fR is 1, then you'd expect the singular, of
course.  Just like Latin or German.  \fIBut!\fR  Where \f(CW$directory_count\fR %
10 is 1 (\*(L"%\*(R" for modulo, remember), assuming \f(CW$directory\fR count is an
integer, and except where \f(CW$directory_count\fR % 100 is 11, \*(L"directories\*(R"
is forced to become grammatically singular, which means it gets the
ending for the accusative singular...  You begin to visualize the code
it'd take to test for the problem so far, \fIand still work for Chinese
and Arabic and Italian\fR, and how many gettext items that'd take, but
he keeps going...  But where \f(CW$directory_count\fR % 10 is 2, 3, or 4
(except where \f(CW$directory_count\fR % 100 is 12, 13, or 14), the word for
\&\*(L"directories\*(R" is forced to be genitive singular \*(-- which means another
ending... The room begins to spin around you, slowly at first...  But
with \fIall other\fR integer values, since \*(L"directory\*(R" is an inanimate
noun, when preceded by a number and in the nominative or accusative
cases (as it is here, just your luck!), it does stay plural, but it is
forced into the genitive case \*(-- yet another ending...  And
you never hear him get to the part about how you're going to run into
similar (but maybe subtly different) problems with other Slavic
languages like Polish, because the floor comes up to meet you, and you
fade into unconsciousness.
.PP
The above cautionary tale relates how an attempt at localization can
lead from programmer consternation, to program obfuscation, to a need
for sedation.  But careful evaluation shows that your choice of tools
merely needed further consideration.
.Sh "The Linguistic View"
.IX Subsection "The Linguistic View"
.RS 4
\&\*(L"It is more complicated than you think.\*(R"
.Sp
\&\-\- The Eighth Networking Truth, from \s-1RFC\s0 1925
.RE
.PP
The field of Linguistics has expended a great deal of effort over the
past century trying to find grammatical patterns which hold across
languages; it's been a constant process
of people making generalizations that should apply to all languages,
only to find out that, all too often, these generalizations fail \*(--
sometimes failing for just a few languages, sometimes whole classes of
languages, and sometimes nearly every language in the world except
English.  Broad statistical trends are evident in what the \*(L"average
language\*(R" is like as far as what its rules can look like, must look
like, and cannot look like.  But the \*(L"average language\*(R" is just as
unreal a concept as the \*(L"average person\*(R" \*(-- it runs up against the
fact no language (or person) is, in fact, average.  The wisdom of past
experience leads us to believe that any given language can do whatever
it wants, in any order, with appeal to any kind of grammatical
categories wants \*(-- case, number, tense, real or metaphoric
characteristics of the things that words refer to, arbitrary or
predictable classifications of words based on what endings or prefixes
they can take, degree or means of certainty about the truth of
statements expressed, and so on, ad infinitum.
.PP
Mercifully, most localization tasks are a matter of finding ways to
translate whole phrases, generally sentences, where the context is
relatively set, and where the only variation in content is \fIusually\fR
in a number being expressed \*(-- as in the example sentences above.
Translating specific, fully-formed sentences is, in practice, fairly
foolproof \*(-- which is good, because that's what's in the phrasebooks
that so many tourists rely on.  Now, a given phrase (whether in a
phrasebook or in a gettext lexicon) in one language \fImight\fR have a
greater or lesser applicability than that phrase's translation into
another language \*(-- for example, strictly speaking, in Arabic, the
\&\*(L"your\*(R" in \*(L"Your query matched...\*(R" would take a different form
depending on whether the user is male or female; so the Arabic
translation \*(L"your[feminine] query\*(R" is applicable in fewer cases than
the corresponding English phrase, which doesn't distinguish the user's
gender.  (In practice, it's not feasable to have a program know the
user's gender, so the masculine \*(L"you\*(R" in Arabic is usually used, by
default.)
.PP
But in general, such surprises are rare when entire sentences are
being translated, especially when the functional context is restricted
to that of a computer interacting with a user either to convey a fact
or to prompt for a piece of information.  So, for purposes of
localization, translation by phrase (generally by sentence) is both the
simplest and the least problematic.
.Sh "Breaking gettext"
.IX Subsection "Breaking gettext"
.RS 4
\&\*(L"It Has To Work.\*(R"
.Sp
\&\-\- First Networking Truth, \s-1RFC\s0 1925
.RE
.PP
Consider that sentences in a tourist phrasebook are of two types: ones
like \*(L"How do I get to the marketplace?\*(R" that don't have any blanks to
fill in, and ones like \*(L"How much do these _\|_\|_ cost?\*(R", where there's
one or more blanks to fill in (and these are usually linked to a
list of words that you can put in that blank: \*(L"fish\*(R", \*(L"potatoes\*(R",
\&\*(L"tomatoes\*(R", etc.)  The ones with no blanks are no problem, but the
fill-in-the-blank ones may not be really straightforward. If it's a
Swahili phrasebook, for example, the authors probably didn't bother to
tell you the complicated ways that the verb \*(L"cost\*(R" changes its
inflectional prefix depending on the noun you're putting in the blank.
The trader in the marketplace will still understand what you're saying if
you say \*(L"how much do these potatoes cost?\*(R" with the wrong
inflectional prefix on \*(L"cost\*(R".  After all, \fIyou\fR can't speak proper Swahili,
\&\fIyou're\fR just a tourist.  But while tourists can be stupid, computers
are supposed to be smart; the computer should be able to fill in the
blank, and still have the results be grammatical.
.PP
In other words, a phrasebook entry takes some values as parameters
(the things that you fill in the blank or blanks), and provides a value
based on these parameters, where the way you get that final value from
the given values can, properly speaking, involve an arbitrarily
complex series of operations.  (In the case of Chinese, it'd be not at
all complex, at least in cases like the examples at the beginning of
this article; whereas in the case of Russian it'd be a rather complex
series of operations.  And in some languages, the
complexity could be spread around differently: while the act of
putting a number-expression in front of a noun phrase might not be
complex by itself, it may change how you have to, for example, inflect
a verb elsewhere in the sentence.  This is what in syntax is called
\&\*(L"long-distance dependencies\*(R".)
.PP
This talk of parameters and arbitrary complexity is just another way
to say that an entry in a phrasebook is what in a programming language
would be called a \*(L"function\*(R".  Just so you don't miss it, this is the
crux of this article: \fIA phrase is a function; a phrasebook is a
bunch of functions.\fR
.PP
The reason that using gettext runs into walls (as in the above
second-person horror story) is that you're trying to use a string (or
worse, a choice among a bunch of strings) to do what you really need a
function for \*(-- which is futile.  Preforming (s)printf interpolation
on the strings which you get back from gettext does allow you to do \fIsome\fR
common things passably well... sometimes... sort of; but, to paraphrase
what some people say about \f(CW\*(C`csh\*(C'\fR script programming, \*(L"it fools you
into thinking you can use it for real things, but you can't, and you
don't discover this until you've already spent too much time trying,
and by then it's too late.\*(R"
.Sh "Replacing gettext"
.IX Subsection "Replacing gettext"
So, what needs to replace gettext is a system that supports lexicons
of functions instead of lexicons of strings.  An entry in a lexicon
from such a system should \fInot\fR look like this:
.PP
.Vb 1
\&  "J\*(Aqai trouv\exE9 %g fichiers dans %g r\exE9pertoires"
.Ve
.PP
[\exE9 is e\-acute in Latin\-1.  Some pod renderers would
scream if I used the actual character here. \*(-- \s-1SB\s0]
.PP
but instead like this, bearing in mind that this is just a first stab:
.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
Now, there's no particularly obvious way to store anything but strings
in a gettext lexicon; so it looks like we just have to start over and
make something better, from scratch.  I call my shot at a
gettext-replacement system \*(L"Maketext\*(R", or, in \s-1CPAN\s0 terms,
Locale::Maketext.
.PP
When designing Maketext, I chose to plan its main features in terms of
\&\*(L"buzzword compliance\*(R".  And here are the buzzwords:
.Sh "Buzzwords: Abstraction and Encapsulation"
.IX Subsection "Buzzwords: Abstraction and Encapsulation"
The complexity of the language you're trying to output a phrase in is
entirely abstracted inside (and encapsulated within) the Maketext module
for that interface.  When you call:
.PP
.Vb 2
\&  print $lang\->maketext("You have [quant,_1,piece] of new mail.",
\&                       scalar(@messages));
.Ve
.PP
you don't know (and in fact can't easily find out) whether this will
involve lots of figuring, as in Russian (if \f(CW$lang\fR is a handle to the
Russian module), or relatively little, as in Chinese.  That kind of
abstraction and encapsulation may encourage other pleasant buzzwords
like modularization and stratification, depending on what design
decisions you make.
.Sh "Buzzword: Isomorphism"
.IX Subsection "Buzzword: Isomorphism"
\&\*(L"Isomorphism\*(R" means \*(L"having the same structure or form\*(R"; in discussions
of program design, the word takes on the special, specific meaning that
your implementation of a solution to a problem \fIhas the same
structure\fR as, say, an informal verbal description of the solution, or
maybe of the problem itself.  Isomorphism is, all things considered,
a good thing \*(-- it's what problem-solving (and solution-implementing)
should look like.
.PP
What's wrong the with gettext-using code like this...
.PP
.Vb 9
\&  printf( $file_count == 1 ?
\&    ( $directory_count == 1 ?
\&     "Your query matched %g file in %g directory." :
\&     "Your query matched %g file in %g directories." ) :
\&    ( $directory_count == 1 ?
\&     "Your query matched %g files in %g directory." :
\&     "Your query matched %g files in %g directories." ),
\&   $file_count, $directory_count,
\&  );
.Ve
.PP
is first off that it's not well abstracted \*(-- these ways of testing
for grammatical number (as in the expressions like \f(CW\*(C`foo == 1 ?
singular_form : plural_form\*(C'\fR) should be abstracted to each language
module, since how you get grammatical number is language-specific.
.PP
But second off, it's not isomorphic \*(-- the \*(L"solution\*(R" (i.e., the
phrasebook entries) for Chinese maps from these four English phrases to
the one Chinese phrase that fits for all of them.  In other words, the
informal solution would be \*(L"The way to say what you want in Chinese is
with the one phrase 'For your question, in Y directories you would
find X files'\*(R" \*(-- and so the implemented solution should be,
isomorphically, just a straightforward way to spit out that one
phrase, with numerals properly interpolated.  It shouldn't have to map
from the complexity of other languages to the simplicity of this one.
.Sh "Buzzword: Inheritance"
.IX Subsection "Buzzword: Inheritance"
There's a great deal of reuse possible for sharing of phrases between
modules for related dialects, or for sharing of auxiliary functions
between related languages.  (By \*(L"auxiliary functions\*(R", I mean
functions that don't produce phrase-text, but which, say, return an
answer to \*(L"does this number require a plural noun after it?\*(R".  Such
auxiliary functions would be used in the internal logic of functions
that actually do produce phrase-text.)
.PP
In the case of sharing phrases, consider that you have an interface
already localized for American English (probably by having been
written with that as the native locale, but that's incidental).
Localizing it for \s-1UK\s0 English should, in practical terms, be just a
matter of running it past a British person with the instructions to
indicate what few phrases would benefit from a change in spelling or
possibly minor rewording.  In that case, you should be able to put in
the \s-1UK\s0 English localization module \fIonly\fR those phrases that are
UK-specific, and for all the rest, \fIinherit\fR from the American
English module.  (And I expect this same situation would apply with
Brazilian and Continental Portugese, possbily with some \fIvery\fR
closely related languages like Czech and Slovak, and possibly with the
slightly different \*(L"versions\*(R" of written Mandarin Chinese, as I hear exist in
Taiwan and mainland China.)
.PP
As to sharing of auxiliary functions, consider the problem of Russian
numbers from the beginning of this article; obviously, you'd want to
write only once the hairy code that, given a numeric value, would
return some specification of which case and number a given quanitified
noun should use.  But suppose that you discover, while localizing an
interface for, say, Ukranian (a Slavic language related to Russian,
spoken by several million people, many of whom would be relieved to
find that your Web site's or software's interface is available in
their language), that the rules in Ukranian are the same as in Russian
for quantification, and probably for many other grammatical functions.
While there may well be no phrases in common between Russian and
Ukranian, you could still choose to have the Ukranian module inherit
from the Russian module, just for the sake of inheriting all the
various grammatical methods.  Or, probably better organizationally,
you could move those functions to a module called \f(CW\*(C`_E_Slavic\*(C'\fR or
something, which Russian and Ukranian could inherit useful functions
from, but which would (presumably) provide no lexicon.
.Sh "Buzzword: Concision"
.IX Subsection "Buzzword: Concision"
Okay, concision isn't a buzzword.  But it should be, so I decree that
as a new buzzword, \*(L"concision\*(R" means that simple common things should
be expressible in very few lines (or maybe even just a few characters)
of code \*(-- call it a special case of \*(L"making simple things easy and