Suggest new I18n shard

[wout]

Currently, the internationalization section in the guide suggests using vladfaust/i18n.cr. That shard is lacking in functionality and it hasn't received an update in three years.

I'd suggest using crystal-i18n/i18n instead. It's pretty well-rounded, supports multi-file locales and even has decent documentation:

https://crystal-i18n.github.io/

[stephendolan]

I found working with this TechMagister shard enjoyable as well: https://luckycasts.com/videos/translations

I'm not 100% sure how up to date it is now, though.

[wout]

I've been looking at that shard too. They both look pretty similar in functionality. We should probably run a benchmark to see which one is performing better.

[ghost]

I'm with @wout here 👍🏻 I've been using crystal-I18n/i18n and had no issues so far 👍🏻 the embedding of translations works really great 👍🏻. And I had some issues with versions with TechMagister

[wout]

@Liberatys For the time being, I've installed that shard as well, and it works great. It's the most feature-rich of all, I think.

There is only one thing that's bothering me. Locale keys are evaluated at runtime, which means possible missing translations. I'd rather have them evaluated at compile-time and have the compiler complain when a key is missing or has a typo. It's one of the advantages of using a compiled language we can do those checks.

We're discussing it further here in luckyframework/lucky#1284. If it's not going in the core, I'm going to see if it's possible to include it in a custom loader for the shard. If that doesn't work or is too awkward to build, I'll probably roll my own shard.

[jwoertink]

Just documenting here that the TechMagister looks like it's been moved https://github.com/crimson-knight/i18n.cr but also updated and will be getting a few more updates.

[syeopite]

May I suggest lens? https://github.com/syeopite/lens It's a recent project of mine that aims to tackle the internationalization issues seen in various crystal projects. It currently supports both GNU Gettext and the typical YAML based format. I've also been working on full CLDR data support to implement proper number and time localization too!

I know it's rather new and slightly different than most i18n shards, but if possible I'd like to offer it on the table of discussion here.

[jwoertink]

It looks like we have quite a few to choose from now considering @wout also has started a new one https://github.com/wout/rosetta which aims to handle translations with compile-time checking (Very Luckyish!)

I wonder if the best solution would be to remove the guides for internationalization completely. Then maybe just list out all of the shards as options. 🤔

The thing is, the original one suggested on the site was actually integrated in to a Lucky app. If we do decide to keep a full guide on adding this in to your app, I'd really like to see a blog post on how to integrate that shard (whichever one it is) in to a Lucky app first. This way we at least know that someone out there is using that in a Lucky app, and we're not just picking a shard for the sake of having something. Does that make sense? @syeopite are you using your project in a Lucky app by chance?

[wout]

It looks like we have quite a few to choose from now considering @wout also has started a new one.

There are quite a few, but there is only one other shard that's handling key lookup at compile-time. And it doesn't use YAML/JSON, which I prefer.

Although Rosetta should work with any Crystal app, I'm building it with Lucky in mind.

I wonder if the best solution would be to remove the guides for internationalization completely.

I don't think what would be necessary. Those instructions are largely applicable to most other shards as well, with some minor differences in initialization and maybe the name of the translate method.

For Rosetta, those instructions can be quite a bit shorter because it includes a mixin with convenience methods for class instances.

I have been thinking about proposing an Internationalization adapter for Lucky. Not unlike those Carbon adaptors for email. Then every shard owner could include a LuckyI18nAdapter, making implementation trivial. And users will then be able to choose one of the shards that implement the adapter, or write an adapter themselves.

[wout]

In the meantime, a lot of work has gone into Rosetta dedicated support for Lucky has been added:

https://wout.github.io/rosetta/latest/getting_started/#using-lucky

If we're suggesting Rosetta in the documentation, the internationalization section can be simplified a lot.

[jwoertink]

I'm down for using it in the docs. Looking through what you have feels very Lucky-ish with the compile-time catches, and the speed. 👍

[wout]

Great! Yeah, I'm trying to do as much as possible at compile-time. And the speed difference with existing libs was a big surprise to me too. I kind of expected a bit of an improvement, but not that much.

Let me first tackle the last big issue, which is pluralization. Then I'll submit a PR with the changes for the Lucky docs.

Really excited about this!