Support packages

[tenhobi]

This package is, of course, superior 🔥 to the default localization packages. Althrough it doesn't provide a simple solution for using it in Flutter or Angular project.

It would be super nice to create support packages – with inspiration in BLoC packages structure – which would contain i69n, flutter_i69n and angular_i69n in packages/ directory.

This would increase the ability to adapt this package. For example, this is some other package about easy localization which has support for Flutter which gives it right on the spot better prestigue to use it. People are lazy and don't wanna repeat yourselves (or dumb and they cannot create proper support packages).

For Flutter it would mean to create, probably, only Localizations and LocalizationsDelegate classes and maybe (?) modify a bit the current package to support loading proper file using locale codes, if it isn't already supported now. Dunno, further investigation would be needed.

Some other resources:

• https://flutter.dev/docs/development/accessibility-and-localization/internationalization
• https://medium.com/saugo360/managing-locale-in-flutter-7693a9d4d6ac
• https://proandroiddev.com/flutter-localization-step-by-step-30f95d06018d
• https://pub.dev/packages/flutter_i18n

---

Personal interest: I would like to use this backage as part of my Bachelor's Thesis, for it's simplicity, so I can try to create the Flutter package or help with it.

[Tomucha]

I'm not sure what you mean by "simple solution for using it in Flutter or Angular project" because I'm using it within both AngularDart and Flutter projects.

On the other hand, I'm completely ignoring "official" standard and I'm just using this package ... so if you desire some kind of bridge between "official" and "great" and you are offering to build it as a by-product of your thesis, I will gladly incorporate it into this project and glory will be yours forever!

[tenhobi]

Can you provide an example how you handle switching locales on fly and how you access locales in widgets? 🙂

[Tomucha]

@dafesimonek Would you mind pasting a few lines of code here? Thanks!

[dafesimonek]

We use 'provider' package for on the fly changes:

1. model for language code

class AppConfigModel extends ChangeNotifier {
  String _languageCode;

  String get languageCode => _languageCode;

  set languageCode(String value) {
    _languageCode = value;
    notifyListeners();
  }
}

2. on app startup, use provider's ProxyModel to choose Messages based on the lang code in appConfig model

    ChangeNotifierProvider<AppConfigModel>.value(
        value: AppConfigModel()),

    ProxyProvider<AppConfigModel, Messages>(builder: (_, appConfig, __) {
      // TODO add other languages here
      switch (appConfig.languageCode) {
        case 'cs':
          log.i('Setting messages to Czech');
          return Messages_cs();
        case 'en':
          log.i('Setting messages to English');
          return Messages();
      }
      log.w(
          'Unknown language code "${appConfig.languageCode}", falling back to default English');
      return Messages();
    }),

3. use Messages in Widgets through provider's Consumer approach

class SomeWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // use provider's ConsumerX syntax sugar to access multiple models at once
    return Consumer3<AppConfigModel, Messages, LoginModel>(
      builder: _buildContent,
    );
  }

  Widget _buildContent(BuildContext context, AppConfigModel appConfig,
      Messages messages, LoginModel loginModel, Widget _) {
    return Text('Text from i69n: ${messages.app_name}');
  }

[tenhobi]

Hmm, just an idea, in order to make this package better. Wouldn't it be better to generate files like

messages/messages_all.i69n.dart
messages/messages_en.i69n.dart
messages/messages_cs.i69n.dart

where *{lang}.* files would share common interface, for example in intl library there is always class MessageLookup extends MessageLookupByLibrary {...}, so other packages can easily implement messages w/o any need to parse the data. In *_all.* file there would be some generated map to switch to desired location.

In contrast to the current state, where individual translations are generated substantially separately.

---

TL;DR; this part is the biggest issue to make by program (or I do not see how to do it easily), w/o any complicated parsing. And complicates a lot creating Flutter's Localization delegate and especially using the package.

switch (appConfig.languageCode) {
        case 'cs':
          log.i('Setting messages to Czech');
          return Messages_cs();
        case 'en':
          log.i('Setting messages to English');
          return Messages();
      }

And that is pitty, cause the yaml idea and implementation for this package is super awesome!

As an example, take a look at Intl implementation of generated files https://github.com/tenhobi/flashcards/tree/0dbc194dbde6acc197e211352c7c16a3e0ff3121/common/lib/src/i18n/generated

TL;DR; The propose is to

• modify generated messages to share common interface (that would be easy)
• add _all file, which would provide switching or other stuff for locales (dunno how to generate the list using build)

---

Dunno, share your opinion, please. ✌️ Maybe I'm just wrong. 🤷‍♂

[Tomucha]

Dude. First of all - thanks for your suggestions.

Second - why would you stuff everything on one issue?

And the third ... we will have to discuss it in Czech, preferably in person ... DevFest? Next Flutter Meetup?

However, if I understand correctly:

Message accessor which would generate that ugly switch statement - good idea, but I'm not sure if it's possible ... build_runner is quite restrictive. I'm not sure if I can generate a file based on several inputs ... maybe not. Must investigate.

Sharing common interface - that's already happening, everything extends "English" at this point.

[tenhobi]

We can discuss it at the next Flutter Meetup. 😉