fallback though :)
-Shawn
-Original Message-
From: Norbert Lindenberg [mailto:ecmascr...@lindenbergsoftware.com]
Sent: Saturday, March 2, 2013 11:09 AM
To: Shawn Steele
Cc: Norbert Lindenberg; Dean Landolt; Mark Davis ☕; Eric Albright; es-discuss;
Phillips, Addison
Subject: Re
I still think the stability issue should be addressed in the IANA time zone
database itself, not by adopting a IANA-derived alternate registry. Has that
been tried?
I agree, we should be chatting with the IANA folks.
-Shawn
___
es-discuss
Re: CLDR names being “better” than tzdb names.
I’m uncomfortable using the CLDR names, although perhaps they could be aliases,
because other standards use the tzdb names and we have to be able to look up
the tzdb names. It might be nice to get more stability for the tzdb names,
like aliases
Can we work with iana to get the names stabilized?
Sent from my Windows Phone 8
From: Norbert Lindenbergmailto:ecmascr...@lindenbergsoftware.com
Sent: 3/1/2013 12:41 PM
To: Mark Davis ☕mailto:m...@macchiato.com
Cc: Shawn Steelemailto:shawn.ste...@microsoft.com;
For #5 I might prefer falling back to English or something. I don't think UTC
offset is a good idea because that doesn't really represent a Timezone very
well. (If a meeting gets moved to a following week, that offset might change
or be wrong)
-Shawn
-Original Message-
From:
things the
developer thinks works.
Assuming a use case for illegal unicode were ever found, it could be added
later.
-Shawn
-Original Message-
From: Norbert Lindenberg [mailto:ecmascr...@norbertlindenberg.com]
Sent: Monday, January 14, 2013 4:35 PM
To: Shawn Steele
Cc: Norbert
IMO String.fromCodePoint should disallow U+D800-U+DFFF.
There's already fromCharCode that does that, and a according to The Unicode
Standard, isolated surrogates have no meaning on their own and goes on to
compare them to illegal UTF-8 sequences. IMO CodePoint is a 21 Unicode code
point, and
...@norbertlindenberg.com]
Sent: Wednesday, December 12, 2012 2:40 PM
To: Shawn Steele
Cc: Norbert Lindenberg; Erik Arvidsson; es-discuss@mozilla.org
Subject: Re: String.fromCodePoint and surrogate pairs?
The Unicode standard defines code point as any value in the range of integers
from 0
I sort of have a fundamental problem with the solution. Eg: If it were
actually unused, it'd be GC'd. Since it isn't GC'd, something must be holding
a reference to it. So if you force it to be gone, or clear all the properties,
or whatever, seems to me that then you'd just start throwing
On the contrary, TypeError: Cannot read property 'prop' of undefined, with
a stack trace, is WAY easier to track down than The RSS on my server
gradually rises, until the operating system kills it, which happens about
every 4 hours.
I'm not so sure. Now you know where you're using it that
[mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Norbert Lindenberg
Sent: Monday, November 28, 2011 5:30 PM
To: Eric Albright; Peter Constable; Shawn Steele
Cc: es-discuss
Subject: Re: Globalization API: supportedLocalesOf vs. getSupportedLocales
We invented the supportedLocalesOf method to let
- Java kept their strings encoded exactly as they were (a sequence of
16-bit code units) and provided extra APIs for the cases where you want to
extract a code point.
Bloaty.
? defining UTF-16 instead of UCS-2 introduces zero bloat. In fact, it pretty
much works anyway, it's just not
The crucial win of Allen's proposal comes down the road, when someone in a
certain locale *can* do s.indexOf(nonBMPChar) and win.
s.indexOf(\U+1),
Ok, but \U+... does not work today.
Yes, that would be worth adding (IMO) as a convenience, regardless of whether
the backend were UTF-16
I don’t have time to make a real strawman, but what would people need if we
went the UTF-16 route (instead of full-Unicode)? (This thread is to collect
requirements, which are somewhat getting lost in the merits of UTF-16 vs 32 bit
thread). Basically, just replace UCS-2 with UTF-16, allowing
There are several sequences in Unicode which are meaningless if you have only
one character and not the other. Eg: any of the variation selectors by
themselves are meaningless. So if you break a modified character from its
variation selector you've damaged the string. That's pretty much
, mayo 19, 2011 3:00 PM
To: Shawn Steele
Cc: Waldemar Horwat; es-discuss@mozilla.org; Peter Constable
Subject: Re: Full Unicode strings strawman
On May 19, 2011, at 2:06 PM, Shawn Steele wrote:
There are several sequences in Unicode which are meaningless if you have only
one character
Hmm... I proposed break iterators for 'character/grapheme', word, line
and sentence as a part of i18n API, but it's shot down (at least for
version
0.5). Are you open to adding them now ? Once this discussion is settled and
the proposal to support the full unicode range is in place, we can
I would much prefer changing UCS-2 to UTF-16, thus formalizing that
surrogate pairs are permitted. That'd be very difficult to break any existing
code and would still allow representation of everything reasonable in Unicode.
That would enable Unicode, and allow extending string literals and
Right - but they are still legitimate code points, and they fill out the
space required to let us treat String as uint16[] when defining the backing
store as something that maps to the set of all Unicode code points.
That said, you can encode these code points with utf-8; for example,
Thanks for making a strawman
Unicode Escape Sequences
Is it possible for U+ to accept either 4, 5, or 6 digit sequences? Typically
when I encounter U+ notation the leading zero is omitted, and I see BMP
characters quite often. Obviously BMP could use the U notation, however it
seems like
, 2011 12:53 PM
To: Shawn Steele
Cc: es-discuss@mozilla.org
Subject: Re: Full Unicode strings strawman
On May 16, 2011, at 11:34 AM, Shawn Steele wrote:
Thanks for making a strawman
(see my very last sentence below as it may impact the interpreation of some of
the rest of these responses
to match, as the return
value of [[Get]] would be a code point.
Shawn Steele, I don't understand this comment:
Also, the “trick” I think, is encoding to surrogate pairs (illegally, since
UTF8 doesn’t allow that) vs decoding to UTF16.
Why do we care about the UTF-16 representation of particular
PM
To: Shawn Steele
Cc: Jungshik Shin (신정식, 申政湜); Markus Scherer; es-discuss@mozilla.org
Subject: Re: Full Unicode strings strawman
In terms of implementation capabilities, there isn't really a significant
practical difference between
* a UCS-2 implementation, and
* a UTF-16
The problem is that “\UD800\UDC00” === “\U+01”. And if the internal
representation is UTF-32, then they’d have to continue to be the same. And
it’s really hard for them to have the same length if one’s 2 code points and
the other’s 1 code point.
-Shawn
From:
Not in my proposal! \ud800\udc00=== \u+01 is false in my proposal.
That’s exactly my problem. I think the engine’s (or at least the applications
written in JavaScript) are still UTF-16-centric and that they’ll have d800,
dc00 === 1. For example, if they were different, then d800,
I think you'll find that the actual JS engines are currently UCS-2 centric.
The surrounding browser environments are doing the UTF-16 interpretation.
That why you see instead of �� in browser generated display output.
There’s no difference. I wouldn’t call Windows C++ WCHAR “UCS-2”, however
expect comparison to match that substring. Similarly, if one
is using Turkish I, we expect all of them to do so.
- Shawn
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
, but, likely, fuzzy and
exact ideas are still useful.
- Shawn
From: Nebojša Ćirić [mailto:c...@google.com]
Sent: Monday, March 28, 2011 2:26 PM
To: Phillips, Addison
Cc: Mark Davis ☕; es-discuss@mozilla.org; Shawn Steele
Subject: Re: Collation API not complete for search
How do you solve search
Yes, sort, comparison and in-text search seem like reasonable buckets to me.
Although in-text can further be broken into, I think, exact and non-exact cases.
- Shawn
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Axel
I think we meant allowing the -u extensions for, at least, collation variants.
- Shawn
http://blogs.msdn.com/shawnste
Selfhost a custom locale from
\\scratch2\scratch\shawnste\customlocaledrop\install.batfile:///\\scratch2\scratch\shawnste\customlocaledrop\install.bat
(Selfhost
PM
To: Shawn Steele; Nebojša Ćirić; es-discuss@mozilla.org
Subject: RE: Summary of i18n ad hoc group meeting - 21st March 2011
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
There was a tiny bit of discussion around scientific notation and number
formatting a while back. I thought this included some comments around
globalization differences between cultures on how scientific notation worked.
Does anyone have any examples of such differences?
Thanks,
- Shawn
I would postpone any formatting stuff until the i18n stuff was better
understood.
- Shawn
http://blogs.msdn.com/shawnste
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Gillam, Richard
Sent: Wednesday, March 09,
-discuss-boun...@mozilla.org] on behalf
of Erik Corry [erik.co...@gmail.com]
Sent: Sunday, January 30, 2011 12:32 AM
To: Mark Davis ☕
Cc: Mads Ager; Shawn Steele; es-discuss@mozilla.org
Subject: Re: Stupid i18n use cases question
On Jan 29, 2011 8:37 PM, Mark Davis ☕
m...@macchiato.commailto:m
Names of the locales? (We seem to be digressing somewhat).
Downloading the code too is how jQuery's i18n works.
-Shawn
http://blogs.msdn.com/shawnste
From: Erik Corry [erik.co...@gmail.com]
Sent: Sunday, January 30, 2011 10:48 AM
To: Shawn Steele
On the phone yesterday we mentioned word/line breaking and grapheme clusters.
It didn't occur to me to ask about the use cases.
Why does someone need word/line breaking in js? It seems like that would
better be done by my rendering engine, like the HTML layout engine or my edit
control or
] on behalf
of Phillips, Addison [addi...@lab126.com]
Sent: Saturday, January 29, 2011 4:19 PM
To: Mark Davis ☕; Shawn Steele
Cc: es-discuss@mozilla.org
Subject: RE: Stupid i18n use cases question
...
For line breaking, the main thing would be to preformat some text. We (the
Lab126 we) use line and word
problems for you.
-Shawn
http://blogs.msdn.com/shawnste
From: Phillips, Addison [addi...@lab126.com]
Sent: Tuesday, January 25, 2011 10:09 PM
To: Shawn Steele; Mark Davis ☕
Cc: es-discuss@mozilla.org; Gillam, Richard
Subject: RE: i18n objects
Hi,
I’ve
My understanding of “inferred” values for the LocaleInfo object is that, when
inferred is allowed/used, that values which are not explicitly specified in the
constructor (eg: calendar), will be inferred as best as possible from the other
inputs.
For example: If I construct it with:
var
that it creates it the way it
intends.
-Shawn
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Mark Davis ?
Sent: Monday, January 24, 2011 4:09 PM
To: Shawn Steele
Cc: es-discuss@mozilla.org
Subject: Re: i18n objects
I don't understand.
* If you want
?
Mark
— Il meglio è l’inimico del bene —
On Mon, Jan 24, 2011 at 15:53, Shawn Steele
shawn.ste...@microsoft.commailto:shawn.ste...@microsoft.com wrote:
But assume I have a “black-box” API that prints a report or something.
If the caller correctly sets the LocaleInfo() for inferred or not inferred
IMO that’s going overboard in the other direction ☺ It’d be nice to find some
middle ground.
Sometimes inferring can be very bad. Sometimes it can be very good. The
problem isn’t that one is “right” or “wrong” for all apps, but rather that it
might be simple for developers to accidentally
infer” in the input options would help avoid
accidentally not making a choice, yet still making it fairly easy to use.
-Shawn
From: mark.edward.da...@gmail.com [mailto:mark.edward.da...@gmail.com] On
Behalf Of Mark Davis ?
Sent: Friday, January 21, 2011 4:01 PM
To: Shawn Steele
Cc: Axel Hecht
The i18n group said we’d figure out collator options by email. This is an
email ☺
First I’d like to say something about the scope of collator’s in EcmaScript: I
don’t think it’s reasonable to write a database in Javascript. I think people
should instead use a database engine in some form,
Forwarding for Mark
From: mark.edward.da...@gmail.com [mailto:mark.edward.da...@gmail.com] On
Behalf Of Mark Davis ?
Sent: Poʻahā, Ianuali 20, 2011 4:05 hours
To: Shawn Steele
Cc: es-discuss@mozilla.org; Peter Constable; Derek Murman
Subject: Re: i18n collator options
(BTW I haven't gotten
For UTF-16 order do you use like the Turkish casing if it was a turkish locale?
-Shawn
From: mark.edward.da...@gmail.com [mailto:mark.edward.da...@gmail.com] On
Behalf Of Mark Davis ?
Sent: Poʻahā, Ianuali 20, 2011 4:05 hours
To: Shawn Steele
Cc: es-discuss@mozilla.org; Peter Constable; Derek
The list didn’t like my email address…, trying again.
From: Shawn Steele
Sent: Poʻakolu, Ianuali 19, 2011 6:12 hours
To: 'Nebojša Ćirić'; es-discuss@mozilla.org
Subject: RE: 2nd day meeting comments on the latest i18n API proposal
I think a “common” case is to tweak a part of a LocaleInfo object
47 matches
Mail list logo
