i18n objects

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


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...

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

> 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> <%2B1%20617%20224.4646>+1 617 224.4646*
>>
>> US Toll free:
>>
>> * <+18664574646> <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ć
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110215/67c663ab/attachment-0001.html>


More information about the es-discuss mailing list