i18n objects

Ok, here are the teleconference details:
Name:*Nebojsa Ciric*International direct:*+1 617 224.4646 <tel:+16172244646>
*US Toll free:*1 866 457.4646 <tel:+18664574646>**
*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ć
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110126/055f026e/attachment-0001.html>