Open derekprior opened 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?
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.
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:
FormBuilder.label
and strip the label tag out of the returned value (ick).FromBuilder.label
ends up checking (it checks 2 keys before falling back to humanize)FormBuilder.label
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.
Looking into this. Haven't quite figured out what to do yet.
Sorry I haven't had much time to work on this lately. I haven't forgotten about you. :)
I'm in the same boat. No worries.
It seems that the standard form builder methods support i18n just fine. The
inputs
andinline_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.