Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | message-i18n-1479026-9.patch | 3.48 KB | klausi |
| #7 | 1479026-message_i18n-7.patch | 3.43 KB | mh86 |
| #4 | message_i18n.patch | 4.25 KB | fago |
| message_i18n.patch | 3.42 KB | fago | |
Comments
Comment #1
amitaibuWhat is the use case of having a translated message type (and not just translating the message-text)?
Comment #2
fagoMy 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.
Comment #3
amitaibuI'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.
Comment #4
fagoLooks 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.
Comment #5
amitaibuWhen I enable module + message-example and create messages, I no longer see them in the message-example View. Is it working ok for you?
Comment #6
amitaibuPatch no longer applies + comment from #5
Comment #7
mh86 CreditAttribution: mh86 commentedRe-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)?
Comment #8
amitaibu#1782134: Translatable fields: Not overriding language-none values with empty default-language values ?
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.
Comment #9
klausiPatch rerolled for my drush make file, no other changes.
Comment #10
bluegeek9 CreditAttribution: bluegeek9 as a volunteer commentedComment #11
klausiHm, it looks like the Message module for Drupal 7 got unsupported. That is bad, since we are using it and would have been happy to take over maintainership for Drupal 7. Unfortunately Drupal 7 support cannot be enabled anymore once it has been disabled on a contrib module.
Please don't unsupport Drupal 7 contrib modules. Please reach out to the D7Security group instead, for many modules there are willing people to take over maintainership.
I will fork the Drupal 7 message module now into the D7Security project and enable support there.
Comment #12
klausiThis patch has been committed to the Message D7 fork at https://gitlab.com/d7security/message/-/commit/fa2ae98cc35fb77bcd981d29d...
Comment #13
amitaibu@klausi Oye. I didn't know one could not re-enable support. Maybe if we contacted Admin there, it would be possible? I think that having to fork isn't get for the community.
Comment #14
klausiI tried to discuss re-enabling support but didn't really get any response from the Drupal Security Team. It looks like they want to stand by this policy established in https://www.drupal.org/psa-2023-07-19
Anyway, I think the D7Security approach with forking is viable and will help keeping security update status information going in the future :)
Comment #15
amitaibuAlright, fair enough. Thank you for doing it!