i18n objects

Nebojša Ćirić cira at google.com
Tue Feb 15 13:53:44 PST 2011


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
http://wiki.ecmascript.org/doku.php?id=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.

28. јануар 2011. 17.31, Shawn Steele <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]
> *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 document<http://www.unicode.org/reports/tr35/#Unknown_or_Invalid_Identifiers>for details.
>
>
>
> I will update strawman with new proposal.
>
>
>
> 26. јануар 2011. 17.37, Mark Davis ☕ <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> wrote:
>
> Ok, here are the teleconference details:
>
>
>
> Name:
>
> *Nebojsa Ciric*
>
> International direct:
>
> * <+16172244646>+1 617 224.4646*
>
> US Toll free:
>
> * <+18664574646>1 866 457.4646*
>
> Participant passcode:
>
> *15242605 then #*
>
>
>
> 26. јануар 2011. 16.57, Nebojša Ćirić <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> је
> написао/ла:
>
>
>
> 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)?
>
>
>
> http://wiki.ecmascript.org/doku.php?id=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> је
> написао/ла:
>
> 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>
> 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] *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> је
> написао/ла:
>
> 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> је
> написао/ла:
>
> 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
>
>
>
>  
>
> http://blogs.msdn.com/shawnste
>
>
>    ------------------------------
>
> *From:* Phillips, Addison [addison at lab126.com]
> *Sent:* Tuesday, January 25, 2011 10:09 PM
> *To:* Shawn Steele; Mark Davis ☕
> *Cc:* es-discuss at mozilla.org; Gillam, Richard
> *Subject:* RE: i18n objects
>
> Hi,
>
>
>
> I’ve been following this thread carefully this week, thinking to chime in
> here or there (but not needing to so far).
>
>
>
> Is there a place where updated docs are accumulating? We’re nearly done
> with our squirrelfish implementation and I’m getting the feeling that it’s
> becoming non-standard ;-). 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>
> 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
>
>
>
>  
>
> http://blogs.msdn.com/shawnste
>
> (Selfhost 7908)
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Nebojša Ćirić
>
>
>
>
> --
> Nebojša Ćirić
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
>
> --
> Nebojša Ćirić
>
>
>
>
> --
> Nebojša Ćirić
>
>
>
>
> --
> Nebojša Ćirić
>
>
>
>
>
>
> --
> Nebojša Ćirić
>



-- 
Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110215/3d2c88c7/attachment-0001.html>


More information about the es-discuss mailing list