i18n objects

Nebojša Ćirić cira at google.com
Thu Feb 17 14:14:14 PST 2011


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

17. фебруар 2011. 13.51, Phillips, Addison <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]
> *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.
>
>
>
> Regards,
>
>  Nebojša
>
>
>
> 17. фебруар 2011. 11.44, Gillam, Richard <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
> 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:
>
> * <%2B1%20617%20224.4646>+1 617 224.4646*
>
> US Toll free:
>
> * <1%20866%20457.4646>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ć
>
>
>
>
>
>
> --
> Nebojša Ćirić
>



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


More information about the es-discuss mailing list