Package selection guidance compiled from public package information, community data, and project usage.
The multiple_localization package enhances the intl package by enabling support for multiple localization files, including .arb files, allowing developers to manage translations more efficiently across different languages and locales. It simplifies the process of organizing and loading localized messages in Flutter apps, especially when dealing with large-scale internationalization needs. The package is designed to work seamlessly with Flutter's existing internationalization infrastructure, making it easier to maintain and scale translation assets. It supports all major platforms: Android, iOS, Web, macOS, Windows, and Linux.
Use cases
Managing multiple language files in a single project
Additional configuration needed for custom file paths
May increase build complexity with many files
Best suited for projects already using intl
Not compatible with non-intl localization approaches
Original README
Original README snapshot from the linked source repository. Visit the repository for the latest content.
multiple_localization
Support for multiple abr and messages localization files for intl package.
Problem
If you want to have multiple arb files and register separate delegate for each one of them,
then you have a problem. Intl doesn't allow multiple initializeMessages calls. Only
first one will be processed and only it's messages will be used. Every calls after the first one
will be ignored.
Why do we need to have multiple arb files?
In common scenario - we don't. Just put all localization string in single file and enjoy.
But if you want to add intl localization with arb files to separate package, and than use
it in you project with it's own localization files - that's problem.
MultipleLocalizations supports using Localizations.override(delegates: [SomeLocalizationsDelegate(), ...]) widget, too.
Exactly for that situation this package was developed.
If you want to override string from package localization in project
(for example to change some labels in package widgets) - you need to
define string with required name in you app localization class.
Example.
If package has string messageFromPackageForOverride:
Now, whenever package use messageFromPackageForOverride you will see App, not Package.
Set fallback locale
Also you can specify a fallback locale when loading application localization delegate.
Use [fallbackLocale] parameter to set locale which will be used if some key not found for current locale.
Only first call of [load] will set fallback locale, make sure that your app's localization delegate
added as a first element of the delegates list.
Also pay attention that if you provide the [fallbackLocale], than all messages will be uploaded in memory
on the start of application in addition to current locale.