> >
> > The Date constructor and the functions creating Date instances may accept
> values expressed in the local time zone, but are all specified to calculate a
> time
> value in UTC, which then gets stored in the [[PrimitiveValue]].
>
> To speak to Dean's implications, many of the Date methods
Hello Norbert,
This looks good to me.
Regarding:
> The last one I'm not entirely comfortable with: IANA time zone names can be
> long and unfamiliar (e.g., America/Indiana/Tell_City), and sometimes people
> think the wrong representative city was selected (e.g., Shanghai rather than
> Beijing f
I agree that the tzinfo database and its identifiers should form the basis for
ES time zone support. There are some issues with providing support, such as
that it means that implementers will need to update several times a year (as
time zone rules change).
Setting TimeZone on a Date object migh
Andrea wrote:
--
to sanitize, I would say, is the very first use case where if str.length !=
str.points something might require a fix.
A utf-8 friendly "number of allowed chars", as it would be the twitter case, is
another example.
A split able to represent codePoints rather than chars would ne
One question would be what you’d want that specific number for? The number of
code points in a string is only marginally interesting in a script. It doesn’t,
for example, tell you how many screen positions the text consumes (that’s the
grapheme count).
Norbert’s proposal [1] includes an iterato
You might want to check out Norbert's proposal [1]
Addison
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.
[1]
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html
> -Origin
>
> So yes, I think we can change the spec to set the [[hour12]] internal property
> only if the [[hour]] internal property is present after step 28 of
> InitializeDateTimeFormat. That's similar to how [[currency]] depends on
> [[style]] in InitializeNumberFormat.
>
Looking at the steps involved
x27;t mind
not requiring others to support it (e.g. allowing them to ignore it).
Addison
> -Original Message-
> From: Norbert Lindenberg [mailto:ecmascr...@norbertlindenberg.com]
> Sent: Thursday, August 02, 2012 10:08 PM
> To: Phillips, Addison
> Cc: Norbert Lindenberg; G
> > It's a bit late to add any special handling for these new keys and values to
> edition 1 of the Internationalization API Specification. I propose that for
> edition
> 1 we declare them unsupported:
> >
> > 1) Add "kr" to the list of "not allowed" values in the NOTE in section
> > 10.2.3.
> >
implementation defined.
Addison
> -Original Message-
> From: Norbert Lindenberg [mailto:ecmascr...@norbertlindenberg.com]
> Sent: Sunday, July 15, 2012 9:54 PM
> To: Phillips, Addison
> Cc: Norbert Lindenberg; es-discuss
> Subject: Re: Internationalization: Strings as lo
>
> The result would be that "" is rejected with a RangeError, but "en-US" is
> processed as ["en-US"].
>
Would there be some means of referencing the "root" locale other than using the
empty string?
Also, one means of assigning a locale would be to scrape one or another @lang
attribute in so
I prefer #3.
The problem with #1 is that it's hard to detect--you always get a string back
from the call and you have to inspect the string to find out that you don't
want to display it to the user. Yuck.
Even worse is that the string is localized and the caller can't be certain what
that str
>
> How would Node.js determine the language priority list to return (a) while
> processing an HTTP request, (b) while not? Note that so far ECMAScript knows
> nothing about HTTP...
ES shouldn't care about HTTP. I'm just saying that implementations (which know
something about both) might wish to
>
> I fully agree that an API to obtain the locale list that a browser would send
> to
> the server directly from the browser would be very useful. But since that API
> would be browser specific, I don't think it belongs into an ECMAScript
> specification. Something like window.navigator.acceptLa
A reply to Norbert's reply and a fresh comment.
The fresh comment first:
It would be useful to add addLikelySubtags/removeLikelySubtags from UTS #35
C.10 (http://www.unicode.org/reports/tr35/#Likely_Subtags), which is helpful
when preparing locale lists for use with legacy language tags (e.g. z
A few comments follow.
Addison
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.
On Mar 26, 2012 4:59 PM, "Norbert Lindenberg"
mailto:ecmascr...@norbertlindenberg.com>>
wrote:
While everybody is reviewing the
Comments follow.
1. Definition of string. You say:
--
However,
ECMAScript does not place any restrictions or requirements on the sequence
of code units in a String value, so it may be ill-formed when interpreted
as a UTF-16 code unit sequence.
--
I know what you mean, but others migh
>
> Hi Mark, thanks for this post.
>
> Mark Davis ☕ wrote:
> > UTF-8 represents a code point as 1-4 8-bit code units
>
> "1-6".
No. 1 to *4*. Five and six byte "UTF-8" sequences are illegal and invalid.
>
> > UTF-16 represents a code point as 2 or 4 16-bit code units
>
> "1 or 2".
Yes, 1
Because it has always been possible, it’s difficult to say how many scripts
have transported byte-oriented data by “punning” the data into strings.
Actually, I think this is more likely to be truly binary data rather than text
in some non-Unicode character encoding, but anything is possible, I s
>
> I meant ECMA-262 punts source normalization upstream in the spec pipeline
> that runs parallel to the browser's loading-the-URL | processing-what-was-
> loaded pipeline. ECMA-262 is concerned only with its little slice of
> processing
> heaven.
Yep. One of the problems is that the source scr
>
> Normalization happens to source upstream of the JS engine. Here I'll call on a
> designated Unicode hitter. ;-)
>
I agree that Unicode Normalization shouldn't happen automagically in the JS
engine. I rather doubt that "normalization happens to source upstream of the JS
engine", unless by "
Mark wrote:
First, it would be great to get full Unicode support in JS. I know that's been
a problem for us at Google.
AP> +1: I think we’ve waited for supplementary character support long enough!
Secondly, while I agree with Addison that the approach that Java took is
workable, it does cause
Why would converting the existing UCS-2 support to be UTF-16 not be a good
idea? There is nothing intrinsically wrong that I can see with that approach
and it would be the most compatible with existing scripts, with no special
"modes", "flags", or interactions.
Yes, the complexity of supplemen
that scripters don't
need access to it.
Addison
Sent from my iPhone
On May 17, 2011, at 12:52 PM, "Wes Garland" mailto:w...@page.ca>>
wrote:
On 17 May 2011 15:00, Phillips, Addison
<<mailto:addi...@lab126.com>addi...@lab126.com<mailto:addi...@lab126.com>>
-Brock [mailto:al...@wirfs-brock.com]
> Sent: Tuesday, May 17, 2011 12:16 PM
> To: Phillips, Addison
> Cc: Shawn Steele; Brendan Eich; Boris Zbarsky; es-discuss
> Subject: Re: Full Unicode strings strawman
>
>
> On May 17, 2011, at 12:00 PM, Phillips, Addison wrote:
>
> >
Note: The W3C Internationalization Core WG published a set of "requirements" in
this area for consideration by ES some time ago. It lives here:
http://www.w3.org/International/wiki/JavaScriptInternationalization
The section on 'locale related behavior' is being separately addressed.
I think
> > Personally, I think UTF16 is more prone to error than either UTF8 or
> > UTF32 -- in UTF32 there is a one-to-one correspondence
>
> One-to-one correspondence between string code units and Unicode codepoints.
>
> Unfortunately, "Unicode codepoint" is only a useful concept for some
> scripts..
I didn’t say it was “useless”, only that we had a lower priority for us.
What I trying to say (but didn’t) was that I’m quite happy with this design
compared to what came previously.
Addison
From: Nebojša Ćirić [mailto:c...@google.com]
Sent: Monday, March 28, 2011 2:26 PM
To: Phillips, Addison
useful, but really I don’t see it as a particularly
high priority for us.
Addison
From: Nebojša Ćirić [mailto:c...@google.com]
Sent: Monday, March 28, 2011 1:36 PM
To: Mark Davis ☕
Cc: es-discuss@mozilla.org; Shawn Steele; Phillips, Addison
Subject: Re: Collation API not complete for search
Shawn
Those would be BCP 47 language tags too, though. I guess the question is what
level of support the spec should contain (MUST/SHOULD/MAY support RFC 6067).
Addison
From: Shawn Steele [mailto:shawn.ste...@microsoft.com]
Sent: Friday, March 25, 2011 12:56 PM
To: Phillips, Addison; Nebojša Ćirić
Hi Nebojša,
Some comments follow.
1. “Use Unicode identifier vs. BCP47 in the API” It isn’t clear what you
mean by this. I would strongly prefer that we use BCP 47 identifiers. If you
mean “allow the Unicode locales extension to BCP 47”, I’m fine, but I don’t see
why we would want to us
For grapheme clusters, the use cases are pretty straightforward. Here are a few
right off the top of my head:
- You have a field that is limited in length and you wish to truncate
the text automatically (perhaps appending ellipses). You want to break the text
on a grapheme boundary so
Hi,
I’ve been following this thread carefully this week, thinking to chime in here
or there (but not needing to so far).
Is there a place where updated docs are accumulating? We’re nearly done with
our squirrelfish implementation and I’m getting the feeling that it’s becoming
non-standard ;-).
4. The Collator doesn't include rule-based collation? Is that planned for the
future?
Rule based collation is available for ICU only (as far as I know). We would
need to get into agreement of rule format before we would add it to the API.
And I am not sure there is a high demand for it, so it
Hi,
I reviewed the thread at [1] and wanted to contribute a few comments on the
strawman proposal at [2].
I think this effort is important. Many of us have struggled with the lack of
ready internationalization support within ECMAScript and server-side or custom
processing are both unsatisfyin
35 matches
Mail list logo
