Troubleshoot i18n YAML in Rails the Easy Way - ruby-on-rails

I waste tons of time trying to construct the the proper yaml for translating text and labels in Rails.
Is there an easy way to pinpoint what path I should use in the YAML to provide the translation?
As an example, I am using a nested simple_form with this form erb:
<%= f.input :birth_date, as:'string' %>
The label I get is Birth date and I am assuming is just coming from the model attribute.
When I debug that line and type f.object_name I get
=> "user_wizard[children_attributes]
Here's my YAML
en-US:
simple_form:
labels:
user_wizard:
children_attributes:
birth_date: "Name Date or Expected Date"
Is there a sure-fire way to log, print, probe, watch, render or query that will give the (or one) exact path I need in almost any situation? Not just simple_form or a model attribute but for error messages, buttons, mailers, etc.

We have had tons of issues with the i18n key management as well, that's why we have decided to go down a different road and display the whole key name, with a possibility to edit it in place as well. We feel that this solves the problem of finding the correct key name and filling it. Check out our solution, PhraseApp and especially our In-Context Editor.
To summarize: The best thing might be to expose the key name through code. We have built our own solution, but you probably can do it with a little monkey patch to i18n as well.

Related

adding translations to database records

I am at the end off my project. I implemented few languages.
But this moment, I have categories that are placed in database, but these categories are in my native Latvian language, what would be the trick to be able change language of these records simultaneously with display language change.
It means that If I choose locale en, then these category names are displayed in english.
Some ideas!
To store ultiple language translation within the records, I think it's bad idea.
Or to store just put latvian category name as id inside <%= I18n.t 'category_id_in_latvian'%>
and just in yml files put the translation ?
Or there are other solution?
Thanks
You should take a look at the Globalize Gem:
Github of globalize3 Gem
This gem should do exactly what you need. ;)
And if it doesn't, please, explain why by providing more details on what you want to do and I'll update my answer according to your needs.

Reference ActiveRecord attributes in textarea

I am building a simple invoice application, and I would like to allow the users to customize the text on the invoice. In addition to this, they should be able to reference specific attributes in my models, i.e. "This is a test {{Model.attribute}}", and once the text is parsed the tag is replaced with the value of that attribute.
I have looked a bit at redcloth, textile and handlebars, but it does look like a little bit overkill to be honest. For instance I would not like to allow the users to input any HTML.
I would really appreciate if someone could point me in the right direction. There is probably a gem for this that I just havent found yet.
Thanks in advance
I use liquid with simpleformat which will sanitise the text.

Is lazy lookup in Rails I18n a bad practice?

Using shorter i18n keys (e.g. t '.submit_button') in Rails views makes them easier to type, but is it actually good? When later you decide to refactor your views and partials you have to remember to update the respective localization entries. Wouldn't it be more robust to name them by their business meaning and always specify the full key-name?
Well, I'm using a mixture. ;-)
For things like "yes", "no", "submit", "cancel" I tend to use a namespace called "defaults" so I always use it like t 'defaults.cancel'. That could also address the "submit_button" thing you mentioned above.
For my specific views I decided to use the lazy lookup feature.
If you want I18n keys for specific views you have to decide what fits best for you:
If you don't mind searching your yaml file for the I18n keys and
change them if you change the view do so. The advantage is that you
save some characters for each I18n.t call of it in your view.
But if you change your view names very often (not sure why you should
have to do so :) ) then you might be better of using the way you described.
As I already said I prefer the first option since it's more convenient for me.

Omit attribute name from validation error message (at start of it)?

I write code in English but I'm currently doing a site which is fully translated to another language (validation error messages included). However, I have a problem because validation error messages always seem to include the name of the attribute the error is on at the start of the error, e.g.:
Title Prosimo izpolnite naziv fakultete.
I want to get rid of the Title at the start, like so:
Prosimo izpolnite naziv fakultete.
Any help is appreciated. I would rather see if this can be solved without installing any 3rd party plugins.
If it's possible to provide translations for attribute names, that would be a cool solution too, but I would still like to know how it can be done both ways (omit or translate).
There is no need to use the error_messages_for helper for errors, you can write your own helper using the record's errors attribute.
You can just iterate over the error objects and display their messages.

Parsing blog post tags from a text_field

Ok, so you know how you ask a question here, and in the "Tags" field you can enter several space-separated tags into a single text field?
I'm trying to replicate similar behavior in my Rails app. Except instead of questions, I'm doing a blog app (which has "posts"), and tagging those.
I'm using "form_for" to build the quick form. Inside of that I have the line:
f.text_field :tags
The problem I'm running into is, "tags" is not a field on my Post class. My Post class HABTM tags. So, somehow I need to parse the tags text field (using String.split), and pass the resulting tag Strings into my controller, so my controller can create and associated the tags along with the new blog post.
Is using "form_for" not going to work in this case? Is doing this sort of behavior beyond the design of the quick-and-dirty "form_for" functionality?
Thanks!
Unless you really want to reinvent the wheel, I would suggest using a plugin for this. ActsAsTaggableOnSteroids is a mature one. http://svn.viney.net.nz/things/rails/plugins/acts_as_taggable_on_steroids
Agree with Ben on this - there's lots of great plugins and features/helpers that make them simple to use. And you can learn a lot about how to do this in a well-designed way. Here's another good choice.
http://github.com/mbleigh/acts-as-taggable-on

Resources