Prev: www.sexpornnude.com
Next: Send Unlimited Free sms World Wide
From: Thomas 'PointedEars' Lahn on 9 Dec 2009 18:07
Garrett Smith wrote:

> Proposed to remove text for: #localization
> Replace:
> | Much more support is expected in future versions of ECMAScript.
> with:
> | ECMAScript 5 introduced Date.prototype.toISOString.

Date.prototype.toISOString() is the exact opposite of L10n.

And can we drop the bogus "multinationalisation" definition, please? There
is only i18n (internationalisation, mainly concerns the natural language of
the UI) and L10n (localisation, concerns location-specific adaptations such
as date and time format).


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: Dr J R Stockton on 10 Dec 2009 12:56
In comp.lang.javascript message <hfndo3$mcj$1(a)news.eternal-
september.org>, Tue, 8 Dec 2009 21:48:44, Garrett Smith
<dhtmlkitchen(a)gmail.com> posted:
>
>Proposed text for #futureEcmaScript:
>| The 5th Edition of ECMAScript was approved on 2009-12-04. There is
>| some support in recent implementations (JScript 5.8, JavaScript 1.8,
>| JavaScriptCore).

Does not, as a paragraph, make sense. The only thing to which
"implementations" can refer is the 5th Edn itself; and an implementation
of 5th Edn must have substantially complete support for 5th Edn.

Given that you seem to know little about the use of JavaScript outside
browsers showing WWW pages, what you must mean is : "At December 2009,
there is some support in recent browsers" or "At that date, there was
some support in recent browsers". (In a document subject to updating,
any reference to a date/time needs to have that date/time indicated
adjacently.)



>http://www.ecma-international.org/publications/standards/Ecma-262.htm
>
>Proposed to remove text for: #localization

#localization is a bad anchor value. Since the Web is an international
medium, pages should be written in a manner which is as far as practical
understandable by all people independent of their cultural origin, which
is in general unknown to the page author and his code. Pages should in
fact be delocalised, unless of limited interest.


>Replace:
>| Much more support is expected in future versions of ECMAScript.
>with:
>| ECMAScript 5 introduced Date.prototype.toISOString.

That routine is misnamed; it should be .toJSONDateTimeString, since that
is evidently its intended use. And .toISOString should have been
reserves for something more generally useful and ISO 8601 compatible.

The present .toISOString will be useful almost exclusively in a machine-
to-machine context, whereas ISO 8601 provides formats suitable both for
that and for ordinary use.

Perhaps the FAQ should have a Date Object method .toFormat(F)
in which F is a format string. Letters Y M D h m s stand for four-digit
year and two-digit month..second, other non-alphanumerics stand for
themselves. With that, and maybe a little else (G, L, U giving "GMT",
"LCT", "UTC", maybe), most useful Gregorian formats are available. The
code need not be long, and can illustrate switch.

A more general version is in <js-dobj2.htm>, including Week Numbers and
Ordinal Dates.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
From: Garrett Smith on 19 Dec 2009 00:20
Dr J R Stockton wrote:
> In comp.lang.javascript message <hfndo3$mcj$1(a)news.eternal-
> september.org>, Tue, 8 Dec 2009 21:48:44, Garrett Smith
> <dhtmlkitchen(a)gmail.com> posted:
>> Proposed text for #futureEcmaScript:
>> | The 5th Edition of ECMAScript was approved on 2009-12-04. There is
>> | some support in recent implementations (JScript 5.8, JavaScript 1.8,
>> | JavaScriptCore).
>
> Does not, as a paragraph, make sense. The only thing to which
> "implementations" can refer is the 5th Edn itself; and an implementation
> of 5th Edn must have substantially complete support for 5th Edn.
>

I got that you think it doesn't make sense. An implementation of
ECMAScript is version-agnostic. The paragraph is correct in that there
is some support in recent implementations of ECMAScript engines
(JScript, et al).

> Given that you seem to know little about the use of JavaScript outside
> browsers showing WWW pages, what you must mean is : "At December 2009,
> there is some support in recent browsers" or "At that date, there was
> some support in recent browsers". (In a document subject to updating,
> any reference to a date/time needs to have that date/time indicated
> adjacently.)
>

While it is true that I am mainly focused on browsers, JScript is not a
browser. The change is part of JScript.

>> http://www.ecma-international.org/publications/standards/Ecma-262.htm
>>
>> Proposed to remove text for: #localization
>
> #localization is a bad anchor value. Since the Web is an international
> medium, pages should be written in a manner which is as far as practical
> understandable by all people independent of their cultural origin, which
> is in general unknown to the page author and his code. Pages should in
> fact be delocalised, unless of limited interest.

I understand that you believe "localization" is a bad anchor value.
What I do not understand is the reason for that opinion.

> Perhaps the FAQ should have a Date Object method .toFormat(F)

A formatting method, with localization, would be much too much for the
FAQ. The formatDate function seems like the right approach for reasons
stated in the FAQ and in the links to the w3c note and Kuhn page. The
routine can be tweaked to allow extended years. We'll come back to that.

There are various things that could be desirable. For example,
getFirstDayOfMonth, isLeapYear. That seems like a little too much
detail for the FAQ.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 19 Dec 2009 00:22
Thomas 'PointedEars' Lahn wrote:
> Garrett Smith wrote:
>
>> Proposed to remove text for: #localization
>> Replace:
>> | Much more support is expected in future versions of ECMAScript.
>> with:
>> | ECMAScript 5 introduced Date.prototype.toISOString.
>
> Date.prototype.toISOString() is the exact opposite of L10n.
>
> And can we drop the bogus "multinationalisation" definition, please?

It doesn't seem to be an FAQ, It does notseem to be a common term.

Proposal to remove the "multinationalisation" paragraph and replace the
FAQ title with "Localization".

Any objection to that?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dr J R Stockton on 20 Dec 2009 10:31
In comp.lang.javascript message <hghnva$m6m$2(a)news.eternal-
september.org>, Fri, 18 Dec 2009 21:22:47, Garrett Smith
<dhtmlkitchen(a)gmail.com> posted:
>Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>
>>> Proposed to remove text for: #localization
>>> Replace:
>>> | Much more support is expected in future versions of ECMAScript.
>>> with:
>>> | ECMAScript 5 introduced Date.prototype.toISOString.
>> Date.prototype.toISOString() is the exact opposite of L10n.
>> And can we drop the bogus "multinationalisation" definition, please?
>
>It doesn't seem to be an FAQ, It does notseem to be a common term.
>
>Proposal to remove the "multinationalisation" paragraph and replace the
>FAQ title with "Localization".
>
>Any objection to that?


Yes.

Localisation should be discouraged, even more than multinationalisation.

Whenever practicable, an internationally-standard form should be used on
the World-Wide Web. And that is the international meaning of
"internationally", not the American one, which usually means "not us"
(where "us" possibly includes Canada) and sometimes means "us & Canada".

By habitually doing things its own foolish way, the USA makes things
unnecessarily difficult for itself, and inconveniences other peoples.

Using local forms, except where they are the JavaScript default, leads
to bloat and error, both in coding and in reading.

Then, what local form *should* be used? There are so many immigrants
nowadays, so the form which the user prefers cannot be determined by the
locality. E.G.: AIUI, installation of one browser (of US origin) is, at
least by default, localised to location - which rather annoys monoglot
Americans, and others, resident in various other countries.

The last paragraph of FAQ 2.5 should be reconsidered. Has ECMA 5
fulfilled that hope? Support for what - Internationalisation,
Multinationalisation, or both? it is not clear.

In the fourth paragraph, where does one see a UK setting which is not a
US setting AND no other local setting? If there is no such case, the
"UK" is superfluous.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: www.sexpornnude.com
Next: Send Unlimited Free sms World Wide