Flutter would like support for using OEM strings files with package:intl

[eseidelGoogle]

Sometime in the next ~6 months or so I suspect we're going to need this as larger apps start to ship with Flutter.

The advantages of using OEM string files instead of compiling in translated strings are:

1. Reduces binary size of compiled Flutter apps by removing intl strings.
2. Allows sharing Dart/Flutter localizations with other 3rd party libraries and Java/Obj-C code.
3. Allows App-Stores to further reduce the size of Flutter App downloads by stripping out localization files in their normal manner.

FYI @abarth @dgrove

[alan-knight]

In theory, you can do this already and should be able to write it yourself without additional support.

Right now a program imports the generated messages_all.dart, which uses a MessageLookupByLibrary and deferred-loaded libraries. It should be possible to generate or even write a single import which looks messages up using an OEM mechanism instead.

So using existing OEM messages should be fairly simple. One possible issue is that we identify messages by name, which is passed into the Intl.message call. If the OEM messages are identified differently, that might be an issue. Notably, we have only a single namespace, as an Intl.message call doesn't have a way to pass in its context, e.g. what library it's in. That could be addressed by just having different libraries to import. messages_subsystem_a.dart, messages_subsystem_b.dart, etc.

The other step is extracting message information from Dart programs and getting it into OEM form. Intl_translation is also pluggable for its output form. The issue there is that it, and Intl.message in general, are pretty tied to ICU semantics. OEM mechanisms may have different semantics, most notably, they may be missing things. My impression is that most OEM mechanisms are pretty limited with respect to things like plurals and genders. It could be confusing for the users if the Dart-level API offers lots of functionality that won't actually work when localized. One possibility would be to write an intl_lite package which only supports the lowest common denominator of OEM formats and have users write to that API. That could be quite a thin layer that could delegate to the intl mechanisms. That would handle subsetting, significant differences in semantics would be harder, but that's always going to be true.

Another possibility would be to implement any missing plural/gender/select support in terms of the underlying oem support, e.g. by breaking a plural up into N distinct messages at the OEM level.