I'm working on a document discussing the issues and possible solutions,
including some that haven't come up in the discussion yet. This will hopefully
provide a basis for further discussion and decision.
Thanks,
Norbert
On Dec 20, 2012, at 5:42 , Gervase Markham wrote:
> On 03/12/12 19:32, No
On 03/12/12 19:32, Norbert Lindenberg wrote:
As part of implementing the ECMAScript Internationalization API [1,
2] in SpiderMonkey, and as an aid in internationalizing other
functionality in Mozilla products [3], I need to integrate the ICU
library (International Components for Unicode [4]) into
Robert O'Callahan a écrit :
Often, the OS support for a particular
language is really terrible and we can and should do better even if it
means being inconsistent with the OS. This is certainly true for the case
of font shaping, for example.
I've seen the references to font shaping in the start
On Thu, Dec 13, 2012 at 6:10 AM, Jean-Marc Desperrier wrote:
> Knowing that in most cases you will be reimplementing in parallel the
> support the user has added to the OS so that native application can get it.
> And doing it in parallel means never doing it perfectly the same way.
This argument
Norbert Lindenberg a écrit :
This is really basic infrastructure that for native applications is
provided by the OS and for web applications should be provided by the
browser.
And why do you set the aim for the web application to be able to do what
the native application next to it will be una
Axel Hecht a écrit :
Additionally, quite a few users are multilingual. If I look at en-US
usage, only half of that is within the US, followed by India and Indonesia.
Also, OS support usually means support for the language the OS is
running in, not the language we use for Firefox.
Bi-lingual, no
On Mon 10 Dec 2012 08:37:08 AM PST, Benjamin Smedberg wrote:
On 12/7/2012 4:39 PM, Norbert Lindenberg wrote:
This is really basic infrastructure that for native applications is
provided by the OS and for web applications should be provided by the
browser.
We still need to weigh the cost of this
On 12/7/2012 4:39 PM, Norbert Lindenberg wrote:
On Dec 7, 2012, at 6:18 , Benjamin Smedberg wrote:
On 12/6/2012 9:21 PM, Norbert Lindenberg wrote:
The benefit is that the ECMAScript Internationalization API lets developers
create a more consistent localized experience for their users, with th
On 07/12/12 02:21, Norbert Lindenberg wrote:
The benefit is that the ECMAScript Internationalization API lets
developers create a more consistent localized experience for their
users, with the correct
* date time, and number formats,
* the culturally appropriate calendar,
* correct currency sym
On 07/12/12 12:33, Jonathan Kew wrote:
This is somewhat analogous to the solution (proposed and prototyped in
bug 619521 and bug 648548) to provide downloaded-on-demand fonts to
extend the character coverage when the device lacks any preinstalled
fonts for a given script/writing system.
And we
On 08/12/12 20:40, Asa Dotzler wrote:
On 12/6/2012 6:25 PM, Norbert Lindenberg wrote:
Google Chrome is bundling ICU, so they're not limited by what's on
the device.
How much does this bundling add to the Google Chrome download size.
Presumably someone can compile/package Chromium with and wit
On 12/6/2012 6:25 PM, Norbert Lindenberg wrote:
Google Chrome is bundling ICU, so they're not limited by what's on the device.
How much does this bundling add to the Google Chrome download size.
Presumably someone can compile/package Chromium with and without or
compare the size of the build
Jean-Marc Desperrier wrote:
> ICU is a massive, huge juggernaut. It fits the bill in professional
> application that have no download size constraints, and no
> requirement to support the low end of installed memory size. OS
> support is incredibly more efficient.
Jean-Marc, I don't agree with eve
On Dec 7, 2012, at 6:18 , Benjamin Smedberg wrote:
> On 12/6/2012 9:21 PM, Norbert Lindenberg wrote:
>> The benefit is that the ECMAScript Internationalization API lets developers
>> create a more consistent localized experience for their users, with the
>> correct date, time, and number formats
On 2012-12-06 10:11 PM, Chris Peterson wrote:
For example, someone who downloads Firefox's Portuguese build is
probably interested in ECMAScript internationalization, but only as it
pertains to Portuguese.
There is nothing special about a Portuguese build compared to, let's
say, an English US
On 12/6/2012 9:21 PM, Norbert Lindenberg wrote:
The benefit is that the ECMAScript Internationalization API lets developers
create a more consistent localized experience for their users, with the correct
date, time, and number formats, the culturally appropriate calendar, correct
currency symb
On 7/12/12 03:35, Robert O'Callahan wrote:
On Fri, Dec 7, 2012 at 4:25 PM, Robert O'Callahan wrote:
On Fri, Dec 7, 2012 at 4:08 PM, Norbert Lindenberg <
mozillali...@lindenbergsoftware.com> wrote:
This sounds like non-trivial surgery on ICU. Yes, the APIs are
synchronous. And we don't know wh
On Fri, Dec 7, 2012 at 5:11 AM, Chris Peterson wrote:
> Can the ICU data be split by locale and bundled with the localized Firefox
> builds?
>
> For example, someone who downloads Firefox's Portuguese build is probably
> interested in ECMAScript internationalization, but only as it pertains to
> P
On Fri, Dec 7, 2012 at 4:25 PM, Robert O'Callahan wrote:
> On Fri, Dec 7, 2012 at 4:08 PM, Norbert Lindenberg <
> mozillali...@lindenbergsoftware.com> wrote:
>
>> This sounds like non-trivial surgery on ICU. Yes, the APIs are
>> synchronous. And we don't know whether the time when a user stumbles
On Fri, Dec 7, 2012 at 4:08 PM, Norbert Lindenberg <
mozillali...@lindenbergsoftware.com> wrote:
> This sounds like non-trivial surgery on ICU. Yes, the APIs are
> synchronous. And we don't know whether the time when a user stumbles onto a
> Chinese web page that requests Chinese collation is real
On 12/6/12 6:36 PM, Robert O'Callahan wrote:
How hard would it be to incrementally download data for the locales we need?
It seems that most users won't ever need the collation tables for Chinese,
for example. If we could figure out a way to make them available
just-in-time, that could be a win.
On Dec 6, 2012, at 18:36 , Robert O'Callahan wrote:
> How hard would it be to incrementally download data for the locales we need?
>
> It seems that most users won't ever need the collation tables for Chinese,
> for example. If we could figure out a way to make them available
> just-in-time, that
How hard would it be to incrementally download data for the locales we need?
It seems that most users won't ever need the collation tables for Chinese,
for example. If we could figure out a way to make them available
just-in-time, that could be a win.
I assume the relevant APIs are synchronous, s
On Dec 6, 2012, at 16:33 , Axel Hecht wrote:
> On 07.12.12 01:08, Asa Dotzler wrote:
>> On 12/3/2012 2:39 PM, Norbert Lindenberg wrote:
>>> Well, the first question is what size increase would be acceptable
>>> given the benefits that ICU provides.
>>
>> I don't understand what benefits this actu
On Dec 6, 2012, at 16:08 , Asa Dotzler wrote:
> On 12/3/2012 2:39 PM, Norbert Lindenberg wrote:
>> Well, the first question is what size increase would be acceptable
>> given the benefits that ICU provides.
>
> I don't understand what benefits this actually provides. How are users'
> online live
On 07.12.12 01:08, Asa Dotzler wrote:
On 12/3/2012 2:39 PM, Norbert Lindenberg wrote:
Well, the first question is what size increase would be acceptable
given the benefits that ICU provides.
I don't understand what benefits this actually provides. How are users'
online lives improved by this c
On 12/3/2012 2:39 PM, Norbert Lindenberg wrote:
Well, the first question is what size increase would be acceptable
given the benefits that ICU provides.
I don't understand what benefits this actually provides. How are users'
online lives improved by this change, either today or in the future?
This thread has got off-topic (reasonably; the new issues are important)
but back on the original point, if we do add ICU then:
On 03/12/12 11:32, Norbert Lindenberg wrote:
- Add the required set of ICU source files as separate files to the
Mozilla repository. The current version of ICU (50.1,
On 12/5/2012 8:07 AM, Benjamin Smedberg wrote:
On 12/3/2012 5:39 PM, Norbert Lindenberg wrote:
OK, just as an introduction, why we're doing this: The ECMAScript
Internationalization API (which has been approved by Ecma TC 39 and
is on track to become an Ecma standard next week) provides web
ap
On 05.12.12 17:07, Benjamin Smedberg wrote:
On 12/3/2012 5:39 PM, Norbert Lindenberg wrote:
OK, just as an introduction, why we're doing this: The ECMAScript
Internationalization API (which has been approved by Ecma TC 39 and is
on track to become an Ecma standard next week) provides web
applica
On 12/3/2012 5:39 PM, Norbert Lindenberg wrote:
OK, just as an introduction, why we're doing this: The ECMAScript
Internationalization API (which has been approved by Ecma TC 39 and is on track
to become an Ecma standard next week) provides web applications with the
ability to format numbers,
Mike Hommey wrote:
> On Tue, Dec 04, 2012 at 07:51:21AM -0500, Justin Wood (Callek) wrote:
>> Rafael Ávila de Espíndola wrote:
Actually, ICU has several options for how its data is packaged. One option
is libraries (which are not sharable between architectures, AFAIK), but
ano
On Tue, Dec 04, 2012 at 07:51:21AM -0500, Justin Wood (Callek) wrote:
> Rafael Ávila de Espíndola wrote:
> >>
> >> Actually, ICU has several options for how its data is packaged. One option
> >> is libraries (which are not sharable between architectures, AFAIK), but
> >> another possibility is to
On Tue, Dec 4, 2012 at 6:15 AM, Makoto Kato wrote:
> A year ago, I investigated to replace uconv with ICU.
>
> Many (most is IBM code page) converters in ICU isn't compatible with uconv,
> and ICU isn't have all character set converters that we already use in
> uconv.
>
> If using ICU for uconv, w
Rafael Ávila de Espíndola wrote:
>>
>> Actually, ICU has several options for how its data is packaged. One option
>> is libraries (which are not sharable between architectures, AFAIK), but
>> another possibility is to use data package (.dat) files, which I believe
>> *could* be shared between th
On 04.12.12 11:53, Jean-Marc Desperrier wrote:
Norbert Lindenberg a écrit :
The ECMAScript Internationalization API [...] provides web applications
with the ability to format numbers, dates, and times and sort strings
according to the rules of the language that the application is using,
not the
Norbert Lindenberg a écrit :
The ECMAScript Internationalization API [...] provides web applications
with the ability to format numbers, dates, and times and sort strings
according to the rules of the language that the application is using,
not the one that browser and OS default to.
If the OS
On Mon, Dec 03, 2012 at 05:25:55PM -0500, Rafael Ávila de Espíndola
wrote:
> >
> > Actually, ICU has several options for how its data is packaged. One
> > option is libraries (which are not sharable between architectures,
> > AFAIK), but another possibility is to use data package (.dat) files,
> >
Hi,
- Original Message -
> From: "Justin Lebar"
> To: "Norbert Lindenberg"
> Cc: "Benjamin Smedberg" ,
> dev-platform@lists.mozilla.org
> Sent: Monday, December 3, 2012 7:54:34 PM
> Subject: Re: Integrating ICU into Mozilla build
>
&g
A year ago, I investigated to replace uconv with ICU.
Many (most is IBM code page) converters in ICU isn't compatible with
uconv, and ICU isn't have all character set converters that we already
use in uconv.
If using ICU for uconv, we can remove a few table code into uconv, but
not all.
-
> Is all code loaded into memory as one lump on B2G, or is it paged in as
> needed? There may be quite a bit of code in there that's not commonly needed.
I don't know how it works, to be honest. I can't imagine that library
pages are loaded only on demand with no pre-fetching, since that would
b
On Tue, Dec 4, 2012 at 2:04 PM, Norbert Lindenberg
wrote:
> Understood. Now, how does B2G support internationalization in the absence of
> ICU?
Possibly it uses ICU already. There's an external/icu4c in the B2G repository.
Chris.
--
http://www.bluishcoder.co.nz
On Dec 3, 2012, at 14:10 , Jonathan Kew wrote:
> On 3/12/12 20:11, Mike Hommey wrote:
>> On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
>>> On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
As part of implementing the ECMAScript Internationalization API [1, 2] in
Spid
On Dec 3, 2012, at 16:15 , Justin Lebar wrote:
> On Mon, Dec 3, 2012 at 5:39 PM, Norbert Lindenberg
> wrote:
>>
>> Well, the first question is what size increase would be acceptable given the
>> benefits that ICU provides.
>
>> I have currently trimmed it to 9.7 MB for the data library and 3.
On Mon, Dec 3, 2012 at 5:39 PM, Norbert Lindenberg
wrote:
>
> Well, the first question is what size increase would be acceptable given the
> benefits that ICU provides.
> I have currently trimmed it to 9.7 MB for the data library and 3.1 MB for two
> code libraries.
Ignoring download size for
On Dec 3, 2012, at 11:48 , Benjamin Smedberg wrote:
> On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
>> As part of implementing the ECMAScript Internationalization API [1, 2] in
>> SpiderMonkey, and as an aid in internationalizing other functionality in
>> Mozilla products [3], I need to integ
>
> Actually, ICU has several options for how its data is packaged. One option is
> libraries (which are not sharable between architectures, AFAIK), but another
> possibility is to use data package (.dat) files, which I believe *could* be
> shared between the 32- and 64-bit builds.
getting a b
On 3/12/12 20:11, Mike Hommey wrote:
On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
As part of implementing the ECMAScript Internationalization API [1, 2] in
SpiderMonkey, and as an aid in internationalizing other functionalit
On Mon, Dec 03, 2012 at 09:11:58PM +0100, Mike Hommey wrote:
> On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
> > On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
> > >As part of implementing the ECMAScript Internationalization API [1, 2] in
> > >SpiderMonkey, and as an aid in i
On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
> On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
> >As part of implementing the ECMAScript Internationalization API [1, 2] in
> >SpiderMonkey, and as an aid in internationalizing other functionality in
> >Mozilla products [3], I
On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
As part of implementing the ECMAScript Internationalization API [1, 2] in
SpiderMonkey, and as an aid in internationalizing other functionality in
Mozilla products [3], I need to integrate the ICU library (International
Components for Unicode [4]
On Mon, Dec 3, 2012 at 11:32 AM, Norbert Lindenberg <
mozillali...@lindenbergsoftware.com> wrote:
> As part of implementing the ECMAScript Internationalization API [1, 2] in
> SpiderMonkey, and as an aid in internationalizing other functionality in
> Mozilla products [3], I need to integrate the I
52 matches
Mail list logo
