904: Add i18n for translations

[steffenkleinle]

Short description

This PR extracts all user visible text constants to a new arb file asset and adds general support for i18n.

Proposed changes

• l10n/localization is setup
• All text constants are extracted to a new arb file
• All former text constants are now translated using l10n

Fixes #904.

---

[michael-markl]

Just a general comment: Did you consider using the "standard flutter" approach of localization as described in their docs?
https://docs.flutter.dev/ui/accessibility-and-localization/internationalization

[steffenkleinle]

Just a general comment: Did you consider using the "standard flutter" approach of localization as described in their docs? https://docs.flutter.dev/ui/accessibility-and-localization/internationalization

@michael-markl tbh just because I am used to react-native where you need a library for everything, so I didn't even check.

However, one thing that does not work with the standard flutter approach: It uses .arb files intstead of normal .json files which doesn't support namespaces. What would works is keys like categories_culture or similar with underscores.

Opinions on whether we should use the standard way and work around the namespace issue or stick to the current library? @michael-markl @f1sh1918 @sarahsporck

[michael-markl]

@steffenkleinle According to the ARB spec (see https://github.com/google/app-resource-bundle/wiki/ApplicationResourceBundleSpecification#arb-namespace-and-registration) there might be some namespace support, however, I don't know whether the Flutter implementation supports this.

[michael-markl]

One benefit of the ARB-way would be "type"-safety (in the sense that you cannot misspell translation keys) as special Dart code is generated from the ARB file (if I understand correctly).

(It's not a recommendation from me, but I am kind of interested in these ARB files. I like that (a) the translation files have some proper spec, and (b) that translation keys can also hold meta data like a description or a screenshot).

[steffenkleinle]

One benefit of the ARB-way would be "type"-safety (in the sense that you cannot misspell translation keys) as special Dart code is generated from the ARB file (if I understand correctly).

(It's not a recommendation from me, but I am kind of interested in these ARB files. I like that (a) the translation files have some proper spec, and (b) that translation keys can also hold meta data like a description or a screenshot).

Agreeing with all the points. One drawback would be that the tools we use in the integreat project to handle constants won't work anymore/would need some adjustments. I think I would still give those ARB files a try, because I think the typesafety is a huge pro.

[steffenkleinle]

A few notes, while in general the localization works pretty nice (typesafety 🎉), it seems like no features are really implemented at the moment and there are a few problems for us:

• No nesting in an arb file -> Not possible to use nesting like we do in integreat. Instead I know used nesting identifiers separated by an underscore, e.g. about_title. Let me know if you don't like that.
• No namespaces or multiple files per locale possible even though its in the .arb specs -> might be a problem for translating the build config (even though there are hacky workarounds, e.g. including both de and en in the build config, won't scale though): [Proposal]Allow multiple arb files to organize l10n / intl localizations for a language flutter/flutter#107157
• No dynamic translations possible, which is why the refactoring of the categoryAssets with context was necessary: [Proposal] Access l18n Translations with Dynamic Keys flutter/flutter#105672

All in all it seems like a great tool in general but not that actively maintained/improved. It might work for us for now but also might have too many limitations in the future.

[steffenkleinle]

This should work so far, if you change something in app_en.arb, it should show up in the app (if your system language is set to English).

[f1sh1918]

Tested on android and ios seem to work fine for both even they recommend in the docs to add this into Info.plist.
Seem not to be require anymore.

<key>CFBundleLocalizations</key>

<array>

    <string>en</string>

    <string>ar</string>

</array>

Even tested using different system languages on device

[f1sh1918]

does this break lines like before? I think each quote part is for one line
But i think its also fine if it breaks automatically. Maybe only on tablets an issue

[steffenkleinle]

No, it doesn't lead to the same linebreaks anymore. Let me know if I should readd them. Personally I think its perhaps better to let flutter handle it depending on the screen size?

[steffenkleinle]

Will keep it as it is :)

[sarahsporck]

Looks good!