(+es-discuss)<br><br>Hi Steven,<div> I've moved the discussion to the official es-discuss list. See my comments below.<br><br><div class="gmail_quote">12. септембар 2011. 14.52, Mark Davis ☕ <span dir="ltr"><<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>></span> је написао/ла:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font face="times new roman,serif">A few comments from my perspective.<br clear="all"></font><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px;font-family:Times;font-size:medium">

<span style="font-family:'times new roman', serif;font-size:small"><br></span></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px;font-family:Times;font-size:medium">

<span style="font-family:'times new roman', serif;font-size:small">Mark</span></div><i>— Il meglio è l’inimico del bene —</i></font><br>
<br><br><div class="gmail_quote"><div class="im">On Mon, Sep 12, 2011 at 14:13, Steven R. Loomis <span dir="ltr"><<a href="mailto:srl@icu-project.org" target="_blank">srl@icu-project.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hello Mark and Cira,<br>
<br>
  We discussed the proposal <<a href="https://docs.google.com/document/pub?id=1rsUxJQ03Ql6o3bh6RN7J81dtYZXE7OVsdQBw_h5ASnM&ndplr=1" target="_blank">https://docs.google.com/<u></u>document/pub?id=<u></u>1rsUxJQ03Ql6o3bh6RN7J81dtYZXE7<u></u>OVsdQBw_h5ASnM&ndplr=1</a>> a bit internally and came up with some response.  Please feel free to respond to me or as appropriate.<br>


<br>
Regards,<br>
Steven<br>
<br>
------------------------<br>
<br>
Response to ECMAScript/JavaScript i18n proposal.<br>
<br>
1. What are the target scenarios for this proposal? Where, how would it be used? How does it solve the problems outlined in section 4.2 of the proposal?<br></blockquote><div><br></div></div><div>Cira, I think it would be useful to add more of this information to the intro.</div>
</div></blockquote><div><br></div><div>I agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div><br></div><div>In short, ECMAScript i18n is seriously deficient, and there is widespread need for better ECMAScript support. You can't, for example, do something as simple as sort a list of user names on a page, or format a currency value.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. The results of globalization operations are not defined, if one implementation has different results from another, what problem is solved? It would be no better than what we have today.<br></blockquote><div><br></div>

</div><div>While it would be great to have precisely predictable results, typically it is sufficient to have reasonably good results from each browser. For example, even though for symbols and punctuation IE and ICU differ, they both sort (say) Serbian letters according to reasonable user expectations. So it is vastly better than code point order.</div>
</div></blockquote><div><br></div><div>The same problem exists with different versions of ICU. I agree with Mark, we are fine as long as you get locale acceptable result.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Collation tailoring is not addressed.<br></blockquote><div><br></div></div><div>True. Only a subset of the overall functionality is specified in the first release. The goal was to release useful functionality in a first release, and then follow up with more functionality later (eg break-iterators, etc.)</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4. Comments show the desire for a Globalization namespace, what is the reason for this?  Why not hang the services off objects that have the desired functoin,  such as String.collator (or 'new String.Collator()'), Date.format, Number.format etc?<br>

</blockquote><div><br></div></div><div>These are the results of a number of discussions and compromises over time in the working group.</div></div></blockquote><div><br></div><div>There are couple reasons:</div><div><br>
</div><div>1. Decouple our work from main EcmaScript body and make API more like a library or ES6 module.</div><div>2. Limit conflicts with existing code</div><div>3. Future expandability - would you hang message/plural formatting on string class? What about Calendar?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
5. Using special objects is not JavaScript-like. Why isn't LocaleList a simple array, with functions which manipulate it?<br></blockquote><div><br></div></div><div>The reason is that it does have specific semantics, and allows for the validation of the list one time, instead of repeating it.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
6. Why isn't there any discovery of the default locale? Suggestion, expose HTTP "accept-language" as a LocaleList.<br></blockquote><div><br></div></div><div>A target is for web applications that need to be able to set the locale independently of the AL. (I thought we did have a way to get the AL as a LocaleList, Cira. Did that disappear, or am I misremembering.)</div>
</div></blockquote><div><br></div><div>There were problems with defining default locale:</div><div>1. Not all platforms are browser based (client apps, servers)</div><div>2. Application developer should detect user language and pass it to the API (see <a href="http://stackoverflow.com/questions/1043339/javascript-for-detecting-browser-language-preference">http://stackoverflow.com/questions/1043339/javascript-for-detecting-browser-language-preference</a> - JavaScript can't access acceptLanguage list) - but we could potentially get navigator.language at some point.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
7. Does not specify what behavior is where no locale is given.<br></blockquote><div><br></div></div><div>As I recall, there are vendors that do not want to be required to provide particular behavior if no locale is set.</div>
<div class="im"><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
8. We are concerned about a client environment simulating a different locale than the one the user has specified (at the desktop level). For example, new with a locale of "ja-JP" may have different results than new() [ default locale ] if the default locale is ja-JP, IF the user has customized their locale through a control panel.  Server side JavaScript would be a different situation, however.<br>

</blockquote><div><br></div></div><div>That is one of the goals, to allow use of a different locale.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
9. No Parsing capability, just formatting.<br></blockquote><div><br></div></div><div>Yes, known limitation (see #3). Formatting is a much higher-frequency operation than parsing.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
10. No way to format dates/numbers based on a pattern.<br></blockquote><div><br></div></div><div>Yes, known limitation (see #3).</div></div></blockquote><div><br></div><div>We actually had it, and I don't think it was #3 that cut it out. We just felt that pattern format is not very user friendly and that skeleton as JSON object expresses the meaning much better. It may be more verbose than dense ICU pattern but it may be easier for web developer to digest.</div>
<div>I think that ActionScript incorporated similar solution with collation for example (preset, easy to understand enums vs strenght).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
11. Overall this proposal seems to be much scaled back from the earlier proposals. Please comment on the planned future direction.<br></blockquote><div><br></div></div><div>See #3 </div></div><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Nebojša Ćirić<br>
</div>