On Mar 23, 2012, at 6:30 , Steven Levithan wrote:
> Norbert Lindenberg wrote:
>
>> I've updated the proposal based on the feedback received so far. Changes
>> are listed in the Updates section.
>> http://norbertlindenberg.com/2012/03/ecmascript-supplementary-charact
I've updated the proposal based on the feedback received so far. Changes are
listed in the Updates section.
http://norbertlindenberg.com/2012/03/ecmascript-supplementary-characters/
Norbert
On Mar 16, 2012, at 0:18 , Norbert Lindenberg wrote:
> Based on my prioritization of goals for
On Mar 17, 2012, at 11:58 , Erik Corry wrote:
> 2012/3/17 Steven L. :
>> I further objected because I think the /u flag would be better used as a
>> ASCII/Unicode mode switcher for \d\w\b. My proposal for this is based on
>> Python's re.UNICODE or (?u) flag, which does the same thing except that i
e dot does.
>
>> From Perl, PCRE, .NET, Java, XML Schema, and ICU (among others):
>>
>> \P{M}\p{M}*
>>
>> Obviously \X is prettier, but because it's fairly rare for people to care
>> about this, IMO the more widely compatible solution that use
Steven, sorry, I wasn't aware of your proposal for /u when I inserted the note
on this flag into my proposal. My proposal was inspired by the use of /u in
PHP, where it switches from byte mode to UTF-8 mode. We'll have to see whether
it makes sense to combine the two under one flag or use two -
On Mar 16, 2012, at 19:57 , Erik Corry wrote:
> 2012/3/17 Norbert Lindenberg :
>> Thanks for your comments - a few replies below.
>>
>> Norbert
>>
>>
>> On Mar 16, 2012, at 1:55 , Erik Corry wrote:
>>
>>> However I think we probably do
In Harmony we should be able to make this even more beautiful using iterators
[1]:
If we add:
String.prototype.[iterator] = function() {
var s = this;
return {
index: 0,
next: function() {
if (this.index >= s.length) {
throw StopIteration;
u does not consist of a single character, return
ch." in the Canonicalize algorithm in ES 5.1).
> 2012/3/16 Norbert Lindenberg :
>> Based on my prioritization of goals for support for full Unicode in
>> ECMAScript [1], I've put together a proposal for supporting the f
Based on my prioritization of goals for support for full Unicode in ECMAScript
[1], I've put together a proposal for supporting the full Unicode character set
based on the existing representation of text in ECMAScript using UTF-16 code
unit sequences:
http://norbertlindenberg.com/2012/03/ecmascr
Thanks, Luke, for bringing this up again and doing all the research!
In the ECMAScript Internationalization API specification draft [1], which we
expect to be implemented on top of libraries with good time zone support, we
tried to address this issue. The description of the abstract operation
T
Comments:
1) In terms of the prioritization I suggested a few days ago
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020721.html
it seems you're considering item 6 essential, item 1 a side effect (whose
consequences are not mentioned - see below), items 2-5 nice to have. Do I
under
To make it easier to review the ECMAScript Internationalization API
Specification, I also updated my guide to the API:
http://norbertlindenberg.com/2012/02/ecmascript-internationalization-api/index.html
Norbert
On Feb 24, 2012, at 0:11 , Norbert Lindenberg wrote:
> The 23 February 2
The 23 February 2012 working draft of the ECMAScript Internationalization API
Specification is available at
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
Along with the name change from Globalization API back to Internationalization
API, the namespace has changed from
Second part: the BRS.
I'm wondering how development and deployment of existing full-Unicode software
will play out in the presence of a Big Red Switch. Maybe I'm blind and there
are ways to simplify the process, but this is how I imagine it.
Let's start with a bit of code that currently support
I'll reply to Brendan's proposal in two parts: first about the goals for
supplementary character support, second about the BRS.
> Full 21-bit Unicode support means all of:
>
> * indexing by characters, not uint16 storage units;
> * counting length as one greater than the last index; and
> * supp
As Brendan's link indicates, JSON is specified by RFC 4627, not by the
ECMAScript Language Specification. JSON is widely used for data exchange with
and between systems that have nothing to do with ECMAScript and the proposed
BRS - see the middle section of
http://www.json.org/
So the only thin
No. The intent here is to strip out the Unicode extension subsequence because
it's always negotiated separately in this library and the fallback of the
Lookup algorithm doesn't make sense for it. Private use extensions are treated
as normal parts of the language tag with the normal fallback beha
We expect ['sr-Latn-RS']. The idea was that applications can find out which of
the locales that they (or their users) request are supported across different
services.
An API to return actually supported locales would likely look different.
Norbert
On Feb 8, 2012, at 15:58 , Nebojša Ćirić wrot
The current specification of the ECMAScript Globalization API requires the
prototype objects for the LocaleList, Collator, NumberFormat, and
DateTimeFormat constructors to be objects constructed by these constructors
themselves. This is following a pattern established in the ECMAScript Language
Following up on Nebojša's summary, I'd like to
- Rename the namespace object of the Globalization API from "Globalization" to
"Intl".
- Then rename the API itself from "Globalization API" back to
"Internationalization API".
I searched a bit and found indications that the global "Globalization" m
't changed those functions.
Norbert
On Feb 1, 2012, at 8:59 , Allen Wirfs-Brock wrote:
>
> On Jan 31, 2012, at 4:23 PM, Nebojša Ćirić wrote:
>
>> 31. јануар 2012. 15.50, Norbert Lindenberg
>> је написао/ла:
>> I can imagine doing this for Collator.prototype.compar
I can imagine doing this for Collator.prototype.compare because
Array.prototype.sort is such a common use case for it, but why for the format()
methods? We don't want to impose the overhead of creating a bound function on
each call to format() unless there's a good reason...
Of course, doing it
I don't see the standard allowing character encodings other than UTF-16 in
strings. Section 8.4 says "When a String contains actual textual data, each
element is considered to be a single UTF-16 code unit." This aligns with other
normative references to UTF-16 in sections 2, 6, and 15.1.3. Secti
I'd agree that Jed is an internationalization library. Code that enables
localization to me is internationalization. But the
internationalization/localization/globalization community speaks a number of
different dialects...
The current spec of the proposed ECMAScript Globalization API is at:
ht
Hi Alex,
Comments inline.
Cheers,
Norbert
On Jan 23, 2012, at 17:14 , Alex Sexton wrote:
> A few questions inline. I'd love to continue to improve Jed to the point
> where it can handle the problems that you've outlined.
>
> On Mon, Jan 23, 2012 at 6:57 PM, Norber
Well, Jed does a little more than you give it credit for, but there's still no
real overlap.
Jed provides the following functionality:
- an incomplete implementation of resource loading (no language negotiation, no
I/O, only dictionary lookup),
- an incomplete implementation of plural handling (
But time zones other than UTC and the "host environment's current time zone"
are not supported. This limitation exists in version 1 of the API spec because
one implementation currently doesn't support other time zones. We hope that in
the next version this limitation can be removed and all IANA
We use es-discuss@, with "globalization" or "internationalization" as part of
the subject line to help us pick out internationalization-related messages from
the daily flood.
Looking forward to your feedback,
Norbert
On Jan 18, 2012, at 11:39 , Oliver Hunt wrote:
> Ah, where is the new locati
hould be sensitive to
minor differences such as accents. See
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
http://norbertlindenberg.com/2011/11/ecmascript-globalization-api/index.html
Norbert
On Jan 17, 2012, at 4:06 , Herby Vojčík wrote:
>
>
> Norbert Li
This message includes strawman proposals for
(a) a simplified pattern syntax and
(b) simple style specifiers
for DateTimeFormat objects, which can replace the current format specification
through nine separate properties for the components of formatted date and time.
Several people have recently
I can't find a specification for Object.system.load - does it return a
reference to a single globally shared object representing the module, or does
it return a new object that contains the exported functions/items of the module?
In the first case, I'd assume the object returned is immutable for
A few comments below.
Norbert
On Dec 8, 2011, at 10:25 , Nebojša Ćirić wrote:
> There are couple of threads going on and I wanted to wrap up current state
> before the holidays...
>
> API:
> 1. Use built in toLocaleString family of methods in simple, functional case*
> 2. Use Globalization
I don't think a standalone pattern string is sufficient - the pattern doesn't
encode all information that the DateTimeFormat needs. In this version of the
API, we need at least the timeZone option, in a later version probably also a
calendar option.
Norbert
On Dec 6, 2011, at 11:42 , Nicholas
Nothing planned at this point. Unicode normalization would be a natural
candidate for the Globalization API, but it's not in scope for version 1.
Support for Unicode character properties probably should be part of regular
expressions, as it is in Perl, PHP, Java, and other platforms; there was a
The December 1, 2011 draft is available at
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
This draft adds re-specifications of locale sensitive methods in the ECMAScript
Language Specification (localeCompare, toLocaleString, etc.), adds
implementation dependent best fi
to only English, but someone uploaded
> French content, does that count?
>
> -Shawn
>
> -Original Message-
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
> On Behalf Of Norbert Lindenberg
> Sent: Monday, November 28, 2011 5:30 PM
> To: Eric
We invented the supportedLocalesOf method to let applications find out which of
its requested locales are supported by the implementation of a service. A
getSupportedLocales function that simply returns the locales that the
implementation actually supports would be easier to understand, and coul
idering the most
>> complex use cases instead of the most common.
>>
>> It is my opinion (and I can only speak for myself) that a single object to
>> encompass would represent a better API for JavaScript than adding a
>> namespace, which hasn't been done to this point, and
Sounds like RangeError is the one to use for the Globalization API. If I don't
hear objections, I'll remove ValueError from the spec, replace its uses with
RangeError, and file a ticket against the language specification to have the
word "numeric" removed from the description of RangeError.
Tha
Looking at the feedback we've received on the Globalization API, it seems at
least some of it is based on divergent assumptions about the developers who are
going to use the API. Maybe we should step back and define the different
developer groups we want to serve. Here's a first cut:
1: Develop
I didn't agree with this approach, and Nicholas didn't claim that I did :-)
I'm very glad though that Nicholas is taking the time to provide feedback, come
up with his own ideas, and discuss them with us. In the end, the Globalization
API can only be successful if people like him are comfortable
At last week's TC39 meeting, I asked which error objects an API should throw
when it expects a string matching a specific pattern, but receives a string
that doesn't match the pattern. Examples in the Globalization API are language
tags, as defined in RFC 5646, or selectors such as "sort" and "s
rs Gregorian instead, the application may load a library
that does support Islamic.
Norbert
On Nov 20, 2011, at 9:59 , Brendan Eich wrote:
> On Nov 19, 2011, at 7:27 PM, Norbert Lindenberg wrote:
>
>>>> 2.a. Find out if there were fallbacks through object state
>>>
>&g
Thanks for the clarification - this helps.
I think however that the constructors of the Globalization API handle this
correctly in most cases. The specs for the cases where the options object is
not provided (sections /(8|9|10).2.(2|3)/), say the constructors behave as if
they had received a mi
Comments below.
Norbert
On Nov 18, 2011, at 16:06 , Brendan Eich wrote:
> On Nov 18, 2011, at 2:17 PM, Nebojša Ćirić wrote:
>
>> 2. Do we keep original API (new DateTimeFormat(), and its methods) as an
>> alternative that would let user:
I think yes.
>> 2.a. Find out if there were fallback
1. 13.16, Erik Arvidsson је
> написао/ла:
> On Fri, Nov 18, 2011 at 12:41, Norbert Lindenberg
> wrote:
> > With that, the first example would become:
> >
> > var price = 300,
> >currency = price.toLocaleString(localeList, {style: "currency",
> >
Thanks for the clarification. Let's see what we can do to reduce object
creation.
At the TC 39 meeting, we seemed to have agreement that it's OK for the
Globalization specification to respecify the existing *Locale* methods, as
proposed here:
http://wiki.ecmascript.org/doku.php?id=strawman:glob
Hi Luke,
For String.prototype.toArray, I didn't propose different behavior. The part of
my message that you omitted continues "The function should be named to clearly
indicate that it returns an array of UTF-16 code units. This also allows us to
offer a parallel function that returns an array o
Fortunately we dropped reverse in the TC 39 meeting yesterday - nobody had an
idea who would use it.
I brought up combining character sequences as a concern for the other proposed
functions (startsWith etc.). There the majority opinion was that the model of
the existing String functions, ignori
,
Norbert
On Nov 10, 2011, at 22:42 , Norbert Lindenberg wrote:
> A guide and background article is now available:
> http://norbertlindenberg.com/2011/11/ecmascript-globalization-api/index.html
>
> Regards,
> Norbert
>
>
> On Nov 2, 2011, at 0:10 , Norbert Lindenberg wrote:
Hi Luke,
A few comments on the proposed String functions:
1) String.prototype.reverse(), as proposed, corrupts supplementary characters.
Clause 6 of Ecma-262 redefines the word "character" as "a 16-bit unsigned value
used to represent a single 16-bit unit of text", that is, a UTF-16 code unit.
A guide and background article is now available:
http://norbertlindenberg.com/2011/11/ecmascript-globalization-api/index.html
Regards,
Norbert
On Nov 2, 2011, at 0:10 , Norbert Lindenberg wrote:
> A working draft of the ECMAScript Globalization API Specification for review
> at the No
A working draft of the ECMAScript Globalization API Specification for review at
the November TC 39 meeting is available at
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
There are still a number of open issues, and the algorithms still need
significant work, but the in
Nicholas, Andrea, Rick,
Thanks for your feedback. A few replies:
Why DateTimeFormat and NumberFormat as separate object types rather than
methods on Date.prototype and Number.prototype: I suspect Conway's Law played a
bit of a role here - an ad hoc team was chartered by TC 39 with developing a
A few additional comments below.
Best regards,
Norbert
>> 4. Comments show the desire for a Globalization namespace, what is the
>> reason for this? Why not hang the services off objects that have the
>> desired functoin, such as String.collator (or 'new String.Collator()'),
>> Date.format,
The specification of String.prototype.toLowerCase in ES 5.1 (which is also
referenced in String.prototype.toUpperCase) refers to the Unicode character
database for case mappings, explicitly including "not only the UnicodeData.txt
file, but also the SpecialCasings.txt file that accompanies it in
The current specs for the NumberFormat and DateTimeFormat constructors in the
ECMAScript internationalization API provide for 3 (NumberFormat) or 2
(DateTimeFormat) different ways to specify the desired formats: using style
properties, using skeleton properties, and (for NumberFormat) using patt
I thought it would be useful to convert the results of our discussion on
2011-07-26 into spec language and see how it holds up. In the process I found
and filled several gaps, made a few changes, and noted various issues. The
result, so far limited to NumberFormat and its prerequisites, is here:
ave comments on some of these.
>
> Mark
> — Il meglio è l’inimico del bene —
>
>
> On Tue, Jul 19, 2011 at 01:29, Norbert Lindenberg
> wrote:
>> Hi all,
>>
>> I'm sorry for not having been able to contribute to the internationalization
>> API earli
Hi all,
I'm sorry for not having been able to contribute to the internationalization
API earlier. I finally have reviewed the straw man [1], and am pleased to see
that it contains a good subset of internationalization functionality to start
with. Number and date formatting and collation are iss
I have read the discussion so far, but would like to come back to the
strawman itself because I believe that it starts with a problem
statement that's incorrect and misleading the discussion. Correctly
describing the current situation would help in the discussion of
possible changes, in par
201 - 261 of 261 matches
Mail list logo
