Open Bug 1612379 Opened 5 years ago Updated 1 year ago

Narrow down the list of ICU locales we ship

Categories

(Core :: Internationalization, enhancement, P5)

Product:
Core
Component:
Internationalization
Type:
enhancement

Tracking

()

People

(Reporter: zbraniecki, Unassigned)

References

Details

User Story

Consider reducing the size of the binary to offset the cost of implementing Intl.DisplayNames (bug 1557727).

Attachments

(1 file)

Bug 1612379 - Filter ICU locales.
47 bytes, text/x-phabricator-request
Details | Review

We currently ship ICU data for an unfiltered list of all locales that ICU has in its repository - 459.

This seems excessive, and I'm going to look into finding a reasonable subset of that list that will maintain the globalization quality of our product, web compat, while potentially allowing us to get some bundle size wins.

Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Assignee: gandalf → nobody
Status: ASSIGNED → NEW

Initial findings.

I started producing a cross-table of locales in ICU, shipped by Firefox, and Chrome.

Then I produced a build that includes all locales we ship with Firefox. Unfortunately, the resulting build seems to be incomplete and displayed things like M1 for month in English and Chinese.
ICU documentation [0] claims that root languages for included locales will be included, but when I manually added en, es, pt, and zh, on top of the regional locales we already listed, then the build started producing meanintful values for months in English in Chinese, so that's what I use for testing.

Results:

Pre-built ICU dat file:

./config/external/icu/data/icudt65l.dat:

Variant Bytes Decrease Percent
all 11,143,312
firefox 7,751,056 -3,392,256 -30.44%

./obj-x86_64-pc-linux-gnu-opt/dist/firefox-74.0a1.en-US.linux-x86_64.tar.bz2:

Variant Bytes Decrease Percent
all 72,000,733
firefox 71,278,169 722,564 -1.00%

According to bug 1557727 comment 9, Intl.DisplayNames adds 824,759, but that was measured against all locales.
Even in that scenario, Intl.DisplayNames adds 824,759 and here we shave off 722,564 leaving just a 102,195 bytes increase.

Next, I'll see if I can build the data for display names filtered down by locales.

Here's the locale whitelist I used:

    "localeFilter": {
        "filterType": "locale",
        "includeChildren": false,
        "whitelist": 
        [
          "af",    "ar",    "ast",   "az",    "be",    "bg",    "bn",
          "bo",    "br",    "brx",   "bs",    "ca",    "cs",    "cy",
          "da",    "de",    "dsb",   "el",    "en", "en-CA", "en-GB", "eo",
          "es", "es-AR", "es-CL", "es-ES", "es-MX", "et",    "eu",    "fa",
          "ff",    "fi",    "fr",    "fy-NL", "ga-IE", "gd",    "gl",
          "gu-IN", "he",    "hi-IN", "hr",    "hsb",   "hu",    "hy-AM",
          "ia",    "id",    "is",    "it",    "ja",    "ka",    "kab",
          "kk",    "km",    "kn",    "ko",    "lo",    "lt",    "lv",
          "mk",    "mr",    "ms",    "my",    "nb-NO", "ne-NP", "nl",
          "nn-NO", "pa-IN", "pl",    "pt", "pt-BR", "pt-PT", "rm",    "ro",
          "root",
          "ru",    "si",    "sk",    "sl",    "sq",    "sr",    "sv-SE",
          "ta",    "te",    "th",    "tl",    "tr",    "uk",    "ur",
          "uz",    "vi",    "wo",    "xh",    "zh", "zh-CN", "zh-TW"
        ]
    },

[0] https://github.com/unicode-org/icu/blob/master/docs/userguide/icu_data/buildtool.md

I included https://phabricator.services.mozilla.com/D52163#change-SToEwlHxbEjj on top of my whitelist:

Variant Bytes Decrease Percent
all-locales 72,000,733
firefox-locales 71,278,169 -722,564 -1.00%
firefox-locales + DisplayNames 71,699,687 -301,046 -0.41%

It seems like we can successfully land DisplayNames with this change and shave 300kb of the build size!

I'll work on now finalizing the whitelist production and test the impact on other platforms

I updated the proposed patchset to contain a combination of:

We have a couple ideas on how to further shrink the ICU data size (see bug 1612578), but for now, I'd like to consider landing this list in 75 to enable bug 1557727 landing with no binary size impact.

Numbers:

Variant Bytes Decrease Percent
all-locales 11,143,312
firefox-locales 8,987,296 -2,156,016 -19.35%
firefox-locales + DisplayNames 10,759,792 -383520 -3.44%
Variant Bytes Decrease Percent
all-locales 72,049,289
firefox-locales 71,560,718 -488,571 -0.68%
firefox-locales + DisplayNames 72,095,600 46,311 0.06%

I think this is more in Pike's territory for review than mine.

What I'm personally afraid of, is that this is adding one more place to customize when adding a new locale to Firefox, or when an existing locale becomes available in CLDR. Not sure if that could be covered by tests somehow.

Is this list affecting GeckoView in any way?

Actually, one more question. I see, for example, that Frisian is available in ICU, but doesn't seem to have language names (I assume that's what the ICU Language column is used for). fy or fy-NL are not included in the whitelist. Does it mean we don't import ICU data at all for these languages?

What I'm personally afraid of, is that this is adding one more place to customize when adding a new locale to Firefox, or when an existing locale becomes available in CLDR. Not sure if that could be covered by tests somehow.

Yes, we will need one more place. We could probably have a test which verifies that each locale in all-locales is in intl/icu/data_filter.json.

Is this list affecting GeckoView in any way?

Initially, we'll share the same list between GeckoView and Firefox. Eventually, I could see us further narrowing down the list in GeckoView similarly to how Chromium does it for their android.

======

You're right that fy-NL was not included, and it's due to my mistake in data generation. I updated the sheet and the numbers:

./config/external/icu/data/icudt65l.dat:

Variant Bytes Decrease Percent
all-locales 11,143,312
firefox-locales 9,326,800 −1,816,512 -16.3%
firefox-locales + DisplayNames 11,188,960 45684 0.41%

./obj-x86_64-pc-linux-gnu-opt/dist/firefox-74.0a1.en-US.linux-x86_64.tar.bz2

Variant Bytes Decrease Percent
all-locales 72,049,289
firefox-locales 71,595,453 -453,836 -0.63%
firefox-locales + DisplayNames 72,164,462 115,173 0.16%

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #8)

What I'm personally afraid of, is that this is adding one more place to customize when adding a new locale to Firefox, or when an existing locale becomes available in CLDR. Not sure if that could be covered by tests somehow.

Yes, we will need one more place. We could probably have a test which verifies that each locale in all-locales is in intl/icu/data_filter.json.

On second thoughts, that wouldn't really work. A change to the JSON file would require to manually/locally rebuild the .dat file, or would that be part of automation? I assume it's manual, based on your patch, and in that case we shouldn't block adding a locale on work that it's going to be performed async by another team.

That would also not solve the problem of an existing Firefox locale being added to CLDR/ICU in a new version.

On second thoughts, that wouldn't really work. A change to the JSON file would require to manually/locally rebuild the .dat file, or would that be part of automation? I assume it's manual, based on your patch, and in that case we shouldn't block adding a locale on work that it's going to be performed async by another team.

Yup, it's manual at the moment unfortunately (bug 1315397).

That would also not solve the problem of an existing Firefox locale being added to CLDR/ICU in a new version.

That should not be an issue since updating ICU will require a rebuild of the dat file anyway.

Next - provide android build impact

Flags: needinfo?(gandalf)

Builds:
all-locales: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a2d77c5c8be8d543d90c734a34ecdc1314880fcd
firefox-locales: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7752a1cbb7693c1dcdf2314b0fbd6ab16da06d6c
firefox-locales + DisplayNames: https://treeherder.mozilla.org/#/jobs?repo=try&revision=785d50f6bfaaed30137b34c3c91bc7510aba3e44

Linux:

Variant Bytes Decrease Percent
all-locales 73,832,383
firefox-locales 73,417,558 −414,825 -0.56%
firefox-locales + DisplayNames 73,934,622 102,239 0.14%

MacOS:

Variant Bytes Decrease Percent
all-locales 80,352,721
firefox-locales 79,862,002 −490,719 -0.61%
firefox-locales + DisplayNames 80,577,652 224,931 0.28%

Android:

Variant Bytes Decrease Percent
all-locales 53,023,857
firefox-locales 52,460,245 −563,612 -1.06%
firefox-locales + DisplayNames 53,253,714 229,857 0.43%

Windows:

Variant Bytes Decrease Percent
all-locales 51,522,124
firefox-locales 51,231,355 −290,769 -0.56%
firefox-locales + DisplayNames 51,717,843 195,719 0.38%

===

With the current proposed subset, we're shaving off 300-550kb pre-DisplayNames, and with DisplayNames we end up growing by 100-220kb.

I tested with chromium-android and android-small subsets, and the result didn't impact the binary size at all.

This makes me believe that the current approach of filtering to include Firefox + Chromium locales is at its limit, and we either need a different strategy for narrowing down locales, or further investment in bug 1612578 to get more wins.

The question is - are the wins in this bug enough to offset the increase from DisplayNames. If the answer is yes, I believe we should land those two together once 75 opens.
If the answer is no, then we should investigate in bug 1612578 on top of this bug.

Flags: needinfo?(gandalf)
Flags: needinfo?(bgrinstead)

Better visualized, and using better android binary:

Platform all-locales fx-locales + DN Increase Percent File
arm32 49,988,743 50,195,665 206,922 0.41% geckoview-default-armeabi-v7a-74.0.xxx.aar
linux64 73,832,383 73,934,622 102,239 0.14% target.tar.bz2
macos 80,352,721 80,577,652 224,931 0.28% target.dmg
win64 51,522,124 51,717,843 195,719 0.38% target.installer.exe

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #12)

The question is - are the wins in this bug enough to offset the increase from DisplayNames. If the answer is yes, I believe we should land those two together once 75 opens.
If the answer is no, then we should investigate in bug 1612578 on top of this bug.

I wouldn't look at the packet size gains in isolation.

As explained in comment 6, this is adding complexity to our locale management for Firefox (and possibly GV, although it's far from clear what we're doing there in terms of l10n). If it comes with a significant gain, then it's clear that we should do it and figure out how to avoid misalignment.

What's the package increase without optimization? 400-770kb?

What's the package increase without optimization? 400-770kb?

The locale whitelisting in this bug is shaving off around 500kb of the binary size. Intl.DisplayNames without this optimization adds data for all ~800 locales which adds around around 1Mb (bug 1557727 comment 9). With the whitelist, Intl.DisplayNames adds ~600kb, so the whitelist shaves off around 300kb off of the data added.
Future APIs will further increase the impact of the whitelist.

I think we have to ask a bigger question here. Similar to Henri in bug 1613271 comment 9, I think we need to ask what a reduced locale list means to the web.

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'm not sure that we should make that decision. 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.

+1 to this. 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"? 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. If we're restricting Firefox to a whitelisted subset, it becomes "submit to CLDR, and then lobby for your language to be added to the Firefox whitelist", which is (a) added friction that communities shouldn't have to deal with, and (b) an ongoing burden of case-by-case decision-making for us.

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

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #18)

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.

Yes, I realize there are trade-offs to consider, and potentially difficult decisions to make. But looking at the whitelist in comment 2, this isn't just about "locales ... spoken by [a few thousand] people [and perhaps with little tradition of written communication?]". This is also about dropping locales with tens of millions of speakers and a rich literary tradition, like (to pick an example I happen to be familiar with) https://en.wikipedia.org/wiki/Sindhi_language.

Yes, I realize there are trade-offs to consider, and potentially difficult decisions to make.

I agree. I think we conflated two topics:

  1. Should we narrow down the list of locales we ship data for in Intl platform
  2. How to select such a list

It seems that you agree with (1), but contest the current selection (2). Is that correct?

Flags: needinfo?(jfkthame)

I'm really not sure -- it's a tough issue. In principle, I'd strongly prefer us to ship all the intl data for all locales. But I realize that may be prohibitive, and come with its own drawbacks, e.g. if the increased download size significantly reduces adoption.

Next-best option might be on-demand addition of locale data, so that we'd ship with data for just a "core" set of locales, but Firefox would fetch additional locales on the fly in response to content or script asking to use them. So the first time someone does today.toLocaleDateString("snd"), we'd install the Sindhi locale data and it'd "just work" for those users. But that's technically challenging, I'm sure (particularly for sync APIs), and we may not have the developer resources to do it at this point.

So yes, I might end up agreeing with (1), reluctantly; but I wasn't comfortable with it being discussed in terms of such a marginal example, which I don't think gave a fair impression of the impact. As for (2), I don't know where to draw the line, but I'm uneasy about dropping support for a language as major as "snd".

Maybe we need to brainstorm some more criteria for inclusion? A couple of ideas we could consider:

  • Any locale that is a national/official language of a country or a major region (province, state, whatever) gets kept
    • So that would include "snd", as the official language of Sindh province in Pakistan, as well as one of the official scheduled languages of India
    • It would also include "dv", which only has 340K speakers but is the official language of the Maldives
  • Any locale with more than X speakers, where X is.... 100K? A million? Ten million? I don't know... wdyt?
    • This would include examples like "skr", with 20 million speakers

There are probably other useful criteria... e.g. are there regular newspapers published in the language? Used in regular television broadcasting? Other ideas...?

Flags: needinfo?(jfkthame)

Thank you! I agree with your position.

But that's technically challenging, I'm sure (particularly for sync APIs), and we may not have the developer resources to do it at this point.

We are investigating asynchronous constructors for Intl to allow for loading additional data like the scenario you described. We could invest in this proposal and lead the effort to enable us to provide support for all locales without paying in the binary size.
But that's more of a medium term solution and so far ECMA402 does not have a champion for such proposal, so it won't be a feasible solution for the current DisplayNames landing question.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #18)

Reminds me of that lunch conversation with JoeH, on a different topic. Where I explained all my world views, and then he said: You recognize that you just made a case not do this at all?

Not that I agreed, but he had a point.

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

Can you please assign blocking reviewers on aspects that you don't want my input on, and clarify that in the commit message?

Technically, I share flod's concerns about him being savvy enough to add a localization to Firefox, and quite frankly, knowing that I'm looking at a binary blob, my ability to review an addition of a localization to Firefox.

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.

If we're on a budget, does that mean that we can't add localizations to Firefox that are not already in the proposed list of locales?

Also, does that imply that we need to drop further locales when we add new APIs with data requirements?

I'm also concerned about what impact this has on our ability to ship new locales, or locales that are under-resourced and aren't represented in Unicode yet. We would potentially be actively discouraging locales from participating, which seems contrary to the assessibility part of our mission.

I don't have particular dogs in this fight. And I am not terribly happy about losing support for locales -- nor about deciding some are more equal than others (to put it in somewhat loaded fashion).

At the same time:

  • If we don't ship Firefox with support for a particular locale, it isn't crazy to say that we need not support it for in-webpage APIs. If users already have to fumble their way through a UI in a non-preferred locale, the marginal value of in-webpage UI for that locale is also low, because the users have necessarily demonstrated some facility in working in another language. It may not be ideal to deny them a little more support for their locale in Intl...but we're already denying them much more than that in not shipping a Firefox in that locale at all.
  • This consideration is a neutral consideration, that does not require us make any value judgments about which locales are better, which are worse. Whether we are capable of shipping support for that locale in UI has nothing to do with how good, important, "big" a locale is. It has to do with "can we sustain the effort to provide UI in this language?" (Which as a matter of resources and prioritization may raise the same considerations -- precisely why don't we ship a build for Sindhi, if it is used by that many people? -- but that's a question best answered and discussed elsewhere, and there are undeniable purely practical considerations that must go into it.)

(In reply to Jeff Beatty [:gueroJeff] from comment #24)

I'm also concerned about what impact this has on our ability to ship new locales, or locales that are under-resourced and aren't represented in Unicode yet. We would potentially be actively discouraging locales from participating

As I understand the calculus and logic here, this isn't how it would work. If we ship localized builds for a locale, that dictates that we add support for that locale here. Marginally, sure, there's an increased download size for everyone when we start shipping builds for fresh locales. But the marginal cost of one locale is pretty small -- it's the cost of many many locales all considered at once that is non-marginal. So if a Sindhi user community sprang up to enable us to ship Sindhi builds, we would add it to the list for our Intl support and not think twice about it. (Just as we don't think twice about it now when new CLDR adds data for one or a few new locales in a new CLDR release that we start shipping when next we update our CLDR/ICU import.)

Can you please assign blocking reviewers on aspects that you don't want my input on, and clarify that in the commit message?

I appreciate your input in all roles, but in one of them I cannot get it from anyone else (Fx L10n), so I want to make sure we have input from that angle, irrelevant of the conversation about the impact of Gecko as a platform for the Web.

As for other stakeholders - I requested r? from :waldo as an SpiderMonkey Intl module owner, and we have :vchen :rtestard and :bgrins for platform and product angles.

It's clear to me that with the input from all of the Gecko Intl Module peers, we're also reaching the state where the decision goes beyond technical. :)

Technically, I share flod's concerns about him being savvy enough to add a localization to Firefox, and quite frankly, knowing that I'm looking at a binary blob, my ability to review an addition of a localization to Firefox.

I think we could make it easier to notice when a locale in all-locales is not part of data_filer.json whitelist. In 2019 we added 4 locales, in 2018 we added 3. I hope the overhead to do so is not going to outweigh the potential benefits from the decision.
As a mitigating strategy for this issue we could improve the docs on how to add a locale to make it easier for :flod to do so.

If we're on a budget, does that mean that we can't add localizations to Firefox that are not already in the proposed list of locales?

I don't think so. As :waldo stated - adding a couple locales, or languages per year doesn't seem to impact us in the same way as adding/removing 1Mb. I see this whitelist as a one-time mitigation to allow us to land bug 1557727.

Also, does that imply that we need to drop further locales when we add new APIs with data requirements?

I don't think so. I hope we'll find other ways to mitigate the cost of other APIs (like, the mentioned units vs bug 1612578), and ultimately, I hope the async constructors combined with lazy fetching of data (like suggested by :jfkthame in comment 21) will provide an ultimate solution to the problem of increasing data size without being limited by the cost of the binary size.

I'm unassigning myself for the time being and removing r? requests to better reflect the current state of this suggestion.

I don't have particular dogs in this fight.

I'm afraid that with the advancement of Intl.DisplayNames the buck will stop on you.

If stakeholders in this bug prefer to not land this change at all (which is different from adjusting the whitelist - comment 20), at the cost of not landing bug 1557727, we need to find other ways to mitigate the impact of bug 1557727 or accept the binary size increase coming from it.

:bgrins - can you advise on what should happen with this issue? I think we have all the input, but I'm not sure who is the person to make the final call as the problem spans across multiple modules and orgs.

Assignee: gandalf → nobody
Status: ASSIGNED → NEW

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #27)

I don't have particular dogs in this fight.

I'm afraid that with the advancement of Intl.DisplayNames the buck will stop on you.

While we practically are trying to consider these together for the purposes of that feature, I don't think it's exactly a good idea to make the decision here with too much focus on that specific short-term win that this would make more feasible. A policy decision about which locales' data should be shipped is a serious question that ought be considered on its own merits, not solely with regard to benefits it might enable.

If stakeholders in this bug prefer to not land this change at all (which is different from adjusting the whitelist - comment 20), at the cost of not landing bug 1557727, we need to find other ways to mitigate the impact of bug 1557727 or accept the binary size increase coming from it.

Sure. Ideally, enough people will understand that half-support for a locale is a bit weird and does not outweigh the costs on download size imposed by the choice. If not, well, I'm not sure what we'll do, but that's a problem for another day, if indeed it does become a problem.

Priority: P2 → P5

taking off NI but will keep this bug open to revisit once we have ICU4X

Flags: needinfo?(bgrinstead)
See Also: → 1741262
Severity: normal → S3
See Also: → 1331508
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: