I’m creating this proposal to start a discussion on i18n support feature.
Thanks for the proposal. Can you please provide further details on how users would use it? Even better if you could provide pros/cons of the way Rails is doing i18n.
I think i18n is an important feature because even when my app is not going to support more than one locale, I use i18n to keep message strings, form labels (simple_form picks up i18n labels and hints) etc out of the views and controllers, mostly for reusability purposes and all the good things that comes with this (DRY, mainly). Also, you can use i18n keys in controller and integration tests.
I know that Lotus tends to avoid YAML, but that’s the de facto way of doing i18n, since it’s mostly nested key-value pairs.
A lot of people use localeapp (I can’t post more than 2 links, so just google it), so it would be nice if lotus could keep compatibility with it.
All we need to know about it is here: http://guides.rubyonrails.org/i18n.html
I like the way Rails allows you to couple ActiveRecord model names and attributes to i18n: https://gist.github.com/zavan/7a9686f8cb9f157dae54 and how simple_form use this for input labels.
Rails i18n lacks a way of getting the correct locale for the request (from headers, IP, etc), it would be nice to have some of these strategies built in.
@zavan Can you provide a minimum prototype which show how you will implement i18n in lotus, and how it would be used.
I like us to avoid YAML as much as possible due to security concern.
I am open for discussion on using ruby file with hash structure tree.
Is there any advance in this regard?
I agree with @trung_le in not using yaml and I also don’t like the idea of i18n the Entities directly. Messages must be delivered by the apps and the data should go into DTOs and not Entities. That’s a lot cleaner.
Similar to translations there is also localization (think Dates, Times, Currencies, Separators, …) which is needed to make an App available in multiple countries.
atm, there is no progress on this front yet, however we are going to discuss this topic again as we get closer to the RailsGirls Summer of Code planning.