Currently both material_ui and cupertino_ui implement their own localization interfaces, and look up localizations by matching against those exact types:
However, if an app (see demo below) is configured to provide localizations with flutter_localizations, then cupertino_ui/material_ui are not able to reconcile the localizations, failing with the debugCheckHas[Cupertino/Material]Localizations assert in debug-mode, or a runtime error in profile/release mode.
flutter_localizations must wait for material_ui/cupertino_ui to be published before it can be updated to depend on material_ui and cupertino_ui instead of flutter/material and flutter/cupertino. A potential long-term solution here is to move flutter_localizations into flutter/packages along with the Material and Cupertino libraries.
For now, we are splitting test cases that depend on flutter_localization out of material_ui and cupertino_ui and moving them to https://github.com/flutter/flutter/tree/master/packages/flutter_localizations
demo app
import 'package:flutter_localizations/flutter_localizations.dart';
// import 'package:flutter/material.dart'; // WORKS
import 'package:material_ui/material_ui.dart'; // DOES NOT WORK
void main() {
runApp(const DemoApp());
}
class DemoApp extends StatelessWidget {
const DemoApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
locale: const Locale('es'), // Spanish
supportedLocales: const <Locale>[Locale('en'), Locale('es')],
localizationsDelegates: const <LocalizationsDelegate<dynamic>>[
GlobalMaterialLocalizations.delegate,
GlobalWidgetsLocalizations.delegate,
],
home: const HomeScreen(),
);
}
}
class HomeScreen extends StatelessWidget {
const HomeScreen({super.key});
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(title: const Text('material_ui Localization Demo')),
body: Center(
child: ElevatedButton(
onPressed: () {
showTimePicker(context: context, initialTime: TimeOfDay.now());
},
child: const Text('Show Time Picker'),
),
),
);
}
}
Currently both
material_uiandcupertino_uiimplement their own localization interfaces, and look up localizations by matching against those exact types:material_ui:MaterialLocalizations,debugCheckHasMaterialLocalizationscupertino_ui:CupertinoLocalizations,debugCheckHasCupertinoLocalizationsHowever, if an app (see demo below) is configured to provide localizations with
flutter_localizations, thencupertino_ui/material_uiare not able to reconcile the localizations, failing with thedebugCheckHas[Cupertino/Material]Localizationsassert in debug-mode, or a runtime error in profile/release mode.flutter_localizationsmust wait formaterial_ui/cupertino_uito be published before it can be updated to depend onmaterial_uiandcupertino_uiinstead offlutter/materialandflutter/cupertino. A potential long-term solution here is to moveflutter_localizationsintoflutter/packagesalong with the Material and Cupertino libraries.For now, we are splitting test cases that depend on
flutter_localizationout ofmaterial_uiandcupertino_uiand moving them to https://github.com/flutter/flutter/tree/master/packages/flutter_localizationsdemo app