[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

i18n y l10n


Recorto y pego del manual de gettext.

A aquellos que después de leer esto todavía se empeñen en que localización
no es la mejor traducción posible de "localization", les sugiero
encarecidamente que propongan una palabra mejor, y que no desvirtúe el
significado original.

I18n, L10n, and Such

   Two long words appear all the time when we discuss support of native
language in programs, and these words have a precise meaning, worth
being explained here, once and for all in this document.  The words are
*internationalization* and *localization*.  Many people, tired of
writing these long words over and over again, took the habit of writing
"i18n" and "l10n" instead, quoting the first and last letter of each
word, and replacing the run of intermediate letters by a number merely
telling how many such letters there are.  But in this manual, in the
sake of clarity, we will patiently write the names in full, each time...

   By "internationalization", one refers to the operation by which a
program, or a set of programs turned into a package, is made aware of
and able to support multiple languages.  This is a generalization
process, by which the programs are untied from calling only English
strings or other English specific habits, and connected to generic ways
of doing the same, instead.  Program developers may use various
techniques to internationalize their programs.  Some of these have been
standardized.  GNU `gettext' offers one of these standards.  *Note

   By "localization", one means the operation by which, in a set of
programs already internationalized, one gives the program all needed
information so that it can adapt itself to handle its input and output
in a fashion which is correct for some native language and cultural
habits.  This is a particularisation process, by which generic methods
already implemented in an internationalized program are used in
specific ways.  The programming environment puts several functions to
the programmers disposal which allow this runtime configuration.  The
formal description of specific set of cultural habits for some country,
together with all associated translations targeted to the same native
language, is called the "locale" for this language or country.  Users
achieve localization of programs by setting proper values to special
environment variables, prior to executing those programs, identifying
which locale should be used.

   In fact, locale message support is only one component of the cultural
data that makes up a particular locale.  There are a whole host of
routines and functions provided to aid programmers in developing
internationalized software and which allow them to access the data
stored in a particular locale.  When someone presently refers to a
particular locale, they are obviously referring to the data stored
within that particular locale.  Similarly, if a programmer is referring
to "accessing the locale routines", they are referring to the complete
suite of routines that access all of the locale's information.

   One uses the expression "Native Language Support", or merely NLS,
for speaking of the overall activity or feature encompassing both
internationalization and localization, allowing for multi-lingual
interactions in a program.  In a nutshell, one could say that
internationalization is the operation by which further localizations
are made possible.

   Also, very roughly said, when it comes to multi-lingual messages,
internationalization is usually taken care of by programmers, and
localization is usually taken care of by translators.

 "c592092e000560f0f0e8eeeb0a040857" (a truly random sig)

Reply to: