Iteration K3: Translating Checkout

Now we’re entering the home stretch. The new order page is next:

Here’s the form that’s used by this page:

That covers the form elements that Rails is rendering, but what about the React-rendered payment details we added in ​Iteration H1: Adding Fields Dynamically to a Form​? If you recall, we had to create the HTML form elements inside React components, mimicking what Rails form helpers would do.

Since React is rendering our payment details components—--not Rails—--we need to make our translations available to React, meaning they must be available in JavaScript. The i18n-js library will do just that.^[80]

This library will make a copy of our translations as a JavaScript object and provide an object called I18n that allows us to access them. Our React components will use that to provide localized strings for the dynamic form we created earlier. First, we’ll add it to our Gemfile.

Install it with bundle install. Getting i18n-js to work requires a bit of configuration, so let’s do that before we start using it in our React components.

First, we’ll configure i18n-js to convert our translations. This is done by a middleware that the gem provides.^[81] A middleware is a way to add behavior to all requests served by a Rails app by manipulating an internal data structure. In the case of i18n-js, its middleware makes sure that the JavaScript copy of our translations is in sync with those in config/locales.

We can set this up by adding a line of code to config/application.rb:

This requires restarting our server, so if you are currently running it, go ahead and restart it now.

Next, we need to tell Rails to serve up the translations that i18n-js provides. We also need to make the I18n object available. We can do that by adding two require directives to app/assets/javascripts/application.js. These directives tell Rails to include the referenced JavaScript libraries when serving up pages. Since the JavaScript files that come with i18n-js are inside a gem, we have to do this explicitly.

The last bit of configuration we need for i18n-js is to tell it what the currently chosen locale is. We can do that by rendering a dynamic script tag in our application layout in app/views/layouts/application.html.erb.

Note that we want this tag to appear after the call to javascript_pack_tag so that I18n will have been defined.

With this in place, we need to add calls to I18n.t inside the JSX of our React components. This is straightforward to do using the curly brace syntax we’ve seen before. Let’s start with the main component in app/javascript/PayTypeSelector/index.jsx. Here’s the entire class with the render method fully localized.

Although I18n.t is similar to Rails’ t, note the subtle difference in the argument to the method. In our Rails view, we can simply use t(".pay_type") which, as we learned in ​Iteration K2: Translating the Storefront​, allows Rails to figure out from the template name where the strings are in the locale YAML files. We can’t take advantage of this with i18n-js, so we must specify the complete path to the translation in the YAML file.

Next, let’s do this to the three components that make up our payment details view. First up is app/javascript/PayTypeSelector/CheckPayType.jsx (note we aren’t highlighting code here because we are essentially changing the entire render method on each component):

Now, CreditCardPayType.jsx:

And finally PurchaseOrderPayType.jsx:

With those done, here are the corresponding locale definitions:

See the following screenshot for the completed form.

All looks good until we click the Realizar Pedido button prematurely and see the results shown in the screenshot. The error messages that Active Record produces can also be translated; what we need to do is supply the translations:

Although you can create these with many trips to Google Translate, the Rails i18n gem’s GitHub repo contains a lot of translations for common strings in many languages.^[82]

Note that messages with counts typically have two forms: errors.template.header.one is the message that’s produced when there’s one error, and errors.template.header.other is produced otherwise. This gives the translators the opportunity to provide the correct pluralization of nouns and to match verbs with the nouns.

Since we once again made use of HTML entities, we want these error messages to be displayed as is (or in Rails parlance, raw). We also need to translate the error messages. So, again, we modify the form:

Note that we’re passing the count and model name (which is, itself, enabled for translation) on the translate call for the error template header. With these changes in place, we try again and see improvement, as shown in the following screenshot.

That’s better, but the names of the model and the attributes bleed through the interface. This is OK in English, because the names we picked work for English. We need to provide translations for each model. This, too, goes into the YAML file:

Note that there’s no need to provide English equivalents for this, because those messages are built into Rails.

We’re pleased to see the model and attribute names translated in the following screenshot; we fill out the form, we submit the order, and we get a “Thank you for your order” message.

We need to update the flash messages and add the locale to the store_index_url:

Next, we adjust the test to match:

Finally, we provide the translations:

See the cheery message in the next screenshot.