Attached patch adds a small submodule to implement message type translation and makes sure the translated descriptions show up in the message type views exposed form.

Patch requires a entity api dev version for the i18n stuff to work. For the views exposed form to work it even requires the latest version (as of now) as I've just added a sensible Entity::defaultLabel() method which returns the translated entity property label.

Patch attached.

Files: 
CommentFileSizeAuthor
#9 message-i18n-1479026-9.patch3.48 KBklausi
#7 1479026-message_i18n-7.patch3.43 KBmh86
#4 message_i18n.patch4.25 KBfago
PASSED: [[SimpleTest]]: [MySQL] 37 pass(es).
[ View ]
message_i18n.patch3.42 KBfago
PASSED: [[SimpleTest]]: [MySQL] 33 pass(es).
[ View ]

Comments

What is the use case of having a translated message type (and not just translating the message-text)?

My use-case is in conjunction with Views (see the fixed filter), so you can expose the filter to users / site-admins in the correct translation.

I'm using latest -dev of Entity API + i18n, but when I go as uid1 to admin/structure/messages/manage/foo/translate -- I get access denied.

StatusFileSize
new4.25 KB
PASSED: [[SimpleTest]]: [MySQL] 37 pass(es).
[ View ]

Looks like I only test the general translation interface, sry for that.

I had another look at it and fixed that issue by adding in a menu-wildcard + added an i18n string wrapper to declare the message can be localized (which is not default once a language is there). Given that changes the i18n access callback works for me.

When I enable module + message-example and create messages, I no longer see them in the message-example View. Is it working ok for you?

Status:Needs review» Needs work

Patch no longer applies + comment from #5

StatusFileSize
new3.43 KB

Re-rolled Wolfgang's patch from #4.

Message example does not work because they do not have a message text for specific languages, only for LANGUAGE_NONE. Maybe we should have a fallback for messages texts to LANGUAGE_NONE, but that's not a topic of this issue.

Unfortunately I couldn't get the translate tab (admin/structure/messages/manage/%message_type/translate) working yet. What I found out is that i18n_string_object_wrapper is used to check the access. The access to the translate page is based on the translation mode, which returns I18N_MODE_NONE for message types, as they have a language property set and in i18n_object_wrapper::get_translate_access() access is denied for such cases. Other configuration entities (profile2 types, rule links, etc.) don't have a language property and I'm wondering, why this is needed for the message types (message text per language is stored in the field table anyway)?

Maybe we should have a fallback for messages texts to LANGUAGE_NONE, but that's not a topic of this issue.

#1782134: Translatable fields: Not overriding language-none values with empty default-language values ?

why this is needed for the message types (message text per language is stored in the field table anyway)?

This was raised by Gabor (and I think fago was in the conversation), about an entity should always have a language property. For a better explanation better consult with him.

StatusFileSize
new3.48 KB

Patch rerolled for my drush make file, no other changes.