DX: Place i18n behind a feature flag.

[gibbz00]

I'm currently not interested in i18n support, and I'm writing an application where that binary size should be kept as small as possible.

Took a quick look at the crates.io metadata size and the dependency tree, and saw that the metrics were 1.42 MiB and 30% related to i18n respectively, both of which are a lot 🙈

Would such a change be viable?

[str4d]

Hmm, this would be tricky to do, and would not drop all the translation dependencies.

I use Fluent for translations because it is much easier to work with than gettext (.po files), but one of the reasons it's easier is that all translation strings have dedicated IDs, and the "source language" is just another translation file. gettext translations use the source language translation strings as the IDs, which causes a bunch of issues for creating translations, but one advantage is you can disable translations by just replacing the translator function with a pass-through (that just returns the source string).

I will not be moving away from Fluent, so that means there is a minimum required amount of machinery to take the single desired source language and hook it into the binary. It might be possible to remove a bunch of unnecessary translation code, but that would require changes to my upstream dependencies if they don't already have this functionality.

One thing that might be more feasible, is to feature flag off support for more than one language. That would remove other languages from the binary, at least reducing the binary size that way. If someone wanted to investigate this, it would be interesting to see how it could be done in a maintainable way.

[gibbz00]

Hey, thanks for the thoughtful response :)

I like the idea of instead placing languages behind features flags. I should say though, (knowing nothing about i18n in rust), that feature flags should be additive. Cargo is very clear about this: https://doc.rust-lang.org/cargo/reference/features.html#feature-unification

[..] features should be additive. That is, enabling a feature should not disable functionality.

I'm up for taking a look at this once it becomes relevant to the project I'm working on ✌️.

[str4d]

Indeed, so the way it would be done (if even possible) is a default-enabled "all languages" flag, which depends on various per-language flags. Then someone can disable default features and re-enable whichever languages they want (though at least one must be present).