As our rails projects grow bigger and bigger, the i18n locale files easily get messy and will loose their structure after a while. Especially when you have multiple software developers work on the same project.
So we develped a solution for us that is easier to handle and to maintain. The starting point is from the ruby on rails guides combined with this blog post:
We separated our yml files to the folders given by the rails structure. The yml files themself are also structured that way. This is a bit more efford in the beginning, but it is very nice to maintain, because you always know, where you have to put your locales and always know where to look for them!
Each file now only handles the content of one logical controller unit. The views/surveys files now have the content for each action. We group them in the action to logical groups that always look the same. We have a title, the breadcrumbs and then we have a unit for each form.
placeholder: 'Search surveys...'
The problem with a solution like that is, that you have lots of redundant data. Take breadcrumbs for example. In each views folder there are different actions that have the same breadcrumb navigation. But there is a nice feature that you can use for that:
We put all business dependend locals into the defaults or views/defaults folders and reference them with e.g. :defaults.surveys. That makes it easy to have on each page every element, that can be translated to each language, but also removes redundant translations. But if you come to a language that make it harder to translate everything with the same translation you can translate that one separately!! Which can be quite important for example for languages like chinese.
Why Ruby on Rails
I am writing software about 10 years by now. The last 3 years I was delighted by the great web application framework Ruby on Rails, which I don’t want to miss anymore. I want to publish articles in this blog every now and then and will mostly write about this awesome framework. So I want to tell you some good reasons, why I like to use it:
- Rails is good for rapid prototyping
- Ruby is easy to learn
- Rails code is easy to read because of the given structure
Rapid prototyping with Rails
I originally come from the java world. Setting up a new project got easier over the years but it is no comparison on what rails can do. Most blog posts I read when I started learning rails were about scaffolding. Scaffolding is a fast and easy way to create CRUD model/controller/view from scratch.
I usually do not use scaffolding in my working projects anymore, because they usually create a big overhead, but I just love that feature when it comes to a rapid prototype. A first version of our tutorize.com website was created in rails. It was not beautiful, not secure and not even close to be finished, but we had something to show to investors and possible customers. Lot of startup authors say that is the approach that works best for creating businesses without spending lots of money and time and then creating something that nobody even cares about. And I completely agree with it!
Ruby is easy to learn
I just have to say this: Ruby is a quite elegant language. If you have not tried it yet, try it. And the Rails framework is just
Rails code is easy to read because of the given structure
Rails comes with a given MVC-Pattern structure. It is really easy for other developers to dig into someone elses code because of that structure. You know where you find your models, your controllers and views and you know where the urls are build, etc. Very helpful!
And there is also the given structure of the rails engines. I started working with them a while ago and I can also say that this structure helps to understand the code of someone elses engine.
There are lots of features that I could take about right now, but I will leave some space for more posts to come. So try rails and keep on reading.