Add guide for i18n for package authors

[oravecz]

I like that the internationalization documentation and example apps have been recently worked on.

There is some hinting about package localization.

In a large app, different modules or packages might be bundled with their own localizations.

However, there is still a gap in how to use the intl library for those of us developing widgets for sharing with others via a Flutter package.

1. When or how does the packages localization content get loaded?
2. Since a package does not have an App in play, do I expose a localizationDelegate from my component with instructions on how to add this to the consuming app, or should I be listening (?) for Locale changes from the app and react accordingly?

Would love to see a packages folder added to the examples/internationalization to demonstrate the best practice for this.

[sfshaza2]

@shihaohong, can you weigh in?

@oravecz, we are working on some new docs that will better explain this.

[shihaohong]

1. When or how does the package's localization content get loaded?

In Flutter, WidgetsApp, MaterialApp or WidgetsApp take a list of localizations delegates and will load the required localized resources for your application based on that list. If a package contains widgets with localized content, you can pass a localizations delegate into *App so that it can be referenced by the custom widgets in your package.

However, package authors could come up with their own ways of exposing their localizations content, since our strategy for exposing localizations is similar to how InheritedWidgets work.

2. Since a package does not have an App in play, do I expose a localizationDelegate from my component with instructions on how to add this to the consuming app, or should I be listening (?) for Locale changes from the app and react accordingly? Right -- you would expose a localizationsDelegate to be passed into your Widgets/Cupertino/MaterialApp. This would load the localized resources that your custom widgets would need and allow your widget to be localized properly throughout the Flutter app.

I believe that we currently do not provide any explicit guidance on this. The Material and Cupertino libraries are actually themselves examples of packages with localized resources. However, WidgetsApp, MaterialApp and CupertinoApp have localizations delegate lookup baked in so users don't have to do it. (here is how MaterialApp does this, for example).

I think we could add an example on how to create localized packages. I might have to play around with creating a localized package myself and see if there might be a better way to do it than the way I described above.

cc/ @HansMuller if he'd like to weigh in

[sfshaza2]

This sounds like a good idea. Please review, @miquelbeltran

[miquelbeltran]

However, package authors could come up with their own ways of exposing their localizations content, since our strategy for exposing localizations is similar to how InheritedWidgets work.

However, WidgetsApp, MaterialApp and CupertinoApp have localizations delegate lookup baked in so users don't have to do it. (here is how MaterialApp does this, for example).

Have this been implemented somewhere? The i18n documentation still asks users to manually add the localization delegates in their apps: https://docs.flutter.dev/ui/accessibility-and-localization/internationalization#setting-up

e.g.

localizationsDelegates: [
    GlobalMaterialLocalizations.delegate,
    GlobalWidgetsLocalizations.delegate,
    GlobalCupertinoLocalizations.delegate,
  ]

If this step is no longer necessary, then the documentation should be updated.

If a package contains widgets with localized content, you can pass a localizations delegate into *App so that it can be referenced by the custom widgets in your package.

These localization delegates come in fact from the flutter_localizations package, so it's already a good example on how to import external localization into your project.

I think we could add an example on how to create localized packages.

Yes, I think the actual implementation won't be any different than creating localizations for an app, the difference is that the package devs need to expose a localization delegate for the other devs to include in their projects.

That explanation could be added under "Alternative internationalization workflows" in the i18n documentation page: https://docs.flutter.dev/ui/accessibility-and-localization/internationalization#alternative-internationalization-workflows something like e.g. "Adding Localization to a package"