[Proposal]Allow multiple arb files to organize l10n / intl localizations for a language

[golane-august]

Use case

In the current app development, you cannot split your localizations into multiple files to better categorize them. You also don't have the ability to add comments to JSON files in order to better separate the categories.
In Flutter itself you also have multiple files for the different packages.

See also docs for localization.

Question is also asked on Stackoverflow with no good answer yet.

Dart package is claimed to support multiple arb files: https://pub.dev/packages/intl_translation

Proposal

• Allow multiple .arb files with the same suffix
• Let parse all files into one dart file if no template-arb-file is specified in l10n.yaml file or/and allow wildcard for this parameter: template-arb-file: "*_en.arb"

The relevant changes could be made here.

[maheshmnj]

Hi @golane-august, Thanks for filing the issue. That looks like a valid feature request.

[sbatezat]

It's also a must have from my point of view.
Having all localized strings into one file make things very complicated.

However, I think things could be even more improved than @golane-august suggestion.
Having all files into a unique folder is not suitable from my point of view.
Basically, we should have the ability to store arb files near to each linked widget.

Example of app structure I have in mind:

lib/features
   home/
       homeWidget.dart
       home_en.arb
       home_fr.arb
       ....
   awesomeFeature
       awesomeFeatureWidget.dart
       awesomeFeature_en.arb
       awesomeFeature_fr.arb

If needed, we may use special attributes of arb files, @@ locale and @@ context described at https://github.com/google/app-resource-bundle/wiki/ApplicationResourceBundleSpecification

See also this issue/comment, showing we are not the only ones interested by cleaning our arb files : #71729 (comment)

[golane-august]

@sbatezat I don't really agree on that. Although it would be nice to have more flexibility, it may is a bad idea everyone cooks their own soup. I more like the idea of having reusable strings (e.g. such as for buttons like OK or Cancel), which doesn't belong to any special widget. Also in src only should be source files and no translations. You also usually don't mix up resources or assets into source folder. If it should be really separated it's worth considering writing an extra package for this "widget" or functionality.

[ziqq]

It's also a must have from my point of view. Having all localized strings into one file make things very complicated.

However, I think things could be even more improved than @golane-august suggestion. Having all files into a unique folder is not suitable from my point of view. Basically, we should have the ability to store arb files near to each linked widget.

Example of app structure I have in mind:

lib/features
   home/
       homeWidget.dart
       home_en.arb
       home_fr.arb
       ....
   awesomeFeature
       awesomeFeatureWidget.dart
       awesomeFeature_en.arb
       awesomeFeature_fr.arb

If needed, we may use special attributes of arb files, @@ locale and @@ context described at https://github.com/google/app-resource-bundle/wiki/ApplicationResourceBundleSpecification

See also this issue/comment, showing we are not the only ones interested by cleaning our arb files : #71729 (comment)

I want to make this.

[joeldegerman99]

Agree, would be much easier to maintain if we could split it up into feature specific arb files

[ricardodalarme]

up

[vscmaster]

One more thumb-up to get localisation gens separated.
We are facing an issue with long file at the moment, that is difficult to read more than 1k lines per file.

Could you manage to generate Localisation per feature(arb file).

[cedvdb]

There doesn't seem to be anyone assigned to this. Maybe this is something the community could take on ?

[KPatel91]

We would also like something like this, akin to .NET resource files. We have quite a large app with multiple flavours, for different customers (of which some want multi-lingual, others don't) - and would like to be able to have feature-specific resources, flavour-specific resources, and just a bit of organisation.

Otherwise we end up with thousands of fields in a single file and have to manage namespacing the keys ourselves.

Would be quite nice even just to be able to simply have multiple .arb files and a parent file that lists which ones to include in the release.

[edokichuks]

This really needs to be done as it will be difficult to maintain the translation without it

[ricardodalarme]

Hey everyone, I've started working on this and already created a draft. You can check it out there. The part that generates the localizations with a namespace is already working. I plan to finish it by the end of next week.

• [WIP] Allow namespaces when generating localizations #137307

[geminiyellow]

good, hope we can use it in early 2024.

[ndrslmpk]

Any updates on this?

[cedvdb]

Any updates on this?

The PR is stale. Someone can take it over #137307