Why use slang over the recommended flutter_localizations package?

[pattobrien]

For starters, this is not meant to be criticism whatsoever. I'm just curious to understand the motivation of creating slang, and why developers typically want to use it over the officially supported l10n flutter package. I used slang briefly and it works reliably + the docs are great, but I didn't immediately see any use cases that would warrant switching (please change my mind!)

I guess one of the use cases that flutter_localization doesn't support is the ability to override translations so that they could be loaded dynamically (e.g. via backend). On the other hand, it seems like a rare use case that would possibly not worth the effort of learning another l10n json standard.

Anyways - thanks for a great package! :)

[Tienisto]

Hello, thanks for using the package!

Slang has a long history and was formerly known as fast_i18n. At the time of creation, i18n was a lot more difficult as it is now. I wanted an i18n package that uses nested JSON for better readability and also code generation to avoid typos when accessing i18n.

You are right, the current l10n implementation by the Flutter team is good enough for most use cases. Slang however, offers some features that might be useful to your project:

• JSON format in slang is more concise
• CSV format might be useful if you have a CSV plugin so you basically just fill out a table
• If you have multiple projects, you can write a common i18n library: You can use multiple slang instances at once
• Dart only support (might be useful if you have a backend that is written in Dart)
• Translation overrides (as you have mentioned) to dynamically update from backend
• More tooling: Slang can find missing translations and offers many CLI tools to make your life easier
• Rich Text: You can have i18n with styling
• Obfuscation: You might want to encrypt your translations (which will just make reverse engineering harder but not impossible)

Just some examples that are not in the official l10n implementation (yet).

[fzyzcjy]

My two cents: In addition to all these points, I personally love slang because of

• Strongly typed: https://pub.dev/packages/flutter_localization does not seem to be very strongly typed, while when using slang, I can ensure I get a compile error if I wrongly type the name, unexpectedly missing a translation, etc.
• Context-less: Some part of my code does not depend on BuildContext, and slang does support to get string without a context (not sure whether flutter_localization supports as well, but from its README it does not mention such usage)

[pattobrien]

You are right, the current l10n implementation by the Flutter team is good enough for most use cases. Slang however, offers some features that might be useful to your project

Okay I see what you mean; rich text and dart-only support are pretty awesome features. In fact, I question why the official Flutter package and the Locale class is dependent on the flutter sdk at all. It's just text and tooling, after all.

does not seem to be very strongly typed

You seem to be confusing that package on pub with the flutter_localizations package from the Flutter SDK, which is strongly typed (but also BuildContext dependent). I agree, with your second point though, that using localization packages without BuildContext has its place, and thats difficult to do with the built-in Flutter package.

[fzyzcjy]

Thanks, I checked https://docs.flutter.dev/ui/accessibility-and-internationalization/internationalization and it is also codegen based. (IIRC I did read that page long long ago, but somehow I forgot it and looked at the pub package 😆)