Feature Request: Support for Accessing Translations via Key in intl_utils

[TheWalkingDead2]

Currently, the intl_utils package generates methods for each translation key from .arb files, which is convenient for static access. However, for some dynamic use cases where the translation keys are determined at runtime (e.g., fetched from a server or user-generated content), it would be beneficial to have the ability to access translations directly by key strings.

Proposed Feature
I propose adding functionality to the intl_utils package that allows developers to retrieve translations directly by specifying a key as a string. This would complement the existing method generation and not replace any current functionality.

Use Cases
Dynamic Content: Applications that receive part of their UI text from a server response which includes translation keys.
Plugin Systems: Allowing plugins or modules to specify their own keys without needing to regenerate the entire S class.
Suggested Implementation
A possible implementation could involve generating an additional method in the S class that takes a key as a string and returns the corresponding translation if it exists. Example:

String translate(String key) {
  switch(key) {
    case 'hello': return hello;
    case 'welcome': return welcome;
    // include all keys
    default: return key; // or throw, based on configuration
  }
}

Benefits
Flexibility: Allows developers to handle translations dynamically, increasing the flexibility of the intl_utils.
Integration: Makes it easier to integrate with dynamic content systems or external modules.
I believe this feature would significantly enhance the utility of intl_utils for many Flutter developers. Looking forward to your thoughts and feedback on this suggestion.

[lzoran]

Both approaches have their advantages and disadvantages. Static access to localization messages enables autocomplete functionality in the IDE and prevents potential bugs associated with using non-existent messages through code analysis. On the other hand, dynamic access offers more flexibility but requires careful attention to detail from developers, such as specifying exact string key values, avoiding typos, and addressing similar concerns.

However, for managing a smaller number of localization messages dynamically, you might find the ICU Select helpful.

Example:

"commonVehicleType": "{vehicleType, select, sedan {Sedan} cabriolet {Solid roof cabriolet} truck {16 wheel truck} other {Other}}",
"@commonVehicleType": {
  "description": "Vehicle type",
  "placeholders": {
    "vehicleType": {}
  }
}

Then, just invoke the message that suits the passed argument:

const vehicleType = 'cabriolet';
S.of(context).commonVehicleType(vehicleType)

This approach is well-suited for managing a smaller volume of related localization messages that require dynamic access, such as displaying localized error messages corresponding to error codes received from the server and similar scenarios.