Amber: [I18n] Support for Internationalization

[elorest]

As a Developer I want to abstract all strings and other locale specific bits (such as date or currency formats) out of the application

Acceptance Criteria:

• [ ] Ensure you have support for i18n.
• [ ] Setup where to find locale dictionaries.
• [ ] Setup how to set, preserve and switch locales.

[msdos621]

Would it make sense to integrate this i18n https://github.com/TechMagister/i18n.cr , it seems to be what kemalyst uses.

[eliasjpr]

@usbsnowcrash feel free to propose an implementation of i18n

[akzhan]

I prefer node/babelfish and it should be easy to convert it to crystal.

Demo.

So I18n may be pluggable.

[akzhan]

Just started https://github.com/akzhan/crystal-cldr (L10n foundation).

[marksiemers]

@amberframework/core-team - We'll need to revisit this to decide what, if any work needs to be done in amber itself. Also, see what I18n solutions exist in the crystal eco-system now.

[eliasjpr]

We either need to provide some integration guide or a basic setup for this

[drujensen]

we might be able to copy/leverage this middleware from Kemalyst

[docelic]

After looking into the comments above and all combinations of searches for existing Crystal shards, looks like the choices are (in no particular order).

https://github.com/akzhan/crystal-cldr
https://github.com/olbat/icu.cr
https://github.com/TechMagister/i18n.cr (and related https://github.com/TechMagister/kemalyst-i18n)

[imdrasil]

I would suggest @TechMagister shard, but it has 2 major issues:

• it doesn't support multiple localization files for one language (working on PR for this)
• it doesn't support named interpolation inside of translation - just %s etc. (almost done this as well)

[docelic]

@imdrasil are you in contact with the shard author? I haven't been able to reach him lately.

[imdrasil]

@docelic no. I've thought he would be available but as I can see - I'm wrong :disappointed:

[imdrasil]

I've created a fork of his repo - if he doesn't response I will continue support my fork of his repo

[TechMagister]

I didn't received any notification from github, sorry 😕
I'll take a look at your work right away.

[docelic]

@TechMagister I tried to reach you via Gitter and I also sent you an email, receiving no response. See my Liquid PRs.

[faustinoaq]

Can we support translation using .po files and gettext ?

So we could use translation editors like https://poedit.net/, WDYT?

[imdrasil]

@faustinoaq it looks like interesting thing but I'm not pretty sure if this is reasonable and useful for current state. Also in the ruby world it is not widely spread

[imdrasil]

@elorest please take a look on https://github.com/TechMagister/i18n.cr - now, I guess, it satisfies basic requirements for internationalization

[docelic]

Hey @eliasjpr @imdrasil @elorest, I made progress on this one using @TechMagister's i18n shard.
I've repurposed his kemalyst-i18n shard (which was much simpler than I thought) and now for Amber this works roughly in the following way:

0) One adds "amber_i18n" shard to shards.yml
1) In config/application.cr one adds an "Amber::I18n.configure" block if defaults need to be changed
2) In config/routes.cr one adds Amber::Pipe::I18n which discovers the language from Accept-Language header and sets ::I18n.locale value

I've got a couple related questions about the overall functionality:

1) Do you want to keep i18n as a shard (like it's done now), or I should prepare a PR to be directly merged into Amber?
2) Is it OK if in config/application.cr after the Amber::Server.configure block one needs to add Amber::I18n.configure block, or this should be merged into the main server's configure block?
3) Should the folder with locales be directly "./locales" on the top-level of an application, or something else?
4) Is it OK that current locale is read from ::I18n.locale? That's how the kemalyst-i18n does it, but I would think it would be better that this value (at least for the programmer) resides in Amber.locale, or context.locale, or similar?
5) 1) How would you prefer translate and localize methods to be called, do we keep the names "translate" and "localize"?
5) 2) Do we keep calling translate/localize under the I18n namespace or we add these methods under Amber module? (Like Amber.translate and Amber.localize)
5) 3) Do we create "t" and "l" shorthands out of the box, or we leave that as minor local customization for app developers if/when they want it?

[eliasjpr]

Do you want to keep i18n as a shard (like it's done now), or I should prepare a PR to be directly merged into Amber?

I am fine with a separate shard for i18n, let me know if you don't have repo create access I will create a repo for you. Also we have the naming convention of prefixing shards with a crystal name in front so like {Type Crystal}::i18n (You can pick the crystal since you have authored the i18n.

Is it OK if in config/application.cr after the Amber::Server.configure block one needs to add Amber::I18n.configure block, or this should be merged into the main server's configure block?

I would like to this to have its own initializer file just like granite. This will keep it consistent with the other shards.

Should the folder with locales be directly "./locales" on the top-level of an application, or something else?

Rails applications have a /config/locales I almost feel that this can live under the src/locales @amberframework/core-team please weight in.

Is it OK that current locale is read from ::I18n.locale? That's how the kemalyst-i18n does it, but I would think it would be better that this value (at least for the programmer) resides in Amber.locale, or context.locale, or similar?

This feels more of a context concern that Amber it self. I do not foresee people using locale outside of the context. I can be wrong.

5.1) How would you prefer translate and localize methods to be called, do we keep the names "translate" and "localize"?

I like the names I don't have any other suggestions.

Do we keep calling translate/localize under the I18n namespace or we add these methods under Amber module? (Like Amber.translate and Amber.localize)

I vote i18n namespace. Again I don't think this is an Amber concern. We can create an i18n module that people can include where they need the methods

5.3) Do we create "t" and "l" shorthands out of the box, or we leave that as minor local customization for app developers if/when they want it?

Yes 👍

[imdrasil]

yeah, @eliasjpr has just overtaken me - totally agree with him

[docelic]

Hey @eliasjpr, regarding your comment "I am fine with a separate shard for i18n, let me know if you don't have repo create access I will create a repo for you."

Yes, please create it and I will submit PRs to it then. Thanks!

[eliasjpr]

@docelic see https://github.com/amberframework/citrine-i18n

[docelic]

Great, thanks, the shard code is in there now, and what remains is to integrate this into Amber as per above guidelines. I'll submit that PR to amber as soon as I manage.

[docelic]

Solved with https://github.com/amberframework/amber/pull/652