cleanup i18n

[wvengen]

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 98b729e for an example. Also see #84 (in particular this comment)

• make sure there are no untranslated strings left (except in debug messages)
• use i18n-js to translate javascript (ordering.js)
• use i18n-js number localisation features
• and use human_attribute_name&f
• move model and attribute names to activerecord namespace where sensible
• reduce duplicate translations where it makes sense

[wvengen]

Often labels are referenced in the simple_form namespace; this better be changed to be ActiveRecord.

• http://guides.rubyonrails.org/i18n.html#translations-for-active-record-models
• http://iain.nl/translating-activerecord
• http://stackoverflow.com/questions/3516478/rails-i18n-and-yml-structure-for-form-labels

[wvengen]

started moving keys from the simple_form namespace to activerecord in branch i18n

[JuliusR]

• Is it a good practice to use e.g. 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).
• What about pseudo-attributes like fc_price? Should we also refer to them as activerecord.attributes?
• Same questions rises for relations like 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.

[wvengen]

@JuliusR thanks! Responding to your points:

• I have found multiple instances of it being used in views, yes I think it is meant to be.
• I've seen people use pseudo-attributes being used by 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)
• Agree om attribute name.
  I'll continue with this.

[wvengen]

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.