[gen_l10n] Generate static localization keys

[twister21]

Use case

My business logic is executed in a separate class (ViewModel/BLoC pattern) that doesn't have access to Flutter's BuildContext. However, I need to pass localized messages back to the UI in a reactive way (via StreamController/PublishSubject).

ViewModel class:

PublishSubject<String> errorMessage = PublishSubject();

void submit() {
  try {
    // Execute business logic
  } catch(e) {
    // Pass error message to subscriber
    errorMessage.add("submission_error");
  }
}

Screen widget:

@override
void initState() {
  super.initState();
 
  // Subscribe to error messages
  _viewModel.errorMessage.listen((message) => _showSnackbar(message));
}

Proposal

The gen_l10n tool should generate static keys which can be resolved into localized messages when the BuildContext is available.

That's how Android basically manages all kinds of resources like strings, dimensions or colors. The resource IDs (automatically generated integer constants) can be referenced from anywhere (R.string.submission_error), but can only be converted into strings within the application context.

// Generated class
class LocaleKey {
  LocaleKey._();

  static String submissionError = "submission_error";
}

Example usage:

errorMessage.add(LocaleKey.submissionError);

...

_viewModel.errorMessage.listen((localeKey) {
    String localizedMessage = AppLocalizations.of(context).t(localeKey);
    _showSnackbar(localizedMessage);
}

Or with an extension function:
context.getString(localeKey)

[MTRNord]

We have a similar issue that might be fixed by this. (If not feel free to tell me to open another issue). We have a dart library where we want to also localize things. Previously this has been done by letting AppLocalizations extend a class inside of the dart library which defines its keys. Now, this is not possible anymore. As its a pure dart lib we cant use BuildContext in there either so either this works for it or if you think I should add another issue about allowing classes that shall be extended that would be fine too.

[HansMuller]

CC @shihaohong