search

stouset / twitter_bootstrap_form_for

A Rails FormBuilder DSL for generating Twitter Bootstrap forms
https://github.com/stouset/twitter_bootstrap_form_for
MIT License
409 stars 110 forks source link

Support for i18n? #26

Open derekprior opened 12 years ago

derekprior commented 12 years ago

It seems that the standard form builder methods support i18n just fine. The inputs and inline_inputs methods do not, however. Would it be worth adding some i18n to those methods inside the gem, or should the user be forced to call t() in the view? I'm still becoming familiar with the i18n API myself, so I'm not sure how this is usually handled.

If tackling it in the gem is desired, I think the simplest way might be to just call translate when those methods try to throw down a label. That works fine if you pass, say, a symbol as the label. That'd be a clear indication that you'd want translation done. What about the case where the user passes a string as the label (i.e. 'fieldsets.user_information')? How would we know if they want that translated or if they want to render that string directly?

Is there a standard practice for this? simple_form leverages the existing standard location for label translations (helpers.label.model.field) but they do not introduce new elements.

stouset commented 12 years ago

I believe this should be handled on the user end. This gem has no user-visible strings encoded into it (I hope). Usually, this is handled by whomever "owns" the string: if you provide it, you're responsible for translating it.

However, if Rails' form helpers (e.g., label) implicitly perform an internationalization on strings passed to them, then I should absolutely abide by that convention in this gem. Do the default Rails label and similar methods do this currently?

derekprior commented 12 years ago

Check boxes (and probably radio buttons) don't seem to be working right. I think the problem is here: https://github.com/stouset/twitter_bootstrap_form_for/blob/master/lib/twitter_bootstrap_form_for/form_builder.rb#L109

I think that needs to be similar to how input labels are constructed. I'm going to play with it some and probably submit a pull request in a bit.

derekprior commented 12 years ago

Ugh - turns out there's no FormBuilder API call to be made that will return the text of the i18n label without also wrapping it in a label tag. A few ideas for a workaround:

  1. Call FormBuilder.label and strip the label tag out of the returned value (ick).
  2. Construct the keys that FromBuilder.label ends up checking (it checks 2 keys before falling back to humanize)
  3. Somehow get checkboxes and radio buttons working with the default implementation of FormBuilder.label
derekprior commented 12 years ago

I think solution the first proposal was actually the most stable thing to do in this case. The third solution just wasn't working for me and solution number 2 seemed like a nightmare to maintain moving forward. I submitted pull request #27 for this.

stouset commented 12 years ago

Looking into this. Haven't quite figured out what to do yet.

stouset commented 12 years ago

Sorry I haven't had much time to work on this lately. I haven't forgotten about you. :)

derekprior commented 12 years ago

I'm in the same boat. No worries.