This list was copied from gyp, we probably missed them for a long time. :(

If we're going to change the supported locale set and increase the APK size we need to make sure alex/jason are okay with this as previously we haven't done this on purpose.

Is the issue in this bug a regression (i.e. were we previously shipping all 53 locales before the GN migration, or something?) or have we simply never had more than the 44 sets of strings in the webview APK until now?

It looks like right now (and as far as we've been GN), webview has included 53 locale .pak files, but only 44 android res/values files.

What about before the GN migration? Was it the same there?

What's the size delta by including all 53 sets of android resources?

WebView missed components string for 9 languages, not miss 9 language pak, i.e WebView and Monochrome support 53 language, but there are 9 languages missing some string, and English should be used in this case.

in the case of missing resource, the default value will be used, like empty string, not the english one.

Here is summary of my investigation,

- This only impacts on java resources

- This is not regression, these resources are missing from very beginning, have noting to do with GN migration, because only android_webview_strings.grd defines extra 9 languages, but they are not defined in the other grd files (like content, component, ui) that WebView depends on

- The missing resource seems no only component grd, but all grd files that WebView depends on except android_webview_strings.grd.

- ICU data might also need to changed to support additional languages. see https://bugs.chromium.org/p/chromium/issues/detail?id=369218#c30

OK, those 9 languages aren't fully supported in icu, here the script to remove the data for these languages, it seemed we need the separated icu data for WebView.

https://cs.chromium.org/chromium/src/third_party/icu/android/patch_locale.sh?rcl=0&l=55

If we've never shipped this data then we definitely need to look at what it actually affects for those languages (i.e. what are the strings used for) and what the size increase is before simply turning it on.

Talked to torne@ offline, he thought this isn't urgent because this is not regression, and WebView still support few language than Android, but we need to find out the size impact.

I think we should either fully support 9 languages or drop them, and this is judged by size impact I guess.

OK, so summary: 

Which parts of locale data (chromium pak resources, chromium android java resources, ICU data) are included in webview isn't consistent and this is probably not intentional. I'm not sure whether we actually intend to support the 54 languages or not, and how we got into the state we're in now. We should do something to make this consistent, but it doesn't appear to be a regression from earlier webview versions, so I don't think we need to rush to fix it.

See my comment at https://bugs.chromium.org/p/chromium/issues/detail?id=558569#c14 for some past discussion of this.

Some things I think we should confirm/figure out/collect together from the various bugs this has been discussed in:

1) Am I correct that for each language there's three things that need to be present to have full support: the Chromium strings in the <lang>.pak file, the Java strings in the Android resources, and the ICU locale-specific data? Is there anything else?

2) Which languages have only partial support in WebView? It sounds like there's 9 locales where we have the .pak strings but not the ICU locale data or the Java strings; is that definitely all, or are there any other combinations of partial support?

3) What's the actual impact on users of this partial support in WebView?

4) Is Monochrome currently the same as WebView? i.e. does it fully support the same locales, and has the same partial support for the same 9 locales?

5) What's the total size impact on the APK of adding full support for the currently partially supported locales? Both the ICU data that jshin@ discussed in issue 369218, plus any other resources/strings/etc?

6) Is this size impact the same for WebView and Monochrome, or will it be a larger increase for Monochrome due to additional strings that aren't used in webview?

I think if we answer all of that, we can decide what to do about the languages with partial support, and then we can look at whether we actually need to be adding support for even more languages, but yes, I don't think this is urgent if we don't have a regression here, because any change here is going to have to be something we discuss carefully in terms of the size impact and user benefit.

bug 369218 comment 41 ( https://bugs.chromium.org/p/chromium/issues/detail?id=369218#c41 ) shows that the size impact of supporting 9 more locales in the ICU data is less than 150kB. 

re question 3) 
v8's Ecma 402 (JavaScript Intl library for formatting, sorting, etc) implementation relies on ICU. Besides, Blink's various form input implementation (e.g. date picker ) can be affected if they use ICU (bundled) directly instead of Android Java API. 

re qeustion 3) again: Blink on Android does use ICU for various locale-specific formatting, etc  ( https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/BUILD.gn?q=LocaleICU&sq=package:chromium&l=1411&dr=C ). 

re question 6: I guess there will be a bigger size impact on Monochrome (not knowing what that is, I'm speculating that it's a different incarnation of Chrome browser with a lot more UI strings than WebView) than on Webview. 

I found out what monochrome is. The answer to Q6 is positive. 

Thanks for the ICU info; we also need to count how big the missing Java string resources are.

As for webview alone, I suspect it'd be pretty small. Which counts more,  The uncompressed size total of 9 additional xml files or final APK size? 

Final APK size. WebView/Monochrome never have to extract any files from the APK, so only the APK size is important.

No longer on the Chrome team, e-mail me @google.com if any attention still required from me here, otherwise good luck!