Possibility of merging rodauth-i18n into core

[janko]

I was talking with @HoneyryderChuck during some recent improvements to rodauth-i18n about the possibility of merging rodauth-i18n into core. Given that the I18n gem is the de facto translation solution for Ruby, I agreed it might make sense for Rodauth to ship with the integration for it by default.

The rodauth-i18n provides some additional niceties beyond what's shown in the official guide, such as configuration-specific translations, default translations for various languages, and an API for 3rd-party plugins.

We were wondering what do you think about it? I understand it would be an additional maintenance burden, but I thought I'd check 🙂

[HoneyryderChuck]

Thx for kickstarting the discussion @janko . Just wanted to add, as further arguments, that the implementation is low overhead (little added public config API), is based on the defacto ruby standard for translations, in itself similar to how the jwt plugin relies on the "jwt" lib, and by being supported and documented upstream, can document and support best practices, such as keeping translations in the same direction ("config/locales").

There are a few rails-only parts in the current lib, but these could move IMO to "rodauth-rails" I it's part of rodauth core.

[jeremyevans]

Sorry, I don't want to take on maintaining rodauth-i18n, so I think it is best kept as an external gem (similar to rodauth-rails).

[janko]

Thank you for the honest reply 🙂 Great, that means I don't have any extra work either, as rodauth-i18n can stay unchanged.

After the release of rodauth-rails 1.0 that I plan for next week, I would like to start recording screencasts about Rodauth, so I just wanted to look ahead for any potential changes that could make the screencast get outdated quickly. Everything seems to be ready now, and with the release of Rails 7 setting up Bootstrap is as easy as passing a CLI option to rails new 🤞🏻