This is a pretty big task so I probably won't work on it for a while.

When in early stage of development you dont want to work on translations yet but you already want to include the string management. When trying to compile with just a english translation file:

../../.dub/packages/i18n-0.1.0/source/i18n/text.d(347,20): Error: template std.range.zip cannot deduce function from argument types !()(string[], void[]), candidates are:
/usr/include/dmd/phobos/std/range/package.d(3739,6):        std.range.zip(Ranges...)(Ranges ranges) if (Ranges.length && allSatisfy!(isInputRange, Ranges))
/usr/include/dmd/phobos/std/range/package.d(3772,6):        std.range.zip(Ranges...)(StoppingPolicy sp, Ranges ranges) if (Ranges.length && allSatisfy!(isInputRange, Ranges))
../../.dub/packages/i18n-0.1.0/source/i18n/text.d(453,1): Error: template instance i18n.text.Strings!() error instantiating
source/app.d(5,10):        instantiated from here: strings!()

This would enable building the translations separately from the application.

This could improve readability in some cases, and allow the programmer to prepare for internationalization without creating string resources. Additionally, a tool could be provided that uses the -version=list_string_references feature to generate an initial primary catalog, much like xgettext.

By specifying the desired encoding at compile-time, no transcoding will be necessary at runtime.

This foregos pure lookups so it should be a compile-time switch.