Build in i18n conventions

[derekprior]

One of the nice things about simple_form is that it offers conventional locations for form i18n data. It'd be nice if cocoon did the same. While it's simple enough to add the calls to translate every time I use add or delete links, its unnecessarily tedious. Here's an idea that I kicked around for all of 10 minutes. Let me know what you think:

Define convention for i18n something like the following contrived example:

cocoon:
  add: "Add"
    user: "Add User"
    tag: "+"
  remove: "Remove"
    user: "Delete"
    tag: "-"

Calls to the add would perform a lookup to the proper node using the provided association name. Backwards compatibility would be a little tricky because arguments aren't passed as a hash, so it'd either be a breaking change or we'd have to check the number of arguments passed to determine if the i18n lookup should be done.

The remove helper doesn't explicitly take the association name, but it does tae the form builder object. We can get the class name from f.object.class.

If the specific class name translation isn't available it can fall back to the 'add' or 'remove' keys, then try to look in standard rails i18n locations to get a translation for the class name to append. If that's not available it can fall back to other sensible defaults.

Typing all this out makes it seem rather complicated, but I've really come to enjoy similar conventions offered by simple_form. The following:

= link_to_add_association t("action.add.#{Tag.model_name)"), f, :staffing_guidelines
= link_to_remove_association t('actions.delete'), f

... would become:

= link_to_add_association f, :staffing_guidelines
= link_to_remove_association f

What do you think? If it's something you think is worth pursuing, I might be able to get to it in the next couple of weeks. If you think it's too complicated or needs further fleshing out, that's fine too. I can implement this in my own project as a helper that wraps the current helpers if need be.

Thanks for the great gem!

[nathanvda]

I like this idea, however I am bit concerned about the backwards compatibility. I need to think to think about this. Isn't ruby smart enough to handle optional parameters (place-independent), or was that only ruby 1.9?

[nathanvda]

My housekeeping leaves a little to be desired, doh, this ticket is long ago fixed by #306.