VK said:
"multinationalisation" - "internationalisation" are not the
conflicting terms,
"multinationalisation" - "localisation" are, thus:
"Internationalisation and localisation in JavaScript"
like for
C++
http://www.i18nguy.com/
Ruby
http://ri18n.berlios.de/
PHP
http://onlamp.com/pub/a/php/2002/11/28/php_i18n.html
etc.
clj doesn't need to express everything in some peculiar clj'ed way
btw the PHP article is called "Internationalization and Localization
with PHP", so "with" not "in", which is IMHO a much better wording. It
is not about JavaScript itself being "internationalised" or
"localised". It is about native and added JavaScript tools to provide
a localised output or to handle input in a localised way.
The PHP article is about strategies for i18n and l10n, so "with" is
appropriate because the article explains how one would go about
localizing content with PHP.
For the c.l.js entry, the focus is on the language itself. Changing "in
javascript" to "with javascript" changes the statement to a question of
"how do I...".
The second question is not answered by the entry's answer. It is
somewhat answered by: "How do I get a jsp/php variable into client-side
javascript?"
I see some gibberish. That entry needs a rewrite. Proposed:
+-----------------------------------------------------------------------
| "How do I get a jsp/php variable into client-side javascript?"
| Use the server-side language to generate the javascript:
|
| // JSP
| var jsvar = "${ jspVar }";
| // PHP
| var jsvar = "<?php echo $phpVar ?>";
|
| If an inline-script tag is used, the string must not contain any
| markup-significant characters such as <, >, &, ', or ". Such
| characters must be converted to HTML entities on the server.
|
| *
http://www.w3.org/TR/html4/sgml/entities.html
`-----------------------------------------------------------------------
Changes:
* Rewritten gibberish in concluding paragraph.
For the FAQ entry of this subject (i18n and l10n), the proposed text:
+-----------------------------------------------------------------------
| Internationalisation means using one form which is everywhere both
| acceptable and understood. Any international standard not supported by
| default can be coded for.
|
| For example, there is an International Standard for numeric Gregorian
| date format; but none for decimal and thousands separators.
|
| Localisation means using different forms for different readers. It
| cannot work well in general, because it requires a knowledge of all
| preferences and the ability to choose the right one, in an environment
| where many systems are inappropriately set anyway.
|
| ECMAScript has a few localization features. The various
| toString()methods are all implementation dependent, but tend to use
| either UK or US settings (not necessarily correctly). ECMAScript Ed. 3
| introduced some capabilities, including the toLocaleString()method
| which should create a string based on the host's locale.
`-----------------------------------------------------------------------
Changes:
* changed the term "Multinationalisation" to "localisation".
* Changed "Javascript" to ECMAScript in third paragraph.
* removed the last paragraph of "in the future of ECMAScript" (it seemed
pointlessly speculative).
It is hugely matter for Dr. Stockton I guess
From the historical
fairness point of view the first FAQ and all descendants were written
using the US spelling rules. Also CSS and DOM terms use the US
spelling rules ("behavior" - not "behaviour", "centre" - not "center",
"color" - not "colour"). "To change the colour use elm.style.color"...
Whatever though.
There was actually a w3c proposal to change that...
here:
<
http://lists.w3.org/Archives/Public/www-style/2009Feb/0475.html>
[...]
