i18n_field label in the same language as content when viewed

I've set "User interface text language detection" to "User" and "Content language detection" to "URL". It should, in my use-case, be possible to read content in all languages, but the interface should stay in a known language to the user.

Currently, field labels is more "User interface" than "Content" and I agree 50% with this. In my opinion, when you're viewing content, labels should be treated as content. When editing content, labels could very well be treated as user interface. I think those labels should follow the content language too. You wouldn't work on a translation without understanding the language and then surely you'd be able to understand the labels too.

However, when content that exists in language A and B are viewed, it makes sense to me that the labels to fields in the content also is shown in language A and B respectively.

This patch only fixes the viewing part. I've still not decided on the editing part and I wanted something as little intrusive as possible.

It's i18n_field_field_attach_view_alter() that alters how a field is displayed and translates the field with i18n_field_translate_property(). In hook_field_attach_view_alter there is a $context array containing the current language of the viewed content... i18n_field_translate_property() is also able to accept a langcode... but it's not used.

Translation is hard and there are a million different use-cases, but it seems to me that passing along the language from the context should be no problem. What this patch does is pass along the langcode so that labels are shown in the same language as the content independent on the user interface text language detection config. The interface itself will still respect whatever detection is enabled.

If there is a use-case where this blows up, please enlighten me.

See attached patch.