Native i18n support

[sarbogast]

It would be really nice to have support for the new internationalization process documented there.

I tried to use the Flutter Intl plugin for IntelliJ but it creates ARB files in a completely different location and it simply ignores the configuration in l10n.yaml. The most useful part of this plugin that I would love to see replicated in the native Flutter plugin is an intention action that lets me add an entry to my ARB files from a dart file, similar to what "Internationalize" does in Java for example.

It would:

• open a dialog that lets me specify a description for my messsage, as well as a key
• detect if there are any placeholders in the string I want to internationalize and let me select their type and specify an example
• if type is DateTime, int or double, let me choose a format and specify potential parameters
• replace the raw string in my dart file with AppLocalizations.of(context).key(args), taking the configuration in l10n.yamlinto account
• add the app_localizations.dart import if it's missing

Additionally, if it contained an ARB editor that lets me see translations in a table instead of having to open all my ARB files side by side, that would be perfect (similar to the translation editor for Android native projects).

[sarbogast]

Oh, and another cool feature would be the ability to see the message in the reference language in the code editor instead of the identifier, just like in Android native development. And if there could be an intent to weed out all the non-internationalized strings before committing, with an annotation to potentially ignore the intent warning for things like asset paths and so on.

[devoncarew]

Thanks for the detailed feature request! I agree that we should have tooling in this area. We won't have immediate bandwidth but I suspect that this is something pull put into our planning process in the future.

cc @HansMuller @shihaohong

[HansMuller]

There's a great deal the IDE could do to make developers building internationalized apps more effective. Happy to do what we can to help.

[Mike278]

Thumbs up from me!

One of the things I liked about the old localization workflow is that making strings "translatable" had an extremely low barrier to entry, meaning developers were more likely to do it during normal feature development (compared to using raw strings). Since the workflow involved writing Dart code (Intl.message calls), you could leverage the power of a full programming language and all its rich features/tooling (code completion, static typing, refactoring, jump-to-usage/definition, etc). The rest of the workflow where you extract to a single .arb and manually split/merge it into per-locale .arbs could definitely use some better tooling, but in my experience that was far less time consuming than having to go through a code base and make raw strings translatable.

The new workflow looks like it does actually automate a good chunk of that workflow, but:

The proposed approach is to start with handwritten ".arb" files.

IMO this significantly increases the barrier to entry for writing translatable apps:

• Hand-writing JSON is not a great experience
• There's not much tooling for editing .arb files: the original 1st-party editor was shut down, the other 1st-party .arb editor is VSCode-only, and the 3rd party plugin for IntelliJ has the issues mentioned in the OP
• Developers need to learn the verbose .arb json structure: ..."@hello": {"placeholders": {"userName": {"type": "String"}...} compared to the familiarity of a function call String hello(String userName) => Intl.message(... /*auto-complete, pop-up docs, etc*/ )
• You need to perform codegen before you can continue programming against your new string

To be fair the issue with .arb file support isn't unique to the new workflow, but at least in the old workflow you didn't have to interact with .arb files as directly.

All that to say: it would be great to have some better tooling here!