Norbert--
Finally had a chance to read this in detail and respond to it. Sorry it too so
long, and sorry I couldn't make it to the last ad-hoc meeting; let's just say
things have been stressful here at work recently. I still haven't had a chance
to look at the minutes from the ad-hoc meeting;
eat. Yehuda Katz had hinted at this but the namespace is so
> polluted I was struggling to find anything official. Where can I go to follow
> this development?
>
>
> Jon Adams
> +1.530.908.1977 • skype: pointlessjon
>
> On Feb 20, 2013, at 11:32, "Gillam, Richar
Wait a minute. I may be misunderstanding here, but all of this discussion
sounds misguided to me.
A Date is intended to represent a specific instance in time, irrespective of
time zone. You don't want to go adding time-zone-related fields to the Date
object. Time zone becomes important when
at 9:18 AM, Joshua Bell wrote:
On Mon, Oct 15, 2012 at 5:51 PM, Gillam, Richard
mailto:gil...@lab126.com>> wrote:
Encoding conversion and detection. Most of the time, text has already been
converted to UTF-16 before it surfaces in JavaScript, so the use cases here
basically all revolve aroun
Hi everybody--
Here are the minutes from the October 5 ES internationalization ad-hoc. Sorry
it took me so long to get them out…
--Rich Gillam
ECMAScript internationalization meeting
10/5/12, 10:20AM
Richard Gillam (invited expert), Nebojša Ćirić (Google), Norbert Lindenberg
(Mozilla), Eric
Pardon my ignorance, but some sort of analogue to Java's ResourceBundle never
makes it onto these lists. Is this out of scope, and if so, is there some sort
of standard, recommended way to get that effect in ECMAScript? If not, I'd say
that's more important than most of the things on this list
Norbert--
>> I tend to think so. It seems like I ought to be able to pass some function
>> the value 0x1d15f and get back a string containing the quarter-note
>> character; otherwise, we're still privileging BMP characters.
>
> Well, the function that does that is String.fromCodePoint(). The q
Norbert--
> 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.
>
>
Commenting on Norbert's comments…
> Rich's comment was on the lack of any version number for ISO 10646, not on
> the Unicode version number. We can simplify the statement in clause 2 to "A
> conforming implementation of this Standard shall interpret characters in
> conformance with the Unicode
Allen--
A few comments on the i18n/Unicode-related stuff in the latest draft:
- p. 1, §2: It seems a little weird here to be specifying a particular version
of the Unicode standard but not of ISO 10646. Down in section 3, you _do_ nail
down the version of 10646 and it's long, so I can see why
I second Norbert's concerns. I think there's something here, but how all this
should work from the standpoint of internationalization isn't fully baked.
--Rich Gillam
Lab126
On Jul 2, 2012, at 8:30 PM, Norbert Lindenberg wrote:
> The quasi-literal proposal discusses at some length text local
Norbert--
> The ECMAScript Internationalization API Specification currently has
> normalization as an optional feature in collation. However, it requires that
> the compare function "return 0 when comparing Strings that are considered
> canonically equivalent by the Unicode standard". Canonical
Early normalization never became a standard? Boy, I've been away from this
stuff for too long… Does this mean that all the other Web standards that were
going to adhere to early normalization do something similar to what you're
proposing? Or do they also "just assume," even though it never be
Norbert--
> 1) The "variant" sensitivity: This name isn't very descriptive. When
> "variant" is selected, a collator has to take all differences between input
> strings into account that it considers at the "case" and "accent" levels; it
> may consider additional differences. … An alternative w
uld be \u10FF followed by
literal FF. A better syntax is \u{...}, with 1 to 6 digits, values from 0 ..
10.
Mark
— Il meglio è l’inimico del bene —
[https://plus.google.com/114199149796022210033]
On Wed, Jan 25, 2012 at 10:59, Gillam, Richard
mailto:gil...@lab126.com>> wrote:
> The cu
> The current 16-bit character strings are sometimes uses to store non-Unicode
> binary data and can be used with non-Unicode character encoding with up to
> 16-bit chars. 21 bits is sufficient for Unicode but perhaps is not enough
> for other useful encodings. 32-bit seems like a plausable uni
> 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. In contrast, the phrase "Unicode character" is used
Nebojša--
My votes, for whatever they may be worth...
1. For LocaleInfo I would like to include construction with plain string:
new LocaleInfo("de") vs more verbose new LocaleInfo({'languageID': 'de'})
One would be able to construct LocaleInfo like this:
LocaleInfo(); - default
LocaleInfo('sr');
Allen--
I tried to post a pointer to this strawman on this list a few weeks ago, but
apparently it didn't reach the list for some reason.
Feed back would be appreciated:
http://wiki.ecmascript.org/doku.php?id=strawman:support_full_unicode_in_strings
I was actually on the committee when the lan
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>
[mailto:es-discuss-boun...@mozilla.org<mailto:es-discu
It seems worth mentioning that this functionality sounds an awful lot like what
MessageFormat does, and MessageFormat was in the i18n strawman (and I have it
in my own i18n implementation). It doesn't seem like we need two different
"formatted string" APIs.
--Rich Gillam
Lab126
On Mar 9, 20
21 matches
Mail list logo
