The philosophy of JavaScript is to rely on platform services as much as possible,
while requiring very little of the interpreter. Whatever cannot be assumed to
be available on a given platform -- usually a browser and the operating system
on which it is used -- has to be packed into the script itself.
For example, the language does not provide function arguments to select language-specific
behavior for string sorting or date/time formatting. These operations are performed
using the settings of the interpreter's environment, which means that they are
determined by the user locale in the operating system, and/or by language and
locale settings in the browser. By not requiring a possibly complicated behavior,
a JavaScript interpreter need not support large data tables and complicated
algorithms.
In some ways, providing multiple language versions of a script is the
opposite of how internationalization and localization of software are generally
done. Since there are no resource bundles (and no standard way to load any
files), localized strings must be hardcoded in a script. Each language version
of a script must contain the strings for the target language. (By contrast,
application-level software separates all localizable content from the source
code and loads it from separate resource bundles and other data files.)
Scripts can be either translated as a whole, with translators only replacing
user-visible strings, or a server-side script can use a language-neutral template
and insert all of the strings for the user's language. Scripts that are assembled
'on the fly' essentially use a snapshot of the server's more traditional techniques,
such as resource bundles, to provide content that is tailored to the user.
Different implementations of the ECMAScript standard add various system objects
and functions that may provide for more application-style internationalization,
but are less portable. | 
