Posted by mtaqi on June 2, 2008 at 4:25pm
| Project: | Messaging |
| Version: | 6.x-4.x-dev |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
does the notifications module support translation of email templates for digest notifications?
[event-list] needs to be translated in spanish and french.
Comments
#1
No, currently it doesn't.
It would need major development for Drupal 5, as this version doesn't support multilingual requests (would need localization to multiple languages on cron). However it's on the to-do list for Drupal 6 version.
I'm converting this into a task for the 6.x version
#2
Jose, do you have a plan on how this should be implemented?
For user notifications, where planning to use Mail Edit module, but it seems it can only be extended for mails sent using drupal_mail(). Well, this solves part of the puzzle.
As an example of what we need... where also planning to use OG, and this has lead me to Notifications/Messaging. Here, OG allows you to customize the messages, but it seems there's no method to translate them. And then we also have Messaging related Message templates. So we have to additional layers, Messaging itself and modules such as OG that use Messaging, aside from mail sent using drupal_mail().
Could Messaging (and maybe also OG) be somehow integrated with i18n?
#3
Actually, it seems to me it could be as easy as it seems, but this should be handled by Messaging framework itself, I think.
I'm attaching a patch that implements hook_locale() to create a text group for 'messaging', and then it passes message templates to i18nstrrings module if it is enabled. Doing so, the message templates can be translated using the Translate interface.
#4
This seems like a good start. However, there are a lot of things to be figured out yet, like how we select the language for each notification/message, what happens with tokens, etc..
#5
hmm... isn't this something that depends on the caller?
For example, let's look at notifications module. This one builds the messages using notifications_process_compose(), and this function gets the $account, so we can swap $GLOBALS['language'] with the account language while messaging code is processed, and that will affect the result of messaging_message_part() as well as messaging_text_replace(). That means notifications module needs a patch, but it can be patched later.
In case someone is running notifications without such a patch, the end result will be exactly as if messaging stuff was processed without altering $GLOBALS['language'], ie. it will take the current language, which is ok.
The same pattern is valid for og_notifications. It will need a patch that swaps $GLOBALS['language'] with the user language while messaging stuff is being processed.
But both, notifications and og_notifications can be patched later. First, we need to get this in.
Unless I'm missing something the patch here is compatible with existing installations.
PS: Switching back to needs review. The patch still applies, with offsets, but still applies.
#6
The patch looks really good. Some things it needs though:
- Implement a wrapper for string translation like messaging_tt(), just got notifications_tt() a few days ago. We will be using this for all string translations (other strings like messaging method names may need translation too).
- Pass the $language parameter around, instead of a $translate one so we can translate to different languages in the same request (possibly on cron). We need static caching per language too, $cache[$group][$key][$method][$language->language]
- Proper namespacing for 'string name'. Using the 'message group' as the second key may clash with other uses in the same module, so we could use something like "messaging:template:$group:$key#$method'
#7
Hi, Thanks for the great modules, they work great, except notifications arrive in the wrong language. I am trying to figure it out.
I have Internationalization 6.x-1.2, Messaging 6.x-2.2, Notifications 6.x-2.2.
I want the notifications of posts made by user B arriving at user A to be translated into user A preferred language, but they always arrive in the language selected on the language switcher when the post is made by user B. The strings are there okay and all their translations. I guess this is some variable I haven't set up correctly - is there a simple fix? It looks like the issue discussed here. I searched around but can't figure out what the problem is.
I don't know if its related but my multilingual variables dont work either. Even when there is no $conf['i18n_variables'] in my settings.php some variables (site name, frontpage) are flagged multilingual variable. But if I add $conf['i18n_variables'] and an array of variable names they are not found.
Another thing - when a user creates an account I want the thank you for registering email to arrive in the language selected by user on the language switcher
when they register, but the email always arrives in english, no matter what is selected on the language or whether I change the site default language.
Any ideas, this is driving me mad .... I will be happy to help figure out the problem if I get some pointers but pretty clueless right now. Thanks.
#8
In this 3.x branch I've added language field to everything, so subscriptions now have language, that also gets into queue rows and ends up in messaging. All of the parts are now language aware, and use it when building and composing.
So instead of partial solutions we are going for the whole thing. The other issue with languages is that many modules out there have static caching so just switching global language doesn't work.
The missing piece is this i18ncron module that switches languages for every cron. This combined with an option in notifications (Language split mode) should cause messages for every language to be composed and sent cleanly for every language.
The missing part: some UI for the new templating system to allow translating templates. It has already a language field, has language fallbacks, uses language (and fallbacks to default language) when composing. So the only missing piece is some UI to populate these templates in every language.
#9
Hi, Thanks. I tried the 3.x-dev notifications, messaging and cron setup but getting tons of errors, like:
# user warning: Table '....messaging_template' doesn't exist query: SELECT * FROM messaging_template in ..... /sites/all/modules/messaging/messaging_template/messaging_template.module on line 115.
# user warning: Table '.....messaging_template' doesn't exist query: INSERT INTO messaging_template (name, type, title, description, module, fallback, enabled) VALUES ('messaging-template', 'messaging', 'Messaging template', 'Fallback for all message templates.', 'messaging_template', '', 1) in ...../includes/common.inc on line 3467.
Also several failures when running update.php like:
user warning: Duplicate column name 'language' query: ALTER TABLE notifications ADD `language` VARCHAR(12) NOT NULL DEFAULT '' in ....../includes/database.mysql-common.inc on line 298.
Failed: ALTER TABLE {notifications} ADD `language` VARCHAR(12) NOT NULL DEFAULT ''
Going back to the previous versions for the time being. I'll give it another try soon.
#10
Subscribing - would love to have localizable messaging to be able to build a multi-language issue tracker with Drupal, OG, Case Tracker (and so on).
#11
Update: that 3.x branch was quite a big change causing many side issues with other modules, so it's been dropped in favor of 4.x, which is a more gradual approach (though not small change).
#12
Now templates can be translated. Check out latest 4.x version.
#13
Automatically closed -- issue fixed for 2 weeks with no activity.