Discuss
  • i18n objects

i18n objects

# Shawn Steele (15 years ago)

Considering last week’s discussion on the i18n objects, I think I’ll follow this pattern:

· Constructor takes options, as specified

· LocaleInfo takes an option to enable inferring.

o Default to infer or not is an open question.

· Have an isInferred() function to test if a property was inferred.

· NO options property

· Instead individual properties for each value.

· Using the .derive method to derive a similar object.

Discussion of each of these should probably have individual threads unless they directly impact each other; last week’s thread wandered between topics without really resolving them.

My reasoning:

· I didn’t use the options property because an options property is controversial, and leads to other “hard” questions, like:

o Would options represent only the state when constructed? Or the current state? (Can they differ?)

o Would options be read-only? (And then how would you use it).

o Would options be a writable copy (which sounds expensive to me)?

o Would options be mutable?

· It’s clear that we want to be able to infer or not. If find the ability to set it in the constructor much simple. A disadvantage is that a library would have to figure out if inputs were inferred by using isInferred(). An advantage is that when a worker doesn’t really care if data is inferred or not, then the caller can pass a correctly inferred (or not) object to the worker.

· If there isn’t an options property, then there are fewer mechanisms to create a similar derived object. The suggested .derive() function seemed simplest.

-Shawn

  • Shawn

  blogs.msdn.com/shawnste (Selfhost 7908)

# Mark Davis ☕ (15 years ago)

As stated before, I think that this approach is more error prone; that it would be better to explicitly call the other function. Here would be the difference between the two alternatives for the API: A and B, under the two common scenarios:

Scenario 1 "I don't care"

A. x = myLocaleInfo.region;

B. x = myLocaleInfo.inferRegion();

Scenario 2. "I only want explicit region"

A. x = myLocaleInfo.hasInferredRegion ? undefined : myLocaleInfo.region;

B. x = myLocaleInfo.region();

I find the B approach simpler and clearer, and we don't have to have an extra input parameter.

Mark

— Il meglio è l’inimico del bene —

# Shawn Steele (15 years ago)

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, it can call BlackBox(myLocale). However now myLocale has to call either .region or .inferredRegion, depending on whether or not it’s inferred. But the “black box” may not have a clue whether inferred is correct (or not).

IMO it’s better to let the LocaleInfo object behave however the caller wants it to behave and let BlackBox assume that the caller’s using it right. IF the blackbox really cares, it can still check, but, IMO, that’s very uncommon.

From: mark.edward.davis at gmail.com [mailto:mark.edward.davis at gmail.com] On Behalf Of Mark Davis ? Sent: Monday, January 24, 2011 3:41 PM To: Shawn Steele Cc: es-discuss at mozilla.org Subject: Re: i18n objects

As stated before, I think that this approach is more error prone; that it would be better to explicitly call the other function. Here would be the difference between the two alternatives for the API: A and B, under the two common scenarios:

Scenario 1 "I don't care"

A. x = myLocaleInfo.region;

B. x = myLocaleInfo.inferRegion();

Scenario 2. "I only want explicit region"

A. x = myLocaleInfo.hasInferredRegion ? undefined : myLocaleInfo.region;

B. x = myLocaleInfo.region();

I find the B approach simpler and clearer, and we don't have to have an extra input parameter.

Mark

— Il meglio è l’inimico del bene —

On Mon, Jan 24, 2011 at 10:25, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

Considering last week’s discussion on the i18n objects, I think I’ll follow this pattern:

• Constructor takes options, as specified

• LocaleInfo takes an option to enable inferring.

o Default to infer or not is an open question.

• Have an isInferred() function to test if a property was inferred.

• NO options property

• Instead individual properties for each value.

• Using the .derive method to derive a similar object.

Discussion of each of these should probably have individual threads unless they directly impact each other; last week’s thread wandered between topics without really resolving them.

My reasoning:

• I didn’t use the options property because an options property is controversial, and leads to other “hard” questions, like:

o Would options represent only the state when constructed? Or the current state? (Can they differ?)

o Would options be read-only? (And then how would you use it).

o Would options be a writable copy (which sounds expensive to me)?

o Would options be mutable?

• It’s clear that we want to be able to infer or not. If find the ability to set it in the constructor much simple. A disadvantage is that a library would have to figure out if inputs were inferred by using isInferred(). An advantage is that when a worker doesn’t really care if data is inferred or not, then the caller can pass a correctly inferred (or not) object to the worker.

• If there isn’t an options property, then there are fewer mechanisms to create a similar derived object. The suggested .derive() function seemed simplest.

-Shawn

  • Shawn

  blogs.msdn.com/shawnste (Selfhost 7908)

# Mark Davis ☕ (15 years ago)

I don't understand.

  • If you want the explicit value, you call .region.
    • NB, the value will be undefined iff it is not set explicitly.
  • If you want the (possibly) inferred value, you call .inferRegion().
    • NB, the value is never undefined.

What is the problem?

Mark

— Il meglio è l’inimico del bene —

# Shawn Steele (15 years ago)

The “black box” library has no clue if the person calling the black box wants me to infer or not, that’s up to the caller. However the black box would have to choose which API to call. With inferred being a state of LocaleInfo though, then it’s somewhat easy for the caller to ensure that it creates it the way it intends.

-Shawn

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Mark Davis ? Sent: Monday, January 24, 2011 4:09 PM To: Shawn Steele Cc: es-discuss at mozilla.org Subject: Re: i18n objects

I don't understand.

  • If you want the explicit value, you call .region.

  • NB, the value will be undefined iff it is not set explicitly.

  • If you want the (possibly) inferred value, you call .inferRegion().

  • NB, the value is never undefined. What is the problem?

Mark

— Il meglio è l’inimico del bene —

On Mon, Jan 24, 2011 at 15:53, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at 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, it can call BlackBox(myLocale). However now myLocale has to call either .region or .inferredRegion, depending on whether or not it’s inferred. But the “black box” may not have a clue whether inferred is correct (or not).

IMO it’s better to let the LocaleInfo object behave however the caller wants it to behave and let BlackBox assume that the caller’s using it right. IF the blackbox really cares, it can still check, but, IMO, that’s very uncommon.

From: mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com> [mailto:mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com>] On Behalf Of Mark Davis ?

Sent: Monday, January 24, 2011 3:41 PM To: Shawn Steele Cc: es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

As stated before, I think that this approach is more error prone; that it would be better to explicitly call the other function. Here would be the difference between the two alternatives for the API: A and B, under the two common scenarios:

Scenario 1 "I don't care"

A. x = myLocaleInfo.region;

B. x = myLocaleInfo.inferRegion();

Scenario 2. "I only want explicit region"

A. x = myLocaleInfo.hasInferredRegion ? undefined : myLocaleInfo.region;

B. x = myLocaleInfo.region();

I find the B approach simpler and clearer, and we don't have to have an extra input parameter.

Mark

— Il meglio è l’inimico del bene — On Mon, Jan 24, 2011 at 10:25, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

Considering last week’s discussion on the i18n objects, I think I’ll follow this pattern:

• Constructor takes options, as specified

• LocaleInfo takes an option to enable inferring.

o Default to infer or not is an open question.

• Have an isInferred() function to test if a property was inferred.

• NO options property

• Instead individual properties for each value.

• Using the .derive method to derive a similar object.

Discussion of each of these should probably have individual threads unless they directly impact each other; last week’s thread wandered between topics without really resolving them.

My reasoning:

• I didn’t use the options property because an options property is controversial, and leads to other “hard” questions, like:

o Would options represent only the state when constructed? Or the current state? (Can they differ?)

o Would options be read-only? (And then how would you use it).

o Would options be a writable copy (which sounds expensive to me)?

o Would options be mutable?

• It’s clear that we want to be able to infer or not. If find the ability to set it in the constructor much simple. A disadvantage is that a library would have to figure out if inputs were inferred by using isInferred(). An advantage is that when a worker doesn’t really care if data is inferred or not, then the caller can pass a correctly inferred (or not) object to the worker.

• If there isn’t an options property, then there are fewer mechanisms to create a similar derived object. The suggested .derive() function seemed simplest.

-Shawn

  • Shawn

  blogs.msdn.com/shawnste (Selfhost 7908)

# Nebojša Ćirić (15 years ago)

I think we are missing couple details here.

In case user provides the region when constructing LocaleInfo, both .region and .inferredRegion would be the same (i.e. there is nothing to infer).

data provided | US | nothing

.region | US | undefined .inferredRegion | US | US

If one is willing to use inferred data then he can just get the value of inferred property (or call a function). If one is not willing, he should always look into .region property.

This approach duplicates number of properties, but eliminates inferrData constructor option, and isInferred() method.

  1. јануар 2011. 16.09, Mark Davis ☕ <mark at macchiato.com> је написао/ла:
# Shawn Steele (15 years ago)

I agree, but I don’t think that’s necessarily clear to the blackbox library. Additionally the “inferredRegion” seems a bit harder to use, so I think maybe the blackbox would lean towards “region” even if “inferredRegion” might be acceptable.

And then the “black box” library has to make the decision. If this is a worker library, that decision may not be appropriate for the library to make. If the decision is appropriate for the caller to make instead, then it’s tricky for the library to do the right thing. If the black box library thinks that inferred is acceptable, then it calls “inferredRegion.” But in caller’s context, if that isn’t acceptable, the caller would have a problem “correcting” that internal blackbox behavior.

OTOH: With “my” approach, if the caller specified the behavior, then the blackbox would get error conditions if they tried to get “region” and it wasn’t allowed. So it could err. And if the blackbox really needed to be making the decision, then it still could.

-Shawn

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Nebojša Ciric Sent: Monday, January 24, 2011 4:30 PM To: Mark Davis ☕ Cc: Shawn Steele; es-discuss at mozilla.org Subject: Re: i18n objects

I think we are missing couple details here.

In case user provides the region when constructing LocaleInfo, both .region and .inferredRegion would be the same (i.e. there is nothing to infer).

data provided | US | nothing

.region | US | undefined .inferredRegion | US | US

If one is willing to use inferred data then he can just get the value of inferred property (or call a function). If one is not willing, he should always look into .region property.

This approach duplicates number of properties, but eliminates inferrData constructor option, and isInferred() method.

  1. јануар 2011. 16.09, Mark Davis ☕ <mark at macchiato.com<mailto:mark at macchiato.com>> је написао/ла:

I don't understand.

  • If you want the explicit value, you call .region.

  • NB, the value will be undefined iff it is not set explicitly.

  • If you want the (possibly) inferred value, you call .inferRegion().

  • NB, the value is never undefined. What is the problem?

Mark

— Il meglio è l’inimico del bene —

On Mon, Jan 24, 2011 at 15:53, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at 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, it can call BlackBox(myLocale). However now myLocale has to call either .region or .inferredRegion, depending on whether or not it’s inferred. But the “black box” may not have a clue whether inferred is correct (or not).

IMO it’s better to let the LocaleInfo object behave however the caller wants it to behave and let BlackBox assume that the caller’s using it right. IF the blackbox really cares, it can still check, but, IMO, that’s very uncommon.

From: mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com> [mailto:mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com>] On Behalf Of Mark Davis ?

Sent: Monday, January 24, 2011 3:41 PM To: Shawn Steele Cc: es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

As stated before, I think that this approach is more error prone; that it would be better to explicitly call the other function. Here would be the difference between the two alternatives for the API: A and B, under the two common scenarios:

Scenario 1 "I don't care"

A. x = myLocaleInfo.region;

B. x = myLocaleInfo.inferRegion();

Scenario 2. "I only want explicit region"

A. x = myLocaleInfo.hasInferredRegion ? undefined : myLocaleInfo.region;

B. x = myLocaleInfo.region();

I find the B approach simpler and clearer, and we don't have to have an extra input parameter.

Mark

— Il meglio è l’inimico del bene — On Mon, Jan 24, 2011 at 10:25, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

Considering last week’s discussion on the i18n objects, I think I’ll follow this pattern:

• Constructor takes options, as specified

• LocaleInfo takes an option to enable inferring.

o Default to infer or not is an open question.

• Have an isInferred() function to test if a property was inferred.

• NO options property

• Instead individual properties for each value.

• Using the .derive method to derive a similar object.

Discussion of each of these should probably have individual threads unless they directly impact each other; last week’s thread wandered between topics without really resolving them.

My reasoning:

• I didn’t use the options property because an options property is controversial, and leads to other “hard” questions, like:

o Would options represent only the state when constructed? Or the current state? (Can they differ?)

o Would options be read-only? (And then how would you use it).

o Would options be a writable copy (which sounds expensive to me)?

o Would options be mutable?

• It’s clear that we want to be able to infer or not. If find the ability to set it in the constructor much simple. A disadvantage is that a library would have to figure out if inputs were inferred by using isInferred(). An advantage is that when a worker doesn’t really care if data is inferred or not, then the caller can pass a correctly inferred (or not) object to the worker.

• If there isn’t an options property, then there are fewer mechanisms to create a similar derived object. The suggested .derive() function seemed simplest.

-Shawn

  • Shawn

  blogs.msdn.com/shawnste (Selfhost 7908)

# Nebojša Ćirić (15 years ago)

So you are saying, if library developer wanted to keep his library flexible and avoid:

var region = loc.region; if (region === undefined && allowInferrence) { region = loc.inferredRegion; } else { return error; // or fallback gracefully. }

blocks of code, he could let end developer pass constructed LocaleInfo object (with inferData set to true or false), or just a flag and then construct LocaleInfo object. Library code would then look like:

var region = loc.region; if (region === undefined && !allowInference) { return error; // or fallback gracefully. } else if (region === undefined && allowInference) { // This case shouldn't happen? }

In both cases library (black box) writer would need to do defensive checks in order to provide robust library, and this boils down to which approach looks better, and requires less code. I don't think either approach limits black box author in anyway.

We could write a non-nonsense library and see what looks/works better?

  1. јануар 2011. 16.38, Shawn Steele <Shawn.Steele at microsoft.com> је написао/ла:
# Shawn Steele (15 years ago)

My assertion is that there are many libraries that provide very general behavior and presume valid inputs. Eg: they shouldn’t be called with locales that don’t work for them. I expect that most “library” type functions would want to use the “inferredRegion” idea. So: it’d be more user friendly to have “explicitRegion” (not inferred) and “region” (inferred), but that defeats some of the idea here.

A problem is that if a library isn’t thinking about inferred or not, it’s probably OK as long as the caller is “doing the right thing”. If the library isn’t too worried about it, then they could pick “.region” (not inferred), and forget to test the inferred case. Then it’d blow up unnecessarily.

I think that 99% of the time, I can decide, when constructing LocaleInfo(), if inferred is good or not for my application. If my app is a banking app, then perhaps I know that inferring currencies is very bad. So it the “infer” decision should be made, IMO, well above the library level.

I expect good apps that don’t want to infer to do something like:

var myLocale = new LocaleInfo({localeName:en; infer:false}) if (myLocale.inferred(currency)) { // Yipe, go do error case } else { // continue nicely… BlackBox.DoSomething(myLocale); }

So the blackbox shouldn’t ever have to worry about it. Of course if we have currency.isInferred, then it’s trivial for a blackbox currency specific worrying about app to be worried.

-Shawn

From: Nebojša Ćirić [mailto:cira at google.com] Sent: Monday, January 24, 2011 4:58 PM To: Shawn Steele Cc: Mark Davis ☕; es-discuss at mozilla.org Subject: Re: i18n objects

So you are saying, if library developer wanted to keep his library flexible and avoid:

var region = loc.region; if (region === undefined && allowInferrence) { region = loc.inferredRegion; } else { return error; // or fallback gracefully. }

blocks of code, he could let end developer pass constructed LocaleInfo object (with inferData set to true or false), or just a flag and then construct LocaleInfo object. Library code would then look like:

var region = loc.region; if (region === undefined && !allowInference) { return error; // or fallback gracefully. } else if (region === undefined && allowInference) { // This case shouldn't happen? }

In both cases library (black box) writer would need to do defensive checks in order to provide robust library, and this boils down to which approach looks better, and requires less code. I don't think either approach limits black box author in anyway.

We could write a non-nonsense library and see what looks/works better?

  1. јануар 2011. 16.38, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

I agree, but I don’t think that’s necessarily clear to the blackbox library. Additionally the “inferredRegion” seems a bit harder to use, so I think maybe the blackbox would lean towards “region” even if “inferredRegion” might be acceptable.

And then the “black box” library has to make the decision. If this is a worker library, that decision may not be appropriate for the library to make. If the decision is appropriate for the caller to make instead, then it’s tricky for the library to do the right thing. If the black box library thinks that inferred is acceptable, then it calls “inferredRegion.” But in caller’s context, if that isn’t acceptable, the caller would have a problem “correcting” that internal blackbox behavior.

OTOH: With “my” approach, if the caller specified the behavior, then the blackbox would get error conditions if they tried to get “region” and it wasn’t allowed. So it could err. And if the blackbox really needed to be making the decision, then it still could.

-Shawn

From: es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org> [mailto:es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org>] On Behalf Of Nebojša Ciric

Sent: Monday, January 24, 2011 4:30 PM To: Mark Davis ☕ Cc: Shawn Steele; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

I think we are missing couple details here.

In case user provides the region when constructing LocaleInfo, both .region and .inferredRegion would be the same (i.e. there is nothing to infer).

data provided | US | nothing

.region | US | undefined .inferredRegion | US | US

If one is willing to use inferred data then he can just get the value of inferred property (or call a function). If one is not willing, he should always look into .region property.

This approach duplicates number of properties, but eliminates inferrData constructor option, and isInferred() method.

  1. јануар 2011. 16.09, Mark Davis ☕ <mark at macchiato.com<mailto:mark at macchiato.com>> је написао/ла:

I don't understand.

  • If you want the explicit value, you call .region.

  • NB, the value will be undefined iff it is not set explicitly.

  • If you want the (possibly) inferred value, you call .inferRegion().

  • NB, the value is never undefined. What is the problem?

Mark

— Il meglio è l’inimico del bene — On Mon, Jan 24, 2011 at 15:53, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at 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, it can call BlackBox(myLocale). However now myLocale has to call either .region or .inferredRegion, depending on whether or not it’s inferred. But the “black box” may not have a clue whether inferred is correct (or not).

IMO it’s better to let the LocaleInfo object behave however the caller wants it to behave and let BlackBox assume that the caller’s using it right. IF the blackbox really cares, it can still check, but, IMO, that’s very uncommon.

From: mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com> [mailto:mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com>] On Behalf Of Mark Davis ?

Sent: Monday, January 24, 2011 3:41 PM To: Shawn Steele Cc: es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

As stated before, I think that this approach is more error prone; that it would be better to explicitly call the other function. Here would be the difference between the two alternatives for the API: A and B, under the two common scenarios:

Scenario 1 "I don't care"

A. x = myLocaleInfo.region;

B. x = myLocaleInfo.inferRegion();

Scenario 2. "I only want explicit region"

A. x = myLocaleInfo.hasInferredRegion ? undefined : myLocaleInfo.region;

B. x = myLocaleInfo.region();

I find the B approach simpler and clearer, and we don't have to have an extra input parameter.

Mark

— Il meglio è l’inimico del bene — On Mon, Jan 24, 2011 at 10:25, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

Considering last week’s discussion on the i18n objects, I think I’ll follow this pattern:

• Constructor takes options, as specified

• LocaleInfo takes an option to enable inferring.

o Default to infer or not is an open question.

• Have an isInferred() function to test if a property was inferred.

• NO options property

• Instead individual properties for each value.

• Using the .derive method to derive a similar object.

Discussion of each of these should probably have individual threads unless they directly impact each other; last week’s thread wandered between topics without really resolving them.

My reasoning:

• I didn’t use the options property because an options property is controversial, and leads to other “hard” questions, like:

o Would options represent only the state when constructed? Or the current state? (Can they differ?)

o Would options be read-only? (And then how would you use it).

o Would options be a writable copy (which sounds expensive to me)?

o Would options be mutable?

• It’s clear that we want to be able to infer or not. If find the ability to set it in the constructor much simple. A disadvantage is that a library would have to figure out if inputs were inferred by using isInferred(). An advantage is that when a worker doesn’t really care if data is inferred or not, then the caller can pass a correctly inferred (or not) object to the worker.

• If there isn’t an options property, then there are fewer mechanisms to create a similar derived object. The suggested .derive() function seemed simplest.

-Shawn

  • Shawn

  blogs.msdn.com/shawnste (Selfhost 7908)

# Phillips, Addison (15 years ago)

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 ;-). Also, we’re noticing some gaps in the earlier docs. I want to see if they’ve been addressed or if I should comment instead.

WRT the current discussion, I think the problem for me falls between “explicit BCP47 fields” (what I’ve tended to call the “gross locale identifier”), which I’m pretty sure I don’t want automagically populated, and “implicit fields” (i.e. the ones you’d specify using the extension). The implicit fields I kind of expect to have a default setting—if I give you “de”, there should be a default collation, currency, calendar, and such. And maybe the Latin script (Suppress-Script says so). But inferring “de-DE” seems ambitious. Maybe for German it’s not so bad, but many times I don’t want inferences about region to be foisted upon me.

As a result, I’m more in favor of Mark’s solution (you can get an inferred value, but you have to call for it; in most cases, you get null for unset fields). But would that be for all fields? I’d rather that not be the case.

Just a thought.

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Shawn Steele [mailto:Shawn.Steele at microsoft.com] Sent: Monday, January 24, 2011 3:53 PM To: Mark Davis ☕ Cc: es-discuss at mozilla.org Subject: RE: i18n objects

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, it can call BlackBox(myLocale). However now myLocale has to call either .region or .inferredRegion, depending on whether or not it’s inferred. But the “black box” may not have a clue whether inferred is correct (or not).

IMO it’s better to let the LocaleInfo object behave however the caller wants it to behave and let BlackBox assume that the caller’s using it right. IF the blackbox really cares, it can still check, but, IMO, that’s very uncommon.

From: mark.edward.davis at gmail.com [mailto:mark.edward.davis at gmail.com] On Behalf Of Mark Davis ? Sent: Monday, January 24, 2011 3:41 PM To: Shawn Steele Cc: es-discuss at mozilla.org Subject: Re: i18n objects

As stated before, I think that this approach is more error prone; that it would be better to explicitly call the other function. Here would be the difference between the two alternatives for the API: A and B, under the two common scenarios:

Scenario 1 "I don't care"

A. x = myLocaleInfo.region;

B. x = myLocaleInfo.inferRegion();

Scenario 2. "I only want explicit region"

A. x = myLocaleInfo.hasInferredRegion ? undefined : myLocaleInfo.region;

B. x = myLocaleInfo.region();

I find the B approach simpler and clearer, and we don't have to have an extra input parameter.

Mark

— Il meglio è l’inimico del bene — On Mon, Jan 24, 2011 at 10:25, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

Considering last week’s discussion on the i18n objects, I think I’ll follow this pattern:

• Constructor takes options, as specified

• LocaleInfo takes an option to enable inferring.

o Default to infer or not is an open question.

• Have an isInferred() function to test if a property was inferred.

• NO options property

• Instead individual properties for each value.

• Using the .derive method to derive a similar object.

Discussion of each of these should probably have individual threads unless they directly impact each other; last week’s thread wandered between topics without really resolving them.

My reasoning:

• I didn’t use the options property because an options property is controversial, and leads to other “hard” questions, like:

o Would options represent only the state when constructed? Or the current state? (Can they differ?)

o Would options be read-only? (And then how would you use it).

o Would options be a writable copy (which sounds expensive to me)?

o Would options be mutable?

• It’s clear that we want to be able to infer or not. If find the ability to set it in the constructor much simple. A disadvantage is that a library would have to figure out if inputs were inferred by using isInferred(). An advantage is that when a worker doesn’t really care if data is inferred or not, then the caller can pass a correctly inferred (or not) object to the worker.

• If there isn’t an options property, then there are fewer mechanisms to create a similar derived object. The suggested .derive() function seemed simplest.

-Shawn

  • Shawn

  blogs.msdn.com/shawnste (Selfhost 7908)

# Shawn Steele (15 years ago)

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Nebojša Ćirić (15 years ago)

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements...

  1. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com> је написао/ла:
# Phillips, Addison (15 years ago)

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com] Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Nebojša Ćirić (15 years ago)

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal...

  1. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com> је написао/ла:
# Phillips, Addison (15 years ago)

That would be hugely helpful. In addition, if we still had questions/comments, we could forward them at that point.

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com] Sent: Wednesday, January 26, 2011 1:07 PM To: Phillips, Addison Cc: Shawn Steele; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org Subject: Re: i18n objects

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal... 26. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Shawn Steele (15 years ago)

I’m working on a more formal update, ETA is next week?

-Shawn

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Nebojša Ciric Sent: Wednesday, January 26, 2011 1:07 PM To: Phillips, Addison Cc: Gillam, Richard; Shawn Steele; es-discuss at mozilla.org Subject: Re: i18n objects

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal... 26. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Shawn Steele (15 years ago)

I’m sorry, I missed part of the thread. I’d be happy if Nebojša would update the doc, and I’d be happy to participate in a call. (I can’t update it that fast).

Anytime is OK for me.

-Shawn

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Nebojša Ciric Sent: Wednesday, January 26, 2011 1:07 PM To: Phillips, Addison Cc: Gillam, Richard; Shawn Steele; es-discuss at mozilla.org Subject: Re: i18n objects

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal... 26. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Mark Davis ☕ (15 years ago)

Your last message was illustrative.

# Shawn Steele (15 years ago)

Ah, well. Hmmm. I was sort of assuming the caller would care if the data was valid and that the callee wouldn’t be making that kind of decision.

If we went with “infer-by-default”, then your scenario wouldn’t happen (S) unless the app really didn’t want inferring. In which case your workaround is the wrong thing to do (I’d think).

I really don’t want to double the surface, but I see your point about changing from uninferred to inferred.

-Shawn

From: mark.edward.davis at gmail.com [mailto:mark.edward.davis at gmail.com] On Behalf Of Mark Davis ? Sent: Wednesday, January 26, 2011 1:51 PM To: Shawn Steele Cc: Nebojša Ćirić; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org Subject: Re: i18n objects

Your last message was illustrative.

From our perspective, the mainline service APIs (currency formatting, collation, etc.) should always return the best possible answer, with some way to determine whether or not the data was inferred or not in case someone cares (which is important, but definitely the lower-runner case). So writing from the point of view of implementing a service, we'll need to get the the best currency from a LocaleInfo. What your proposal forces us to do is something like Alternative S below, instead of Alternative M:

Alternative S:

theCurrency = inputLocaleInfo.region; // if we didn't get one, then the creator of the inputLocaleInfo set infer:false, so we have to work around that if (theCurrency == null) { myInputLocaleInfo = new LocalInfo({localeInfo:inputLocaleInfo, infer:true); theCurrency = myInputLocaleInfo.region; inferredCurrency = true; } else { inferredCurrency = false; }

Alternative M:

theCurrency = inputLocaleInfo.inferCurrency; inferredCurrency = inputLocaleInfo.region != null;

I think having a phone call will help to understand all the perspectives on the issue.

Mark

— Il meglio è l’inimico del bene —

On Wed, Jan 26, 2011 at 13:27, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

I’m sorry, I missed part of the thread. I’d be happy if Nebojša would update the doc, and I’d be happy to participate in a call. (I can’t update it that fast).

Anytime is OK for me.

-Shawn

From: es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org> [mailto:es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org>] On Behalf Of Nebojša Ciric

Sent: Wednesday, January 26, 2011 1:07 PM To: Phillips, Addison Cc: Gillam, Richard; Shawn Steele; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal... 26. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Nebojša Ćirić (15 years ago)

I made quick update - could you take a look if I captured the essentials (there are 2 proposals)?

strawman:i18n_api#proposal_1_shawns

I tried to get examples to show best and worst cases for both approaches - update if you can do worse :).

  1. јануар 2011. 13.54, Shawn Steele <Shawn.Steele at microsoft.com> је написао/ла:
# Shawn Steele (15 years ago)

Well, that seems to cover that issue, but the document in general is very divergent from the minimal surface area discussed last time. Also the LocaleInfo is missing, and it’s missing .derive (however we implement it).

-Shawn

From: Nebojša Ćirić [mailto:cira at google.com] Sent: Wednesday, January 26, 2011 4:13 PM To: Shawn Steele Cc: Mark Davis ☕; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org Subject: Re: i18n objects

I made quick update - could you take a look if I captured the essentials (there are 2 proposals)?

strawman:i18n_api#proposal_1_shawns

I tried to get examples to show best and worst cases for both approaches - update if you can do worse :). 26. јануар 2011. 13.54, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

Ah, well. Hmmm. I was sort of assuming the caller would care if the data was valid and that the callee wouldn’t be making that kind of decision.

If we went with “infer-by-default”, then your scenario wouldn’t happen (S) unless the app really didn’t want inferring. In which case your workaround is the wrong thing to do (I’d think).

I really don’t want to double the surface, but I see your point about changing from uninferred to inferred.

-Shawn

From: mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com> [mailto:mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com>] On Behalf Of Mark Davis ?

Sent: Wednesday, January 26, 2011 1:51 PM To: Shawn Steele Cc: Nebojša Ćirić; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Your last message was illustrative.

From our perspective, the mainline service APIs (currency formatting, collation, etc.) should always return the best possible answer, with some way to determine whether or not the data was inferred or not in case someone cares (which is important, but definitely the lower-runner case). So writing from the point of view of implementing a service, we'll need to get the the best currency from a LocaleInfo. What your proposal forces us to do is something like Alternative S below, instead of Alternative M:

Alternative S:

theCurrency = inputLocaleInfo.region; // if we didn't get one, then the creator of the inputLocaleInfo set infer:false, so we have to work around that if (theCurrency == null) { myInputLocaleInfo = new LocalInfo({localeInfo:inputLocaleInfo, infer:true); theCurrency = myInputLocaleInfo.region; inferredCurrency = true; } else { inferredCurrency = false; }

Alternative M:

theCurrency = inputLocaleInfo.inferCurrency; inferredCurrency = inputLocaleInfo.region != null;

I think having a phone call will help to understand all the perspectives on the issue.

Mark

— Il meglio è l’inimico del bene — On Wed, Jan 26, 2011 at 13:27, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

I’m sorry, I missed part of the thread. I’d be happy if Nebojša would update the doc, and I’d be happy to participate in a call. (I can’t update it that fast).

Anytime is OK for me.

-Shawn

From: es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org> [mailto:es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org>] On Behalf Of Nebojša Ciric

Sent: Wednesday, January 26, 2011 1:07 PM To: Phillips, Addison Cc: Gillam, Richard; Shawn Steele; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal... 26. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Nebojša Ćirić (15 years ago)

I've removed the old content. It needs more work - like comments, some properties, return values, but the API is there as proposed in the last meeting.

Please edit if you find errors.

Shall we meet Friday, 3pm? I'll send details (bridge and pin) tomorrow.

  1. јануар 2011. 16.17, Shawn Steele <Shawn.Steele at microsoft.com> је написао/ла:
# Nebojša Ćirić (15 years ago)

Ok, here are the teleconference details:

Name:Nebojsa CiricInternational direct:*+1 617 224.4646 tel:+16172244646 US Toll free:1 866 457.4646 tel:+18664574646 *Participant passcode:*15242605 then # *

  1. јануар 2011. 16.57, Nebojša Ćirić <cira at google.com> је написао/ла:
# Mark Davis ☕ (15 years ago)

More explicitly, does anyone who wants to be in on this conversation notmake Friday at 3:00 PT?

Mark

— Il meglio è l’inimico del bene —

# Nebojša Ćirić (15 years ago)

Shawn, Richard, Mark, Jungshik, Addison and I had a teleconference call today about this issue and we managed to resolve the differences.

LocaleInfo object won't have special infer flag, but we will let user of the library specify which values shouldn't be inferred, by listing them at the construction time.

There are 3 cases (2 and 3 are the same except for the value passed to currency):

  1. Create LocaleInfo with locale only (en-US), currency and region are inferred to USD and US respectively.
  2. Create LocaleInfo with locale (en-US), currency:"XXX" -> Currency won't

be inferred but region will. 3. Create LocaleInfo with locale (en-US), currency:"EUR" -> Currency is set

by user to EUR and region is inferred.

We would use standard undefined values for parameters (xx for region, und for language, XXX for currency). See LDML documentwww.unicode.org/reports/tr35/#Unknown_or_Invalid_Identifiersfor

details.

I will update strawman with new proposal.

  1. јануар 2011. 17.37, Mark Davis ☕ <mark at macchiato.com> је написао/ла:
# Shawn Steele (15 years ago)

I found that confusing to read. I know what you mean ‘cause I was on the call, but could you show and example for Creating LocaleInfo without inferred region?

From: Nebojša Ćirić [mailto:cira at google.com] Sent: Friday, January 28, 2011 4:18 PM To: Mark Davis ☕ Cc: Shawn Steele; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org Subject: Re: i18n objects

Shawn, Richard, Mark, Jungshik, Addison and I had a teleconference call today about this issue and we managed to resolve the differences.

LocaleInfo object won't have special infer flag, but we will let user of the library specify which values shouldn't be inferred, by listing them at the construction time.

There are 3 cases (2 and 3 are the same except for the value passed to currency):

  1. Create LocaleInfo with locale only (en-US), currency and region are inferred to USD and US respectively.

  2. Create LocaleInfo with locale (en-US), currency:"XXX" -> Currency won't be inferred but region will.

  3. Create LocaleInfo with locale (en-US), currency:"EUR" -> Currency is set by user to EUR and region is inferred.

We would use standard undefined values for parameters (xx for region, und for language, XXX for currency). See LDML documentwww.unicode.org/reports/tr35/#Unknown_or_Invalid_Identifiers for details.

I will update strawman with new proposal.

  1. јануар 2011. 17.37, Mark Davis ☕ <mark at macchiato.com<mailto:mark at macchiato.com>> је написао/ла:

More explicitly, does anyone who wants to be in on this conversation not make Friday at 3:00 PT?

Mark

— Il meglio è l’inimico del bene —

On Wed, Jan 26, 2011 at 17:06, Nebojša Ćirić <cira at google.com<mailto:cira at google.com>> wrote:

Ok, here are the teleconference details:

Name:

Nebojsa Ciric

International direct:

+1 617 224.4646tel:+16172244646

US Toll free:

1 866 457.4646tel:+18664574646

Participant passcode:

15242605 then #

  1. јануар 2011. 16.57, Nebojša Ćirić <cira at google.com<mailto:cira at google.com>> је написао/ла:

I've removed the old content. It needs more work - like comments, some properties, return values, but the API is there as proposed in the last meeting.

Please edit if you find errors.

Shall we meet Friday, 3pm? I'll send details (bridge and pin) tomorrow. 26. јануар 2011. 16.17, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

Well, that seems to cover that issue, but the document in general is very divergent from the minimal surface area discussed last time. Also the LocaleInfo is missing, and it’s missing .derive (however we implement it).

-Shawn

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 4:13 PM To: Shawn Steele Cc: Mark Davis ☕; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

I made quick update - could you take a look if I captured the essentials (there are 2 proposals)?

strawman:i18n_api#proposal_1_shawns

I tried to get examples to show best and worst cases for both approaches - update if you can do worse :). 26. јануар 2011. 13.54, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

Ah, well. Hmmm. I was sort of assuming the caller would care if the data was valid and that the callee wouldn’t be making that kind of decision.

If we went with “infer-by-default”, then your scenario wouldn’t happen (S) unless the app really didn’t want inferring. In which case your workaround is the wrong thing to do (I’d think).

I really don’t want to double the surface, but I see your point about changing from uninferred to inferred.

-Shawn

From: mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com> [mailto:mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com>] On Behalf Of Mark Davis ?

Sent: Wednesday, January 26, 2011 1:51 PM To: Shawn Steele Cc: Nebojša Ćirić; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Your last message was illustrative.

From our perspective, the mainline service APIs (currency formatting, collation, etc.) should always return the best possible answer, with some way to determine whether or not the data was inferred or not in case someone cares (which is important, but definitely the lower-runner case). So writing from the point of view of implementing a service, we'll need to get the the best currency from a LocaleInfo. What your proposal forces us to do is something like Alternative S below, instead of Alternative M:

Alternative S:

theCurrency = inputLocaleInfo.region; // if we didn't get one, then the creator of the inputLocaleInfo set infer:false, so we have to work around that if (theCurrency == null) { myInputLocaleInfo = new LocalInfo({localeInfo:inputLocaleInfo, infer:true); theCurrency = myInputLocaleInfo.region; inferredCurrency = true; } else { inferredCurrency = false; }

Alternative M:

theCurrency = inputLocaleInfo.inferCurrency; inferredCurrency = inputLocaleInfo.region != null;

I think having a phone call will help to understand all the perspectives on the issue.

Mark

— Il meglio è l’inimico del bene — On Wed, Jan 26, 2011 at 13:27, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

I’m sorry, I missed part of the thread. I’d be happy if Nebojša would update the doc, and I’d be happy to participate in a call. (I can’t update it that fast).

Anytime is OK for me.

-Shawn

From: es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org> [mailto:es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org>] On Behalf Of Nebojša Ciric

Sent: Wednesday, January 26, 2011 1:07 PM To: Phillips, Addison Cc: Gillam, Richard; Shawn Steele; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal... 26. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Nebojša Ćirić (15 years ago)

Sorry it took me some time to get back to the document. I actually tried implementing the API just to see how it feels and I found a couple of problems with the implementation (see the latest at strawman:i18n_api).

Just to reiterate what we are aiming to do:

  1. There is a global LocaleInfo object that would hold the rest (collators, formatters...).
  2. Once we have LocaleInfo instance we shouldn't have to pass that into constructors (simplifies call sites, and allows us to pass locale around).

So this didn't work for me:

LocaleInfo = function(options) {...}; LocaleInfo.prototype.Collator = function(options) {...};

var locale = new LocaleInfo(); var collator = new LocaleInfo.Collator();

At the point where we call Collator() method this is already set to a new object and we have no access to the LocaleInfo data.

So I changed the design a little bit:

LocaleInfo = function(options) {...}; // same as before.

LocaleInfo.Collator = function(options, LocaleInfo locInfo) { does the real work here }; // new static on LocaleInfo class. LocaleInfo.Collator.prototype.derive = function ()...

LocaleInfo.prototype.collator = function(options) { return new LocaleInfo.Collator(options, this) }; // Here this refers to LocaleInfo and we just hide the complexity from the user.

If you all agree with this approach I would go ahead and write some samples on how to use this, and maybe a mock library to play with.

  1. јануар 2011. 17.31, Shawn Steele <Shawn.Steele at microsoft.com> је написао/ла:
# Nebojša Ćirić (15 years ago)

To make it clear, one should do this in latter case:

var locale = new LocaleInfo(); var collator = locale.collator(options);

but following would be valid too, thou more verbose:

var collator = new LocaleInfo.Collator(options, locale)

I would like to thank Mark S Miller for help on the new approach, I wasn't sure if it was in spirit of JavaScript...

  1. фебруар 2011. 13.53, Nebojša Ćirić <cira at google.com> је написао/ла:
# Nebojša Ćirić (15 years ago)

[cc es-discuss, it may be beneficial to others too]

Hi Rich, the initial strawman (including December version, which wasn't much different from original) was just a proposal that we put out there to get people to think about it. Only at the last (January) meeting we managed to get some consensus on what is feasible for most platforms. The current version has less features but we feel that it achieves the following:

  1. All involved parties can implement it with current data/APIs they have available (Windows OS, ICU...)
  2. Using LocaleInfo object on top avoids pollution of global namespace and makes passing locale methods/data around easier
  3. It still implements necessary i18n methods so that the API is usefull

We are planning on extending the API after this draft gets accepted and implemented. We feel it's going to be easier extending it in the future once we have a solid base to build upon.

I am sorry you started the implementation already, I wasn't aware anybody was trying to do that (Addison didn't mention it in the last teleconference call). I too have partial implementation of the old spec in Chrome (at least the locale part). I would wait with further implementations at least till March 21st, when we'll have our next i18n meeting.

If you run top of the tree Chromium (or maybe even dev channel Chromium) with enable-javascript-i18n-api flag you can actually test it. I'll be updating the implementation once we settle on details.

, Nebojša

  1. фебруар 2011. 11.44, Gillam, Richard <gillam at lab126.com> је написао/ла:
# Phillips, Addison (15 years ago)

I don’t think the point was “gee, we have to refactor our code”, which was to be expected in any event. More, the question was: why is everything pushed into this container? The previous “LocaleInfo” document (pre-phone call) seemed to imply that there would still be XXXFormat; my probably-imperfect understanding was that LocaleInfo would just be a container for locale information, perhaps similar to Microsoft’s CultureInfo. But the update makes it look like it contains “everything”.

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com] Sent: Thursday, February 17, 2011 12:02 PM To: Gillam, Richard Cc: es-discuss at mozilla.org Subject: Re: i18n objects

[cc es-discuss, it may be beneficial to others too]

Hi Rich, the initial strawman (including December version, which wasn't much different from original) was just a proposal that we put out there to get people to think about it. Only at the last (January) meeting we managed to get some consensus on what is feasible for most platforms. The current version has less features but we feel that it achieves the following:

  1. All involved parties can implement it with current data/APIs they have available (Windows OS, ICU...)
  2. Using LocaleInfo object on top avoids pollution of global namespace and makes passing locale methods/data around easier
  3. It still implements necessary i18n methods so that the API is usefull

We are planning on extending the API after this draft gets accepted and implemented. We feel it's going to be easier extending it in the future once we have a solid base to build upon.

I am sorry you started the implementation already, I wasn't aware anybody was trying to do that (Addison didn't mention it in the last teleconference call). I too have partial implementation of the old spec in Chrome (at least the locale part). I would wait with further implementations at least till March 21st, when we'll have our next i18n meeting. If you run top of the tree Chromium (or maybe even dev channel Chromium) with enable-javascript-i18n-api flag you can actually test it. I'll be updating the implementation once we settle on details.

, Nebojša

  1. фебруар 2011. 11.44, Gillam, Richard <gillam at lab126.com<mailto:gillam at lab126.com>> је написао/ла:

Forgive me, but would somebody mind (offline if you don't want to waste everybody else's time) bringing me up to speed on how we got here? I started implementing based on the strawman from early December (if memory serves), where there was no LocaleInfo, and by the time I was done with my implementation, the spec had changed completely and my code doesn't match it anymore. What problem does the LocaleInfo object solve?

--Rich Gillam Lab126

On Feb 15, 2011, at 1:53 PM, Nebojša Ćirić wrote:

Sorry it took me some time to get back to the document. I actually tried implementing the API just to see how it feels and I found a couple of problems with the implementation (see the latest at strawman:i18n_api).

Just to reiterate what we are aiming to do:

  1. There is a global LocaleInfo object that would hold the rest (collators, formatters...).
  2. Once we have LocaleInfo instance we shouldn't have to pass that into constructors (simplifies call sites, and allows us to pass locale around).

So this didn't work for me:

LocaleInfo = function(options) {...}; LocaleInfo.prototype.Collator = function(options) {...};

var locale = new LocaleInfo(); var collator = new LocaleInfo.Collator(); At the point where we call Collator() method this is already set to a new object and we have no access to the LocaleInfo data.

So I changed the design a little bit:

LocaleInfo = function(options) {...}; // same as before.

LocaleInfo.Collator = function(options, LocaleInfo locInfo) { does the real work here }; // new static on LocaleInfo class. LocaleInfo.Collator.prototype.derive = function ()...

LocaleInfo.prototype.collator = function(options) { return new LocaleInfo.Collator(options, this) }; // Here this refers to LocaleInfo and we just hide the complexity from the user.

If you all agree with this approach I would go ahead and write some samples on how to use this, and maybe a mock library to play with.

  1. јануар 2011. 17.31, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

I found that confusing to read. I know what you mean ‘cause I was on the call, but could you show and example for Creating LocaleInfo without inferred region?

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Friday, January 28, 2011 4:18 PM To: Mark Davis ☕ Cc: Shawn Steele; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Shawn, Richard, Mark, Jungshik, Addison and I had a teleconference call today about this issue and we managed to resolve the differences.

LocaleInfo object won't have special infer flag, but we will let user of the library specify which values shouldn't be inferred, by listing them at the construction time.

There are 3 cases (2 and 3 are the same except for the value passed to currency):

  1. Create LocaleInfo with locale only (en-US), currency and region are inferred to USD and US respectively.

  2. Create LocaleInfo with locale (en-US), currency:"XXX" -> Currency won't be inferred but region will.

  3. Create LocaleInfo with locale (en-US), currency:"EUR" -> Currency is set by user to EUR and region is inferred.

We would use standard undefined values for parameters (xx for region, und for language, XXX for currency). See LDML documentwww.unicode.org/reports/tr35/#Unknown_or_Invalid_Identifiers for details.

I will update strawman with new proposal.

  1. јануар 2011. 17.37, Mark Davis ☕ <mark at macchiato.com<mailto:mark at macchiato.com>> је написао/ла:

More explicitly, does anyone who wants to be in on this conversation not make Friday at 3:00 PT?

Mark

— Il meglio è l’inimico del bene — On Wed, Jan 26, 2011 at 17:06, Nebojša Ćirić <cira at google.com<mailto:cira at google.com>> wrote:

Ok, here are the teleconference details:

Name:

Nebojsa Ciric

International direct:

+1 617 224.4646tel:%2B1 617 224.4646

US Toll free:

1 866 457.4646tel:1 866 457.4646

Participant passcode:

15242605 then #

  1. јануар 2011. 16.57, Nebojša Ćirić <cira at google.com<mailto:cira at google.com>> је написао/ла:

I've removed the old content. It needs more work - like comments, some properties, return values, but the API is there as proposed in the last meeting.

Please edit if you find errors.

Shall we meet Friday, 3pm? I'll send details (bridge and pin) tomorrow. 26. јануар 2011. 16.17, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

Well, that seems to cover that issue, but the document in general is very divergent from the minimal surface area discussed last time. Also the LocaleInfo is missing, and it’s missing .derive (however we implement it).

-Shawn

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 4:13 PM To: Shawn Steele Cc: Mark Davis ☕; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

I made quick update - could you take a look if I captured the essentials (there are 2 proposals)?

strawman:i18n_api#proposal_1_shawns

I tried to get examples to show best and worst cases for both approaches - update if you can do worse :). 26. јануар 2011. 13.54, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

Ah, well. Hmmm. I was sort of assuming the caller would care if the data was valid and that the callee wouldn’t be making that kind of decision.

If we went with “infer-by-default”, then your scenario wouldn’t happen (S) unless the app really didn’t want inferring. In which case your workaround is the wrong thing to do (I’d think).

I really don’t want to double the surface, but I see your point about changing from uninferred to inferred.

-Shawn

From: mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com> [mailto:mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com>] On Behalf Of Mark Davis ?

Sent: Wednesday, January 26, 2011 1:51 PM To: Shawn Steele Cc: Nebojša Ćirić; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Your last message was illustrative.

From our perspective, the mainline service APIs (currency formatting, collation, etc.) should always return the best possible answer, with some way to determine whether or not the data was inferred or not in case someone cares (which is important, but definitely the lower-runner case). So writing from the point of view of implementing a service, we'll need to get the the best currency from a LocaleInfo. What your proposal forces us to do is something like Alternative S below, instead of Alternative M:

Alternative S:

theCurrency = inputLocaleInfo.region; // if we didn't get one, then the creator of the inputLocaleInfo set infer:false, so we have to work around that if (theCurrency == null) { myInputLocaleInfo = new LocalInfo({localeInfo:inputLocaleInfo, infer:true); theCurrency = myInputLocaleInfo.region; inferredCurrency = true; } else { inferredCurrency = false; }

Alternative M:

theCurrency = inputLocaleInfo.inferCurrency; inferredCurrency = inputLocaleInfo.region != null;

I think having a phone call will help to understand all the perspectives on the issue.

Mark

— Il meglio è l’inimico del bene — On Wed, Jan 26, 2011 at 13:27, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

I’m sorry, I missed part of the thread. I’d be happy if Nebojša would update the doc, and I’d be happy to participate in a call. (I can’t update it that fast).

Anytime is OK for me.

-Shawn

From: es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org> [mailto:es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org>] On Behalf Of Nebojša Ciric

Sent: Wednesday, January 26, 2011 1:07 PM To: Phillips, Addison Cc: Gillam, Richard; Shawn Steele; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal... 26. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Nebojša Ćirić (15 years ago)

We still have XXXFormat, it's just called LocaleInfo.XXXFormat thus reducing our impact on global namespace.

  1. фебруар 2011. 13.51, Phillips, Addison <addison at lab126.com> је написао/ла:
# Gillam, Richard (15 years ago)

Why is it important to minimize our impact on the global namespace? Is there precedent for this particular method of reducing impact on the global namespace, or is this intended to set a precedent? If the answer to both questions is no, why is i18n "special"?

--Rich Gillam Lab126

On Feb 17, 2011, at 2:14 PM, Nebojša Ćirić wrote:

We still have XXXFormat, it's just called LocaleInfo.XXXFormat thus reducing our impact on global namespace.

  1. фебруар 2011. 13.51, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

I don’t think the point was “gee, we have to refactor our code”, which was to be expected in any event. More, the question was: why is everything pushed into this container? The previous “LocaleInfo” document (pre-phone call) seemed to imply that there would still be XXXFormat; my probably-imperfect understanding was that LocaleInfo would just be a container for locale information, perhaps similar to Microsoft’s CultureInfo. But the update makes it look like it contains “everything”.

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Thursday, February 17, 2011 12:02 PM To: Gillam, Richard

Cc: es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

[cc es-discuss, it may be beneficial to others too]

Hi Rich, the initial strawman (including December version, which wasn't much different from original) was just a proposal that we put out there to get people to think about it. Only at the last (January) meeting we managed to get some consensus on what is feasible for most platforms. The current version has less features but we feel that it achieves the following:

  1. All involved parties can implement it with current data/APIs they have available (Windows OS, ICU...)
  2. Using LocaleInfo object on top avoids pollution of global namespace and makes passing locale methods/data around easier
  3. It still implements necessary i18n methods so that the API is usefull

We are planning on extending the API after this draft gets accepted and implemented. We feel it's going to be easier extending it in the future once we have a solid base to build upon.

I am sorry you started the implementation already, I wasn't aware anybody was trying to do that (Addison didn't mention it in the last teleconference call). I too have partial implementation of the old spec in Chrome (at least the locale part). I would wait with further implementations at least till March 21st, when we'll have our next i18n meeting. If you run top of the tree Chromium (or maybe even dev channel Chromium) with enable-javascript-i18n-api flag you can actually test it. I'll be updating the implementation once we settle on details.

, Nebojša

  1. фебруар 2011. 11.44, Gillam, Richard <gillam at lab126.com<mailto:gillam at lab126.com>> је написао/ла:

Forgive me, but would somebody mind (offline if you don't want to waste everybody else's time) bringing me up to speed on how we got here? I started implementing based on the strawman from early December (if memory serves), where there was no LocaleInfo, and by the time I was done with my implementation, the spec had changed completely and my code doesn't match it anymore. What problem does the LocaleInfo object solve?

--Rich Gillam Lab126

On Feb 15, 2011, at 1:53 PM, Nebojša Ćirić wrote:

Sorry it took me some time to get back to the document. I actually tried implementing the API just to see how it feels and I found a couple of problems with the implementation (see the latest at strawman:i18n_api).

Just to reiterate what we are aiming to do:

  1. There is a global LocaleInfo object that would hold the rest (collators, formatters...).
  2. Once we have LocaleInfo instance we shouldn't have to pass that into constructors (simplifies call sites, and allows us to pass locale around).

So this didn't work for me:

LocaleInfo = function(options) {...}; LocaleInfo.prototype.Collator = function(options) {...};

var locale = new LocaleInfo(); var collator = new LocaleInfo.Collator(); At the point where we call Collator() method this is already set to a new object and we have no access to the LocaleInfo data.

So I changed the design a little bit:

LocaleInfo = function(options) {...}; // same as before.

LocaleInfo.Collator = function(options, LocaleInfo locInfo) { does the real work here }; // new static on LocaleInfo class. LocaleInfo.Collator.prototype.derive = function ()...

LocaleInfo.prototype.collator = function(options) { return new LocaleInfo.Collator(options, this) }; // Here this refers to LocaleInfo and we just hide the complexity from the user.

If you all agree with this approach I would go ahead and write some samples on how to use this, and maybe a mock library to play with.

  1. јануар 2011. 17.31, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

I found that confusing to read. I know what you mean ‘cause I was on the call, but could you show and example for Creating LocaleInfo without inferred region?

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Friday, January 28, 2011 4:18 PM To: Mark Davis ☕ Cc: Shawn Steele; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Shawn, Richard, Mark, Jungshik, Addison and I had a teleconference call today about this issue and we managed to resolve the differences.

LocaleInfo object won't have special infer flag, but we will let user of the library specify which values shouldn't be inferred, by listing them at the construction time.

There are 3 cases (2 and 3 are the same except for the value passed to currency):

  1. Create LocaleInfo with locale only (en-US), currency and region are inferred to USD and US respectively.

  2. Create LocaleInfo with locale (en-US), currency:"XXX" -> Currency won't be inferred but region will.

  3. Create LocaleInfo with locale (en-US), currency:"EUR" -> Currency is set by user to EUR and region is inferred.

We would use standard undefined values for parameters (xx for region, und for language, XXX for currency). See LDML documentwww.unicode.org/reports/tr35/#Unknown_or_Invalid_Identifiers for details.

I will update strawman with new proposal.

  1. јануар 2011. 17.37, Mark Davis ☕ <mark at macchiato.com<mailto:mark at macchiato.com>> је написао/ла:

More explicitly, does anyone who wants to be in on this conversation not make Friday at 3:00 PT?

Mark

— Il meglio è l’inimico del bene — On Wed, Jan 26, 2011 at 17:06, Nebojša Ćirić <cira at google.com<mailto:cira at google.com>> wrote:

Ok, here are the teleconference details:

Name:

Nebojsa Ciric

International direct:

tel:%2B1 617 224.4646+1 617 224.4646tel:%2B1 617 224.4646

US Toll free:

tel:1 866 457.46461 866 457.4646tel:1 866 457.4646

Participant passcode:

15242605 then #

  1. јануар 2011. 16.57, Nebojša Ćirić <cira at google.com<mailto:cira at google.com>> је написао/ла:

I've removed the old content. It needs more work - like comments, some properties, return values, but the API is there as proposed in the last meeting.

Please edit if you find errors.

Shall we meet Friday, 3pm? I'll send details (bridge and pin) tomorrow. 26. јануар 2011. 16.17, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

Well, that seems to cover that issue, but the document in general is very divergent from the minimal surface area discussed last time. Also the LocaleInfo is missing, and it’s missing .derive (however we implement it).

-Shawn

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 4:13 PM To: Shawn Steele Cc: Mark Davis ☕; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

I made quick update - could you take a look if I captured the essentials (there are 2 proposals)?

strawman:i18n_api#proposal_1_shawns

I tried to get examples to show best and worst cases for both approaches - update if you can do worse :). 26. јануар 2011. 13.54, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

Ah, well. Hmmm. I was sort of assuming the caller would care if the data was valid and that the callee wouldn’t be making that kind of decision.

If we went with “infer-by-default”, then your scenario wouldn’t happen (S) unless the app really didn’t want inferring. In which case your workaround is the wrong thing to do (I’d think).

I really don’t want to double the surface, but I see your point about changing from uninferred to inferred.

-Shawn

From: mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com> [mailto:mark.edward.davis at gmail.com<mailto:mark.edward.davis at gmail.com>] On Behalf Of Mark Davis ?

Sent: Wednesday, January 26, 2011 1:51 PM To: Shawn Steele Cc: Nebojša Ćirić; Phillips, Addison; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Your last message was illustrative.

From our perspective, the mainline service APIs (currency formatting, collation, etc.) should always return the best possible answer, with some way to determine whether or not the data was inferred or not in case someone cares (which is important, but definitely the lower-runner case). So writing from the point of view of implementing a service, we'll need to get the the best currency from a LocaleInfo. What your proposal forces us to do is something like Alternative S below, instead of Alternative M:

Alternative S:

theCurrency = inputLocaleInfo.region; // if we didn't get one, then the creator of the inputLocaleInfo set infer:false, so we have to work around that if (theCurrency == null) { myInputLocaleInfo = new LocalInfo({localeInfo:inputLocaleInfo, infer:true); theCurrency = myInputLocaleInfo.region; inferredCurrency = true; } else { inferredCurrency = false; }

Alternative M:

theCurrency = inputLocaleInfo.inferCurrency; inferredCurrency = inputLocaleInfo.region != null;

I think having a phone call will help to understand all the perspectives on the issue.

Mark

— Il meglio è l’inimico del bene — On Wed, Jan 26, 2011 at 13:27, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> wrote:

I’m sorry, I missed part of the thread. I’d be happy if Nebojša would update the doc, and I’d be happy to participate in a call. (I can’t update it that fast).

Anytime is OK for me.

-Shawn

From: es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org> [mailto:es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org>] On Behalf Of Nebojša Ciric

Sent: Wednesday, January 26, 2011 1:07 PM To: Phillips, Addison Cc: Gillam, Richard; Shawn Steele; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

The es strawman was not updated with the recent discussion. I can do that before the call, and put both versions there. Shawn could check if my representation matches his proposal... 26. јануар 2011. 13.03, Phillips, Addison <addison at lab126.com<mailto:addison at lab126.com>> је написао/ла:

Sure.

Did someone update the docs? Where can we get at them?

Thanks,

Addison

Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature. It is an architecture.

From: Nebojša Ćirić [mailto:cira at google.com<mailto:cira at google.com>]

Sent: Wednesday, January 26, 2011 1:02 PM To: Shawn Steele Cc: Phillips, Addison; Mark Davis ☕; Gillam, Richard; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>

Subject: Re: i18n objects

Would people be interested in a teleconference call, say Friday to discuss this further (in case posting to the list doesn't resolve conflicts soon)? I can make the arrangements... 26. јануар 2011. 01.35, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:

A "common" pattern is to require some sort of data (like date format), even if you don't have enough information. The missing-data-so-end-up-at-root is a similar sort of scenario. "Many" applications have the information they provide. If we can't get a value from that, they're sunk because they cannot get more specific.

I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.

My problems with the inferred/not inferred pattern are:

  1. that the function actually doing the work may not be the function that "knows" if the data should be inferred or not. That may be the caller. So then all worker functions have to use the inferred form, which seems awkward. Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.

  2. Ok, so we have "both" forms. Then I call the base form, and it fails because it had bogus data. That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call. Or else the non-inferred functions need to throw.

  3. My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.

var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); // Should this require a "inferredFormat" ? That seems really heavy, but en-US and en-anywhere else have different default values.

It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help. It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.

-Shawn

  blogs.msdn.com/shawnste

# Nebojša Ćirić (15 years ago)

i18n API could potentially have large surface (look at ICU class list for example) - and we may collide with some of the existing libraries.

The other reason for one aggregate class was ease of passing locale and its methods around. In this case LocaleInfo is like a namespace and a container for a given locale. Also having this setup we don't have to pass locale object to various formatters, like

var locale = new Locale(locale stuff); var formatter = new DateFormatter(formatter specific stuff, locale);

Instead you do:

var locale = new LocaleInfo(locale stuff); var formatter = locale.dateFormatter(formatter specific stuff);

Both approaches are valid, but input from ecma script members was that they would prefer the new approach.

I'll be on vacation tomorrow, so I may be late replying to emails.

  1. фебруар 2011. 16.40, Gillam, Richard <gillam at lab126.com> је написао/ла: