i18n VS Simple Form

Ruby on Rails provides built-in support for I18n, making it easy to create and manage translations for different languages. The humanization helpers of ActiveRecord and ActiveModel I18n, and you can leverage this to make you application support multiple languages, and to also humanize your object names and attributes to generate human readable content and forms.

I18n enables L10n. It is what makes your application responsive to the long list of L10n requirements. It will manipulate the way the data is delivered, it will change the design in case of an RTL (Right-to-Left) language, will pluralize words, manage time zones, etc… You might know that there are libraries that can help with that, but are you sure it is 1/ well maintained, 2/ following the standards? Wait, what standards? Ha! Glad you asked! Have you heard about Unicode? I won’t explain everything Unicode manages, but let's say simply that it is a Worldwide organization that defines the standards for character encoding and localization data for the industry (standards like ICU and CLDR, which probably deserve a separate article). The main libraries for internationalization use these standards. For example, Intl for front-end JS which is shipped with Node.JS, or ruby-i18n which is shipped with Rails. And let's not forget about mobile development: Android (using Java) and iOS (using Swift) are also using these standards behind the scene. Though while it's a good thing that these libraries cover the essentials, you also sometimes need to add some logic specific to your business, product, and users.

If you are planning to create a Rails application in languages other than English, let Rails help you with the translation. Ruby I18n gem provides an easy-to-use framework for translating your application to a single custom language or for providing multi-language support in your application so that you can focus on the development.

I also tend to use gems like simple_form to generate my form HTML, and this saves me from having to maintain a lot of view code to outputting translated content onto forms. Also simple_form has it's own i18n convention that compliments the Rails default pretty well.

I followed the RailsCasts tutorial and its GitHub page to set up the gem in my application and used it for all of the models in my application. It was working perfectly fine showing the default error message at the top and the validation message at the bottom of their respective fields.

Okay now for those "buttons". We don't want just a normal button or link though. This is where we need the booking update form. Let's use simple_form_for (check out the docs here).

There are many ways to create a form in Rails, whether you want to create a form with Form builder from Rails itself or maybe using third party gem like simple_form. Of course, simple_form is not the only option we have to build form in rails, there are alternatives out there such as formtastic, cocoon, nested_form, etc. However, in this post I'm going to give you a basic use case to use simple_form in Rails application.

I usually go with simple_form, I customise my forms by configuring it and letting it handle the repeated rendering.

Simple Form gem

The biggest unclear area that we saw related to view components were forms. There were glimpses of compatibility issues with Rails form helpers in the documentation and we saw a recent effort of the team to mitigate them. Moreover, we were used to building forms with Simple Form which added another variable to the equation. And, in general, we considered the Rails form builders (as well as the Simple Form builder) a system of form-related components in the first place so we were unsure how this would fit into the View Components ecosystem or whether we should even try to do that.

Learn more about simple form: 1) https://github.com/heartcombo/simple_form 2) https://www.youtube.com/watch?v=NfZk74R2Oi4&t=5s