From: Garrett Smith on
VK wrote:
> On Apr 18, 8:49 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> Where is the term "multinationalization" defined, so that a comparison
>> can be made?
>

[snip definitions]

>
> This way the FAQ topic is to be renamed to "Internationalization and
> localization in Javascript"
> http://en.wikipedia.org/wiki/Internationalization_and_localization
>

Without a clear definition of "multinationalisation," its hard to
justify keeping it instead of the more commonly understood
"internationalisation".

I kept British spelling to be consistent with the rest of the document,
though it probably doesn't matter much either way.

> Respectively the current FAQ question has to be significantly changed
> with all "multinationalization" stuff made of the top of one's head
> removed. The topics to remain and to be clarified:
> 1. Locale-dependent string comparison and sorting
> 2. Locale-dependent date and time display
> 3. Possibly a good library reference with Java-like Calendar
> functionality:
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html
>

If you want to propose those, elaborate on one of them. Y0ou might want
to dothis in a new thread.

[...]

--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: VK on
On Apr 19, 9:07 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> Without a clear definition of "multinationalisation," its hard to
> justify keeping it instead of the more commonly understood
> "internationalisation".

"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.

> I kept British spelling to be consistent with the rest of the document,
> though it probably doesn't matter much either way.

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.

> > Respectively the current FAQ question has to be significantly changed
> > with all "multinationalization" stuff made of the top of one's head
> > removed. The topics to remain and to be clarified:
> > 1. Locale-dependent string comparison and sorting
> > 2. Locale-dependent date and time display
> > 3. Possibly a good library reference with Java-like Calendar
> > functionality:
> >http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html
>
> If you want to propose those, elaborate on one of them. Y0ou might want
> to dothis in a new thread.

I may do it and post a test page for volunteers' testing as obviously
I am not having all possible locales available.

From: VK on
On Apr 19, 6:33 pm, Dr J R Stockton <reply1...(a)merlyn.demon.co.uk>
wrote:

> Perhaps you are trying to pass yourself off as an American.

I am an American but English is not my native language. Did I ever
over past years tried to hide it or claimed otherwise?

> Multinational is widely defined, and -isation is a sufficiently well-
> known ending.   That is how the English language works.

Noop, it doesn't work this way, Dr.Stockton. Neither any other
language for that matter. One doesn't make up a new word saying "and
now shall it be called by everyone this way and not that way because I
want it to be so".

http://www.google.com/#hl=en&q=multinationalization
http://www.google.com/#hl=en&q=multinationalisation

Any anyhow *programming* related usage to support you claims?

Also please note that both "international" and "internationalization"
are presented in prominent dictionaries. This is how the English
language works.

After all I know you to be Date/Time acclaimed super-specialist: but
never heard you claiming - nor I remember seeing you by actions - as a
philology specialist. Shall we not touch lesser known domains (applies
to both of us)?
From: Garrett Smith on
VK wrote:
> On Apr 19, 9:07 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> Without a clear definition of "multinationalisation," its hard to
>> justify keeping it instead of the more commonly understood
>> "internationalisation".
>
> "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).


>> I kept British spelling to be consistent with the rest of the document,
>> though it probably doesn't matter much either way.
>
> 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>

[...]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on
Garrett Smith wrote:
> VK wrote:
>> On Apr 19, 9:07 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:

[...]

> I see some gibberish. That entry needs a rewrite. Proposed:
[...]
>
> Changes:
> * Rewritten gibberish in concluding paragraph.
* Added a link to: <http://www.w3.org/TR/html4/sgml/entities.html>

>
> 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
...............^
Inserted space
[...]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Any RTF guru
Next: New Host Object Primer