Would someone be willing to champion pluralization support?

[Domenic Denicola]

Hi all,

I'm here to forward a concern from the V8 and Chrome teams, which originally came up in https://code.google.com/p/chromium/issues/detail?id=481718. We were frustrated that, while ICU includes pluralization support, that was not included in Ecma 402. As such, we were hoping to get an update on whether this would be a priority for you all with regard to the next edition? Has this perhaps been considered in the past but dropped?

Thanks very much for your consideration,

-Domenic

[Nebojša Ćirić]

Hi,
 there are couple of proposals in ecmascript.org wiki (http://wiki.ecmascript.org/doku.php?id=globalization:messageformatting).

 I don't think anybody is actively driving this at this moment.

Nebojsa

--
You received this message because you are subscribed to the Google Groups "JavaScript Globalization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javascript-globali...@googlegroups.com.
To post to this group, send email to javascript-g...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/17328bff-ec4e-4184-b9b1-c5ec44a21e30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nebojša Ćirić]

Btw. Closure has plural/gender support that matches syntax of ICU - http://docs.closure-library.googlecode.com/git/local_closure_goog_i18n_messageformat.js.source.html.

It does not support date/number formatting in the parameters, but you can do that using Intl.DateFormat for example.

[Domenic Denicola]

Yeah, exactly; the motivation here is to avoid having to drag in Closure or similar libraries given that browsers already ship ICU.

[Alex Sexton]

I have been in very recent discussions with Eric Ferraiuolo and Caridy Patiño (currently away) about trying to formalize ICU MessageFormat in some way.

I built https://github.com/SlexAxton/messageformat.js and they built http://formatjs.io/ (which probably makes up most of the ICU MessageFormat users outside of Google Closure) - and we have some cross-over of ideas concerning messageformat.

We spoke on the phone about 2 weeks ago and decided to see if we could approach the list about creating a more official grammar/specification for messageformat so we could consider it in ECMA402. As far as we know, there are really only implementations of ICU MessageFormat (in C and Java), and not really and formal specification outside a few comments in the code and on the website.

Our end goal would be to either formally specify MessageFormat separately, and have ECMA 402 reference that specification (much like how JSON works these days). Or to specify some minimally agreeable behavior directly into 402.Next. Additionally, we had a strong desire to specify and/or strongly recommend the AST for parsers so there could be a strong portability between implementations.

My first task was to write to this list to get feedback on these ideas and see if anyone had input/hatorade, etc. - but it seems I've been beat (thnx domenic).

Thoughts? Concerns? Know people who work on The Real MessageFormat™ specs and think they'd hate us for doing this/work with us?

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/CY1PR0501MB13690378A0CDFCC728E6C268DFD50%40CY1PR0501MB1369.namprd05.prod.outlook.com.

[Nebojša Ćirić]

Adding Jungshik (he is the author of the chromium bug that was referred to in the thread).

[Eric Ferraiuolo]

Domenic, thanks for bringing this up. As Alex mentioned, we’ve been talking about this, and we want Message Format support in ECMAScript.

Since ICU Message syntax provides a declarative way to format messages/strings, I think it’s important to have low-level APIs supporting its argument types: number, date, time, select, plural, selectordinal, etc.

As we know, today, ECMA-402 defines APIs Intl.NumberFormat and Intl.DateTimeFormat that back the `number`, `date`, and `time` ICU Message syntax argument types. Arguably, `select` desugars to a `switch` statement (this is actually how we describe it in FormatJS). What’s missing is an imperative API to back `plural` and `selectordinal` argument types.

Many of us are using Eemeli’s make-plural package internally in our i18n libs which given a number and an option for cardinal or ordinal, it returns one of: “zero”, “one”, “two”, “few”, “many”, or “other”. So I wondering if we should also standardize this functionality on `Intl` as well?

A super rough plural API might be used like this:

var cardinal = new Intl.PluralFormat(‘en’, {style: ‘cardinal’});

console.log(cardinal.format(0)); // “other”

console.log(cardinal.format(1)); // “one”

console.log(cardinal.format(2)); // “other”

var ordinal = new Intl.PluralFormat(‘en’, {style: ‘ordinal’});

console.log(ordinal.format(11)); // “one”

console.log(ordinal.format(22)); // “two”

console.log(ordinal.format(33)); // “few”

console.log(ordinal.format(44)); // “other”

Maybe better would be returning a known Symbol since the potential return values are finite?

This low-level Intl.PluralFormat API could then be used along with Intl.NumberFormat and Intl.DateTimeFormat to back a higher-level ICU Message Format API.

Thoughts?

Eric

[Rafael Xavier]

This low-level Intl.PluralFormat API could then be used along with Intl.NumberFormat and Intl.DateTimeFormat to back a higher-level ICU Message Format API.

+1.

What about having one proposal for Intl.PluralFormat and another for Intl.MessageFormat submitted to https://github.com/tc39/ecma402 (as two separate PRs), where we could discuss its API details?

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/5F66F4DB-05D7-48CF-B48D-05BA3FF186EB%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

+55 (16) 98138-1583, +1 (415) 568-5854, skype: rxaviers
http://rafael.xavier.blog.br

[Steven R. Loomis]

Will reply more soon, but I'd see plural and message format as being tied together. Also I'd like to keep it something Icu compatible. 

S

Enviado desde nuestro iPhone.

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/CADdLYsoqqur1RchKAD_toV1dMtiGP4F5FkKfF92w_LMSR0J4Zw%40mail.gmail.com.

[Tingan Ho]

I think any use cases for getting a plural category would be in message formatting. So I doubt it makes sense to make a public Intl.PluralFormat since a future Intl.MessageFormat already deals with plural category handling.

FWIW, I think the current Strawman draft of Intl.MessageFormat is just an object notation syntax of ICU's MessageFormat's syntax. I still think it is a little bit easier with staying with the current ICU's MessageFormat's syntax, since it was designed so that non-programmers could write those. Letting people learn JS objects on top of ICU's MessageFormat is a slightly worser deal as oppose to learning ICU's MessageFormat alone. It is better to keep the current ICU's MesageFormat's syntax and not add any JS objects into it — to keep a message format syntax standardized across programming languages. 

I don't know if anyone else have noticed this inconsistency in ICU MessageFormat's type-of-format keywords:

select, plural, selectordinal and not selectword, selectplural, selectordinal or just word, plural, ordinal. (Having only the "select" keyword is too ambiguous too)

It would be good if this inconsistency is fixed in any future Intl.MessageFormat.

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/055605B7-CDD9-4077-999F-CD032211F2A1%40icu-project.org.

For more options, visit https://groups.google.com/d/optout.

--

Sincerely,

Tingan Ho

@tingan87

[Domenic Denicola]

Eric, this sounds really good. I think this kind of incremental step (Intl.PluralFormat) would make a lot of sense, since Alex’s more ambitious plan of specifying MessageFormat seems like a large dependency to introduce. Getting pluralization support into the hands of users sooner would be truly great.

 

> Maybe better would be returning a known Symbol since the potential return values are finite?

 

No, a string is much better for JS enums. Symbols should only be used to prevent collision with future author-defined properties.

--
You received this message because you are subscribed to a topic in the Google Groups "JavaScript Globalization" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/javascript-globalization/3nFDf5al5hU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to javascript-globali...@googlegroups.com.

To post to this group, send email to javascript-g...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/5F66F4DB-05D7-48CF-B48D-05BA3FF186EB%40gmail.com.

[zbran...@mozilla.com]

Thanks for bringing this up. Plural formatter would be extremely useful and help all localization frameworks, so it feels like a great middle step between not doing anything and hardcoding a single solution.

On Sunday, May 3, 2015 at 4:44:20 AM UTC-7, Domenic Denicola wrote:

Eric, this sounds really good. I think this kind of incremental step (Intl.PluralFormat) would make a lot of sense, since Alex’s more ambitious plan of specifying MessageFormat seems like a large dependency to introduce. Getting pluralization support into the hands of users sooner would be truly great.

 

 Exactly. MessageFormat in its current form is not very appealing for Mozilla, but I believe it will be a good inspiration for future localization frameworks. Localization is a very complex topic and I don't believe we have got to the point where any of the currently available frameworks is worth standardizing into the language, but we can identify smaller pieces that are needed for all of them and focus on those.

zb.

[Eric Ferraiuolo]

I’m up for helping to formalize my proposal in this thread. I can work on it next week at the TC39 meeting.

I see one major API decision to work out, and that’s whether we want `.format(number)` to return one the discrete ICU plural category strings: “zero”, “one”, “two”, “few”, “many”, or “other” and require the developer to `switch` on that value, or if we want to have the constructor take these as options and do the switch/selection internally.

1) new Intl.PluralFormat(‘en-US’).format(100); // => “other”

vs.

2) new Intl.PluralFormat(‘en-US’, {

    one: ‘comment’,

    other: ‘comments’

}).format(100); // => “comments”

#1 would be more flexible and lower level, but #2 is probably closer to the majority use-case of selecting the correct string “label”.

Thoughts?

Eric

[Alex Sexton]

On Wed, Sep 16, 2015 at 1:55 PM Eric Ferraiuolo <eferr...@gmail.com> wrote:

I’m up for helping to formalize my proposal in this thread. I can work on it next week at the TC39 meeting.

I see one major API decision to work out, and that’s whether we want `.format(number)` to return one the discrete ICU plural category strings: “zero”, “one”, “two”, “few”, “many”, or “other” and require the developer to `switch` on that value, or if we want to have the constructor take these as options and do the switch/selection internally.

1) new Intl.PluralFormat(‘en-US’).format(100); // => “other”

vs.

2) new Intl.PluralFormat(‘en-US’, {

    one: ‘comment’,

    other: ‘comments’

}).format(100); // => “comments”

#1 would be more flexible and lower level, but #2 is probably closer to the majority use-case of selecting the correct string “label”.

Thoughts?

(accidentally replied to just Eric, sorry Eric)

I like both of these so much :D.

I normally lean towards the more low-level api, but it actually feels like maybe just two features that would both be supported (by the nature of needing the first in order to implement the second), and that the second is the better default.

So #2 would remain as is, and #1 would look more like:

let enPluralFormatter = new Intl.PluralFormat('en-US');

enPluralFormatter.getPluralizationKey(100); // =>  "other"

 

I don't think the output of "other" matches with the expectations of a method called "format" anyways.

If we're afraid of that, we could also follow the DateTimeFormat cue of `resolvedOptions()` exposing the key we used on a given number. But that feels messier for not great reasons.

[zbran...@mozilla.com]

On Wednesday, September 16, 2015 at 11:55:45 AM UTC-7, Eric Ferraiuolo wrote:

I’m up for helping to formalize my proposal in this thread. I can work on it next week at the TC39 meeting.

I see one major API decision to work out, and that’s whether we want `.format(number)` to return one the discrete ICU plural category strings: “zero”, “one”, “two”, “few”, “many”, or “other” and require the developer to `switch` on that value, or if we want to have the constructor take these as options and do the switch/selection internally.

1) new Intl.PluralFormat(‘en-US’).format(100); // => “other”

vs.

2) new Intl.PluralFormat(‘en-US’, {

    one: ‘comment’,

    other: ‘comments’

}).format(100); // => “comments”

#1 would be more flexible and lower level, but #2 is probably closer to the majority use-case of selecting the correct string “label”.

I would prefer 1). My reasoning is that you can easily create 2 out of 1, but getting to 1 out of 2 is non-trivial.

Another reason is that not all technologies will want a simple one-dimensional string branching - we use multilevel, and 2) doesn't fit into this too much (we may branch on plural, then gender, then something else).

So bare to the bones CLDR plural resolution with integer on the input and plural variant on the output seems to be the most versatile and whoever wants 2, can wrap it easily.

I opened github issue with your proposal: https://github.com/tc39/ecma402/issues/34

I'd be happy to help with this.

Thanks,
zb.

[Alex Sexton]

On Wed, Sep 16, 2015 at 2:47 PM <zbran...@mozilla.com> wrote:

On Wednesday, September 16, 2015 at 11:55:45 AM UTC-7, Eric Ferraiuolo wrote:

I’m up for helping to formalize my proposal in this thread. I can work on it next week at the TC39 meeting.

I see one major API decision to work out, and that’s whether we want `.format(number)` to return one the discrete ICU plural category strings: “zero”, “one”, “two”, “few”, “many”, or “other” and require the developer to `switch` on that value, or if we want to have the constructor take these as options and do the switch/selection internally.

1) new Intl.PluralFormat(‘en-US’).format(100); // => “other”

vs.

2) new Intl.PluralFormat(‘en-US’, {

    one: ‘comment’,

    other: ‘comments’

}).format(100); // => “comments”

#1 would be more flexible and lower level, but #2 is probably closer to the majority use-case of selecting the correct string “label”.

I would prefer 1). My reasoning is that you can easily create 2 out of 1, but getting to 1 out of 2 is non-trivial.

I'm fine leaving #2 out, but I don't think `format` is the right name for a function that returns a pluralization key.

 

Another reason is that not all technologies will want a simple one-dimensional string branching - we use multilevel, and 2) doesn't fit into this too much (we may branch on plural, then gender, then something else).

At this point it's full MessageFormat again (or similar), right?

[zbran...@mozilla.com]

On Wednesday, September 16, 2015 at 12:54:11 PM UTC-7, Alex Sexton wrote:

I'm fine leaving #2 out, but I don't think `format` is the right name for a function that returns a pluralization key.

Agree.

Intl.PluralForm(navigator.languages).resolve(100)

?
 

 

Another reason is that not all technologies will want a simple one-dimensional string branching - we use multilevel, and 2) doesn't fit into this too much (we may branch on plural, then gender, then something else).

At this point it's full MessageFormat again (or similar), right?

Sort of. MessageFormat is one of the approaches, that ICU champions, but I believe that there's room for a better one (or several) and I expect to see a new generation of localization libraries to come to life soon, compete for a while, and maybe then we'll get something worth standardizing.

PluralForm is required for all of them, and having it in Intl would lower the barrier for them. But another lesson from my analysis of our Firefox OS project is that we have cases where we need to get plural form outside of localization strings. Solution #1 would give both raw JS, and l10n libraries a good base.

We could also evaluate a merged approach, based on #1, but with ability to perform #2. For example:

var f = Intl.PluralForm(navigator.languages);

f.resolve(100); // 'other'
f.format(100, {
  one: 'comment',
  other: 'comments'
}); // 'comments'

zb.

[Alex Sexton]

This feels like it's a nice API surface. It covers the by-far-most-common use-case, and allows for people to build more complex systems with the primitives.

Feels weird to require people to write out this same boilerplate in all of their applications:

```js

Intl.PluralForm.prototype.format = function(number, choices = {}) {

  return choices[this.format(number)];

};

```

 

zb.

--
You received this message because you are subscribed to the Google Groups "JavaScript Globalization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javascript-globali...@googlegroups.com.
To post to this group, send email to javascript-g...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/54790cf5-a61d-48fe-ab2d-5b722e07f219%40googlegroups.com.

[Alex Sexton]

On Wed, Sep 16, 2015 at 3:07 PM Alex Sexton <alexs...@gmail.com> wrote:

On Wed, Sep 16, 2015 at 3:01 PM <zbran...@mozilla.com> wrote:

On Wednesday, September 16, 2015 at 12:54:11 PM UTC-7, Alex Sexton wrote:

I'm fine leaving #2 out, but I don't think `format` is the right name for a function that returns a pluralization key.

Agree.

Intl.PluralForm(navigator.languages).resolve(100)

?
 

 

Another reason is that not all technologies will want a simple one-dimensional string branching - we use multilevel, and 2) doesn't fit into this too much (we may branch on plural, then gender, then something else).

At this point it's full MessageFormat again (or similar), right?

Sort of. MessageFormat is one of the approaches, that ICU champions, but I believe that there's room for a better one (or several) and I expect to see a new generation of localization libraries to come to life soon, compete for a while, and maybe then we'll get something worth standardizing.

PluralForm is required for all of them, and having it in Intl would lower the barrier for them. But another lesson from my analysis of our Firefox OS project is that we have cases where we need to get plural form outside of localization strings. Solution #1 would give both raw JS, and l10n libraries a good base.

We could also evaluate a merged approach, based on #1, but with ability to perform #2. For example:

var f = Intl.PluralForm(navigator.languages);

f.resolve(100); // 'other'
f.format(100, {
  one: 'comment',
  other: 'comments'
}); // 'comments'

This feels like it's a nice API surface. It covers the by-far-most-common use-case, and allows for people to build more complex systems with the primitives.

Feels weird to require people to write out this same boilerplate in all of their applications:

```js

Intl.PluralForm.prototype.format = function(number, choices = {}) {

  return choices[this.format(number)];

};

```

Then again, looking at this function, 'format' may still be the wrong name. It's not really doing anything involving formatting. Perhaps if it was mixed with NumberFormat somehow at this point...

enPluralForm.format(100, {style: 'percentage', maximumFractionDigits: 0}, {one: ...});

 

But I'm not necessarily proposing that... seems much more high-level than these other things.

[Eemeli Aro]

On 16 September 2015 at 23:01, <zbran...@mozilla.com> wrote:

Intl.PluralForm(navigator.languages).resolve(100)

One important aspect to keep in mind here is that there are ordinal as well as cardinal plurals that should be supported, and that they have different categorisations. A single "PluralForm" or "resolve" or "format" without some form of qualifier is going to make later support for ordinals difficult.

[Caridy Patino]

The fact that we will be able to reuse the instance is enough reason for me to choose 1. lets remember that creating instances of intl stuff is usually an expensive operation. in the case of #2 we will have to create new instances for every combination of labels.

/caridy

[Alex Sexton]

On Wed, Sep 16, 2015 at 4:57 PM Caridy Patino <car...@gmail.com> wrote:

The fact that we will be able to reuse the instance is enough reason for me to choose 1. lets remember that creating instances of intl stuff is usually an expensive operation. in the case of #2 we will have to create new instances for every combination of labels.

I hadn't considered the reuse. Well stated.

[Caridy Patiño]

Ok guys, finally got a chance to work on this, here is the initial proposal flush out:

https://github.com/caridy/intl-plural-form-spec

The generated spec [draft] is here:

https://rawgit.com/caridy/intl-plural-form-spec/master/index.html

I will work with @ericf next week for formalize the proposal, get the polyfill ready and to see if we can formally presented (if we get a chance to add it to the agenda, which I doubt).

/caridy

[Eemeli Aro]

On 20 September 2015 at 01:01, Caridy Patiño <car...@gmail.com> wrote:
> Ok guys, finally got a chance to work on this, here is the initial proposal
> flush out:
>
> https://github.com/caridy/intl-plural-form-spec
>
> The generated spec [draft] is here:
> https://rawgit.com/caridy/intl-plural-form-spec/master/index.html
>
> I will work with @ericf next week for formalize the proposal, get the
> polyfill ready and to see if we can formally presented (if we get a chance
> to add it to the agenda, which I doubt).

Something I just realised: in section 1.3.4, PluralRules#select()
casts its input to Number before passing it to ResolvePlural, which
then returns a string representing the plural form of the input. That
cast to Number should not be there, and ResolvePlural should be able
to accept String as well as Number input. This is because the plural
category of e.g. 1 is different from the plural category of 1.0 in
many languages, including for instance English (1 is "one", 1.0 is
"other"), and string representation is the only way to determine that.

A second question: the sets of locales for which ordinal and cardinal
plural rules are available in the CLDR are not the same. In 1.1.1,
InitializePluralRules first looks for the locale in
[[availableLocales]], and only then resolves the ordinal/cardinal
"style" of the given options. What is the resulting behaviour for
languages for which cardinal rules are available, but ordinal rules
are not?


eemeli

[Eric Ferraiuolo]

GH issue link for this feedback: https://github.com/caridy/intl-plural-rules-spec/issues/1

> --
> You received this message because you are subscribed to the Google Groups "JavaScript Globalization" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to javascript-globali...@googlegroups.com.
> To post to this group, send email to javascript-g...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/CAFuwTa5_a9aQ9OU95mbQanisJQ%2BL48_irSe63hwDpDxDDBb7Jg%40mail.gmail.com.

[Jungshik Shin]

On Saturday, September 19, 2015 at 3:01:18 PM UTC-7, Caridy Patiño wrote:

Ok guys, finally got a chance to work on this, here is the initial proposal flush out:

https://github.com/caridy/intl-plural-form-spec

Thank you for drafting the spec. 

I wonder if it's possible to add an 'end-to-end' usage example to format messages with plural to README.md.   e.g. what steps should be taken to  get a result equivalent to the following ICU example? 

      "{num_people, plural, "

      "=0 {I met nobody in {place}.}"

      "=1 {I met a person in {place}.}"

      "other {I met # people in {place}.}}")

I'm aware that this spec has a very specific (narrow) scope on purpose, but I think it's not a bad idea to think about how this can be integrated with a translation process and resource bundle handling. 

Jungshik 

P.S. 

FYI, for Chrome's (internal) use (web UI), I'm considering supporting ICU message format.  

Another FYI, has anybody seen this ? https://github.com/yahoo/intl-messageformat (or has it been mentioned in the thread already? )

[Alex Sexton]

On Wed, Sep 23, 2015 at 4:47 PM Jungshik Shin <jshi...@gmail.com> wrote:

On Saturday, September 19, 2015 at 3:01:18 PM UTC-7, Caridy Patiño wrote:

Ok guys, finally got a chance to work on this, here is the initial proposal flush out:

https://github.com/caridy/intl-plural-form-spec

Thank you for drafting the spec. 

I wonder if it's possible to add an 'end-to-end' usage example to format messages with plural to README.md.   e.g. what steps should be taken to  get a result equivalent to the following ICU example? 

      "{num_people, plural, "

      "=0 {I met nobody in {place}.}"

      "=1 {I met a person in {place}.}"

      "other {I met # people in {place}.}}")

I'm aware that this spec has a very specific (narrow) scope on purpose, but I think it's not a bad idea to think about how this can be integrated with a translation process and resource bundle handling. 

The limited scope would mean that the parsing, and bundling of something like ICU Messageformat would still be the job of a library, but that the pluralization data would not need to be hard-coded into the delivered library.

As one of the authors of messageformat.js - which implements the functionality that you've got above - we use make-plural.js to parse and generate javascript functions out of CLDR data. The effect on our library would be that the make-plural library would no longer be necessary, and that we could use the built-in functions instead (once support was high enough).

[0] https://github.com/SlexAxton/messageformat.js

[1] https://github.com/eemeli/make-plural.js

 

Jungshik 

P.S. 

FYI, for Chrome's (internal) use (web UI), I'm considering supporting ICU message format.  

Another FYI, has anybody seen this ? https://github.com/yahoo/intl-messageformat (or has it been mentioned in the thread already? )

:D

Caridy, who wrote the proposal you're replying to, is one of the authors of intl-messageformat at Yahoo. It's a very good library.

 

 

The generated spec [draft] is here:

https://rawgit.com/caridy/intl-plural-form-spec/master/index.html

I will work with @ericf next week for formalize the proposal, get the polyfill ready and to see if we can formally presented (if we get a chance to add it to the agenda, which I doubt).

/caridy

On Friday, May 1, 2015 at 6:16:37 AM UTC-7, Domenic Denicola wrote:

Hi all,

I'm here to forward a concern from the V8 and Chrome teams, which originally came up in https://code.google.com/p/chromium/issues/detail?id=481718. We were frustrated that, while ICU includes pluralization support, that was not included in Ecma 402. As such, we were hoping to get an update on whether this would be a priority for you all with regard to the next edition? Has this perhaps been considered in the past but dropped?

Thanks very much for your consideration,

-Domenic

--

You received this message because you are subscribed to the Google Groups "JavaScript Globalization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javascript-globali...@googlegroups.com.
To post to this group, send email to javascript-g...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/89c9d4a7-c653-4e80-a8ae-f4c85d3579cc%40googlegroups.com.

[Caridy Patiño]

inline...

On Sep 22, 2015, at 5:27 PM, Jungshik Shin (신정식, 申政湜) <js...@chromium.org> wrote:

f.resolve(100); // 'other'

f.format(100, {

  one: 'comment',

  other: 'comments'

}); // 'comments'

With the above approach, I wonder what messages in source language and target languages would look like.  Up to 6 separate messages? Out of which a the following can be built.   

we are focus on the low level api for now: `rt.select(10) // yields “other”`, and then we can focus on formatting messages, and more advanced use cases.

{

  one: 'a person attended',

  other: '{num_person} people attended'

}

Chrome used to have a 6-string approach, but we switched to a single message approach (used by Android and other Google products) with ICU message format.

FYI, for Chrome's (internal) use (web UI), I'm considering supporting ICU message format.  

Great, that makes things easier.

Another FYI, has anybody seen this ? https://github.com/yahoo/intl-messageformat (or has it been mentioned in the thread already? )

Yes, we know about that one, we wrote it jajajaja.

/caridy

[Caridy Patiño]

UPDATE: This proposal has advanced to stage 1, details here: https://github.com/caridy/intl-plural-rules-spec

[Rafael Xavier]

Great job!

On Mon, Nov 23, 2015 at 2:27 PM, Caridy Patiño <car...@gmail.com> wrote:

UPDATE: This proposal has advanced to stage 1, details here: https://github.com/caridy/intl-plural-rules-spec

--

You received this message because you are subscribed to the Google Groups "JavaScript Globalization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javascript-globali...@googlegroups.com.
To post to this group, send email to javascript-g...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/f53f3ef5-5efc-4ac6-a917-60c62d03404c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

+55 (16) 98138-1583, skype: rxaviers
http://rafael.xavier.blog.br