Open wvengen opened 11 years ago
Often labels are referenced in the simple_form
namespace; this better be changed to be ActiveRecord.
started moving keys from the simple_form
namespace to activerecord
in branch i18n
activerecords.attributes.articles.price
in views? This could reduce redundant translations a lot. I also like the syntax StockArticle.human_attribute_name 'name'
(works with inheritance).fc_price
? Should we also refer to them as activerecord.attributes
?StockArticle.human_attribute_name 'supplier'
or t 'activerecords.models.supplier'
. Well, here I would vote for referring to the attribute because a model can have different meanings depending on the kind of relation.@JuliusR thanks! Responding to your points:
human_attribute_name
; and the code allows it too. When that breaks, we can still change it. Directly referring to activerecord.attributes
would be reimplementing the human_attribute_name
code (incl. a call to humanize
)I'd like to merge current changes back into master already to minimise keeping them synchronised. Please raise any objections. One thing to look at is heading_helper.
Begin 2013, foodsoft has been internationalised (meaning that all texts have been replaced by identifiers, and the texts have been associated with these identifiers) and translated to English. simple_form has been used to i18n form labels, and sometimes direct
t('simple_form.labels.foo.bar')
was used. Now these sometimes contain duplicates, and it would be useful to normalise the data, and also to move the strings to ActiveRecord's model i18n when possible. Special cases can remain in simple_form's i18n.See commit 98b729eb7189f87cf745e800d5f076f8131ba06a for an example. Also see #84 (in particular this comment)
ordering.js
)human_attribute_name
&factiverecord
namespace where sensible