Bugzilla

> We're having an impact on which languages get rich JS apps written for them. Say a project contemplates to write an app in Tatar, and then see that neither Chrome, nor Edge, nor Firefox support that.

I don't think this is a good representation of the Web reality.

> I'm pretty sure that we shouldn't let Google make that decision for us. I really don't like the idea of being stuck with a decision Google made a couple of months ago going forward.

I understand this concern.
First, if you have an idea how to select the whitelist which is better from our perspective, I'd prefer to use that.
Second, I think we should separate out the concern of "SpiderMonkey Intl" which is the question of what functionality the Platform provides to the Web, from the question of "Firefox Intl" which is the question of what internationalization capabilities the Platform provides to Firefox for its intl/l10n needs. The platform serves those two "customers".

I requested your r? in the latter capacity, and I think the conversation is straying to focus on the former.

I believe the former is important, and we should hold the conversation, and I see you as a stakeholder in it, but I'd like to also learn from you whether there is a concern about this change from the "Firefox L10n" perspective, or just "Gecko Intl" perspective.

> To look at it from a different angle, how should we respond when a language community approaches us (e.g. files a bug) saying "Firefox i18n doesn't support our language, please fix it so we can have sites/apps that work properly for lang=xyz"?

The Web supports some set of locales, and the Web Reality dictates which of those locales can reliably be used and expected to work for most customers.
Intl capabilities of the platform are intentionally designed to be "best-effort" and fallback in case of missing data aiming to be transparent from the developer perspective, and provide user with as good of a formatted output as the data we ship allows, so it's not "breaking" the Web for them.
The locales I'm suggesting to exclude cannot currently expect their software to be internationalized relying on the ECMA402 due to lack of support in other web browsers.
So, we effectively ship that data to every single user, for an edge scenario where some web application wants to serve one of the minority locales and only cares about Firefox.

> I think the proper response ought to be simply "submit your language's data to CLDR, and then it'll work in Firefox". But that's only an adequate response if we're committed to including all the languages for which CLDR provides data. 

The commitment is a bit more complicated, and this issue is a good example of that complexity.

We have a limited budget for the internationalization data we can carry. We want to add an important set of data - `Intl.DisplayNames` - which, among others, will enable one of the more popular requests on the Web - a language selector - to be available at a lower per-website payload cost to all our users. It means that in a vast majority scenario, the net outcome of this change bundled with bug 1557727 will be the barrier for adding a localized language switcher will drop significantly lowering the barrier to make websites multilingual and making JS/Web platform a better platform for internationalized software.

To "pay" for that, we are considering removing support for locales such as Tasawaq (tsq) spoken by ~2,000-10,000 people in the World.

You're pointing out, and I agree with that, that in the ideal world, we should support Tasawaq, rather than not support it. But I'd argue that in reality, the odds that a Tasawaq speaker will actually benefit from us supporting their language in Gecko JS Intl, while no other browser does, is slim.
On the other hand, the benefit of bringing `Intl.DisplayNames` to even top 30 locales is major, and we are suggesting to bring it to 400 locales.

Finally, unless we accept an unlimited growth of our binary size from ICU data, we should also consider the cost of not supporting `Intl.DisplayNames` for the top 400 locales in the presence of other web engines supporting it [0] for our ability to compete and retain users and web developer community good will necessary to remain relevant and be able to enable multilingual Web at all.

From the platform perspective, we will have such tradeoffs to make in the future, this is just the first one.

For another example, we had to hold a similar conversation about the support list of units in `Intl.NumberFormat` [1]. In result of that, we initially don't support at all units such as `gallon`, `liter`, `calorie`, `lux`, `megahertz`, `milligram`, `ton`, `radian`, `volt` and `watt`.
This, in turn, increases the barrier for webapps to provide internationalized support for UIs that would benefit from those, resulting in either more non-internationalized websites, or higher cost of loading a website that ships all the necessary data to each user on each load.
What should be an equation on the pros and cons of that data being available for French vs. relative time format patterns for Tasawaq?

I agree that the answer is arbitrary, but we don't have a luxury of not making it - or to put it differently - from the Mozilla Manifesto perspective, refusing to make a decision here effectively is a decision and has a cost, and I'd like to see that reflected in people's position.

[0] https://groups.google.com/forum/#!topic/v8-users/YaL_NPKdee0
[1] https://github.com/tc39/proposal-unified-intl-numberformat/issues/39

> We're having an impact on which languages get rich JS apps written for them. Say a project contemplates to write an app in Tatar, and then see that neither Chrome, nor Edge, nor Firefox support that.

I don't think this is a good representation of the Web reality.

> I'm pretty sure that we shouldn't let Google make that decision for us. I really don't like the idea of being stuck with a decision Google made a couple of months ago going forward.

I understand this concern.
First, if you have an idea how to select the whitelist which is better from our perspective, I'd prefer to use that.
Second, I think we should separate out the concern of "SpiderMonkey Intl" which is the question of what functionality the Platform provides to the Web, from the question of "Firefox Intl" which is the question of what internationalization capabilities the Platform provides to Firefox for its intl/l10n needs. The platform serves those two "customers".

I requested your r? in the latter capacity, and I think the conversation is straying to focus on the former.

I believe the former is important, and we should hold the conversation, and I see you as a stakeholder in it, but I'd like to also learn from you whether there is a concern about this change from the "Firefox L10n" perspective, or just "Gecko Intl" perspective.

> To look at it from a different angle, how should we respond when a language community approaches us (e.g. files a bug) saying "Firefox i18n doesn't support our language, please fix it so we can have sites/apps that work properly for lang=xyz"?

The Web supports some set of locales, and the Web Reality dictates which of those locales can reliably be used and expected to work for most customers.
Intl capabilities of the platform are intentionally designed to be "best-effort" and fallback in case of missing data aiming to be transparent from the developer perspective, and provide user with as good of a formatted output as the data we ship allows, so it's not "breaking" the Web for them.
The locales I'm suggesting to exclude cannot currently expect their software to be internationalized relying on the ECMA402 due to lack of support in other web browsers.
So, we effectively ship that data to every single user, for an edge scenario where some web application wants to serve one of the minority locales and only cares about Firefox.

> I think the proper response ought to be simply "submit your language's data to CLDR, and then it'll work in Firefox". But that's only an adequate response if we're committed to including all the languages for which CLDR provides data. 

The commitment is a bit more complicated, and this issue is a good example of that complexity.

We have a limited budget for the internationalization data we can carry. We want to add an important set of data - `Intl.DisplayNames` - which, among others, will enable one of the more popular requests on the Web - a language selector - to be available at a lower per-website payload cost to all our users. It's even considered by W3C as a ground to add a language selector HTML widget. It means that in a vast majority scenario, the net outcome of this change bundled with bug 1557727 will be the barrier for adding a localized language switcher will drop significantly lowering the barrier to make websites multilingual and making JS/Web platform a better platform for internationalized software.

To "pay" for that, we are considering removing support for locales such as Tasawaq (tsq) spoken by ~2,000-10,000 people in the World.

You're pointing out, and I agree with that, that in the ideal world, we should support Tasawaq, rather than not support it. But I'd argue that in reality, the odds that a Tasawaq speaker will actually benefit from us supporting their language in Gecko JS Intl, while no other browser does, is slim.
On the other hand, the benefit of bringing `Intl.DisplayNames` to even top 30 locales is major, and we are suggesting to bring it to 400 locales.

Finally, unless we accept an unlimited growth of our binary size from ICU data, we should also consider the cost of not supporting `Intl.DisplayNames` for the top 400 locales in the presence of other web engines supporting it [0] for our ability to compete and retain users and web developer community good will necessary to remain relevant and be able to enable multilingual Web at all.

From the platform perspective, we will have such tradeoffs to make in the future, this is just the first one.

For another example, we had to hold a similar conversation about the support list of units in `Intl.NumberFormat` [1]. In result of that, we initially don't support at all units such as `gallon`, `liter`, `calorie`, `lux`, `megahertz`, `milligram`, `ton`, `radian`, `volt` and `watt`.
This, in turn, increases the barrier for webapps to provide internationalized support for UIs that would benefit from those, resulting in either more non-internationalized websites, or higher cost of loading a website that ships all the necessary data to each user on each load.
What should be an equation on the pros and cons of that data being available for French vs. relative time format patterns for Tasawaq?

I agree that the answer is arbitrary, but we don't have a luxury of not making it - or to put it differently - from the Mozilla Manifesto perspective, refusing to make a decision here effectively is a decision and has a cost, and I'd like to see that reflected in people's position.

[0] https://groups.google.com/forum/#!topic/v8-users/YaL_NPKdee0
[1] https://github.com/tc39/proposal-unified-intl-numberformat/issues/39

> We're having an impact on which languages get rich JS apps written for them. Say a project contemplates to write an app in Tatar, and then see that neither Chrome, nor Edge, nor Firefox support that.

I don't think this is a good representation of the Web reality.

> I'm pretty sure that we shouldn't let Google make that decision for us. I really don't like the idea of being stuck with a decision Google made a couple of months ago going forward.

I understand this concern.
First, if you have an idea how to select the whitelist which is better from our perspective, I'd prefer to use that.
Second, I think we should separate out the concern of "SpiderMonkey Intl" which is the question of what functionality the Platform provides to the Web, from the question of "Firefox Intl" which is the question of what internationalization capabilities the Platform provides to Firefox for its intl/l10n needs. The platform serves those two "customers".

I requested your r? in the latter capacity, and I think the conversation is straying to focus on the former.

I believe the former is important, and we should hold the conversation, and I see you as a stakeholder in it, but I'd like to also learn from you whether there is a concern about this change from the "Firefox L10n" perspective, or just "Gecko Intl" perspective.

> To look at it from a different angle, how should we respond when a language community approaches us (e.g. files a bug) saying "Firefox i18n doesn't support our language, please fix it so we can have sites/apps that work properly for lang=xyz"?

The Web supports some set of locales, and the Web Reality dictates which of those locales can reliably be used and expected to work for most customers.
Intl capabilities of the platform are intentionally designed to be "best-effort" and fallback in case of missing data aiming to be transparent from the developer perspective, and provide user with as good of a formatted output as the data we ship allows, so it's not "breaking" the Web for them.
The locales I'm suggesting to exclude cannot currently expect their software to be internationalized relying on the ECMA402 due to lack of support in other web browsers.
So, we effectively ship that data to every single user, for an edge scenario where some web application wants to serve one of the minority locales and only cares about Firefox.

> I think the proper response ought to be simply "submit your language's data to CLDR, and then it'll work in Firefox". But that's only an adequate response if we're committed to including all the languages for which CLDR provides data. 

The commitment is a bit more complicated, and this issue is a good example of that complexity.

We have a limited budget for the internationalization data we can carry. We want to add an important set of data - `Intl.DisplayNames` - which, among others, will enable one of the more popular requests on the Web - a language selector - to be available at a lower per-website payload cost to all our users. It's even considered by W3C as a ground to add a language selector HTML widget. It means that in a vast majority scenario, the net outcome of this change bundled with bug 1557727 will be the barrier for adding a localized language switcher will drop significantly lowering the barrier to make websites multilingual and making JS/Web platform a better platform for internationalized software.

To "pay" for that, we are considering removing support for locales such as Tasawaq (tsq) spoken by ~2,000 - 10,000 people in the World.

You're pointing out, and I agree with that, that in the ideal world, we should support Tasawaq, rather than not support it. But I'd argue that in reality, the odds that a Tasawaq speaker will actually benefit from us supporting their language in Gecko JS Intl, while no other browser does, is slim.
On the other hand, the benefit of bringing `Intl.DisplayNames` to even top 30 locales is major, and we are suggesting to bring it to 400 locales.

Finally, unless we accept an unlimited growth of our binary size from ICU data, we should also consider the cost of not supporting `Intl.DisplayNames` for the top 400 locales in the presence of other web engines supporting it [0] for our ability to compete and retain users and web developer community good will necessary to remain relevant and be able to enable multilingual Web at all.

From the platform perspective, we will have such tradeoffs to make in the future, this is just the first one.

For another example, we had to hold a similar conversation about the support list of units in `Intl.NumberFormat` [1]. In result of that, we initially don't support at all units such as `gallon`, `liter`, `calorie`, `lux`, `megahertz`, `milligram`, `ton`, `radian`, `volt` and `watt`.
This, in turn, increases the barrier for webapps to provide internationalized support for UIs that would benefit from those, resulting in either more non-internationalized websites, or higher cost of loading a website that ships all the necessary data to each user on each load.
What should be an equation on the pros and cons of that data being available for French vs. relative time format patterns for Tasawaq?

I agree that the answer is arbitrary, but we don't have a luxury of not making it - or to put it differently - from the Mozilla Manifesto perspective, refusing to make a decision here effectively is a decision and has a cost, and I'd like to see that reflected in people's position.

[0] https://groups.google.com/forum/#!topic/v8-users/YaL_NPKdee0
[1] https://github.com/tc39/proposal-unified-intl-numberformat/issues/39