localizationsDelegates property

The delegates for this app's Localizations widget.

The delegates collectively define all of the localized resources for this application's Localizations widget.

Internationalized apps that require translations for one of the locales listed in GlobalMaterialLocalizations should specify this parameter and list the supportedLocales that the application can handle.

// The GlobalMaterialLocalizations and GlobalWidgetsLocalizations
// classes require the following import:
// import 'package:flutter_localizations/flutter_localizations.dart';

const MaterialApp(
  localizationsDelegates: <LocalizationsDelegate<Object>>[
    // ... app-specific localization delegate(s) here
    GlobalMaterialLocalizations.delegate,
    GlobalWidgetsLocalizations.delegate,
  ],
  supportedLocales: <Locale>[
    Locale('en', 'US'), // English
    Locale('he', 'IL'), // Hebrew
    // ... other locales the app supports
  ],
  // ...
)

Adding localizations for a new locale

The information that follows applies to the unusual case of an app adding translations for a language not already supported by GlobalMaterialLocalizations.

Delegates that produce WidgetsLocalizations and MaterialLocalizations are included automatically. Apps can provide their own versions of these localizations by creating implementations of LocalizationsDelegate<WidgetsLocalizations> or LocalizationsDelegate<MaterialLocalizations> whose load methods return custom versions of WidgetsLocalizations or MaterialLocalizations.

For example: to add support to MaterialLocalizations for a locale it doesn't already support, say const Locale('foo', 'BR'), one first creates a subclass of MaterialLocalizations that provides the translations:

class FooLocalizations extends MaterialLocalizations {
  FooLocalizations();
  @override
  String get okButtonLabel => 'foo';
  // ...
  // lots of other getters and methods to override!
}

One must then create a LocalizationsDelegate subclass that can provide an instance of the MaterialLocalizations subclass. In this case, this is essentially just a method that constructs a FooLocalizations object. A SynchronousFuture is used here because no asynchronous work takes place upon "loading" the localizations object.

// continuing from previous example...
class FooLocalizationsDelegate extends LocalizationsDelegate<MaterialLocalizations> {
  const FooLocalizationsDelegate();
  @override
  bool isSupported(Locale locale) {
    return locale == const Locale('foo', 'BR');
  }
  @override
  Future<FooLocalizations> load(Locale locale) {
    assert(locale == const Locale('foo', 'BR'));
    return SynchronousFuture<FooLocalizations>(FooLocalizations());
  }
  @override
  bool shouldReload(FooLocalizationsDelegate old) => false;
}

Constructing a MaterialApp with a FooLocalizationsDelegate overrides the automatically included delegate for MaterialLocalizations because only the first delegate of each LocalizationsDelegate.type is used and the automatically included delegates are added to the end of the app's localizationsDelegates list.

// continuing from previous example...
const MaterialApp(
  localizationsDelegates: <LocalizationsDelegate<Object>>[
    FooLocalizationsDelegate(),
  ],
  // ...
)

Adding localizations for a new locale

Implementation

TencentCloudChatMaterialApp class