Activity stream tokens didn't work for non English language

Thanks for the bug report. I'm moving this over to the Activity Log module's issue queue in case IceCreamYou has any input :).

I've seen the discussion at http://commons.acquia.com/discussion/activity-stream-change-language ...

When that post was created I asked Gabor to help with this because I've never built a multilingual site before. He was too busy though. So just the barrier of getting someone capable of debugging this set up with a multilingual site is going to slow this issue down.

The problem could be at one of these places in the Activity Log cycle:

1. The templates could be saved incorrectly when there is more than one language
2. The templates could be retrieved and passed to the Rules input evaluators incorrectly
3. Activity Log might ignore the multilingual information it gets back from Rules' input evaluators
4. Activity Log stores which fields need which kinds of input evaluation (because Rules needs that information) and it could be that only English fields get designated as needing input evaluation since only English is defined in the default Rules.

Choice (4) seems the most likely to me -- however, just the act of saving the Rules action with a different template should probably solve this problem if that were the issue (or if not, at least clicking the "Clear all activity messages" button at admin/settings/activity_log). Multilingual templates showing up without the tokens being evaluated would be symptomatic of (2) or (4), while completely blank templates would be symptoms of either (1) or possibly (3).

Hi,

I'm experiencing the same problem but the previous solution is not suitable for me as I have two languages enabled (none of them is english). I've been trying to find a solution navegating through the activity log module code and the function in charge of updating the database is _activity_log_rebuild_templates(), line 329 of file activity_log.module and the values used in that function come from activity_log.rules.inc file. Hook_rules_action_info seems to be passing the right values to eval_input but I can't really track where the error is, it's beyond my capabilities right now. Any advances on this issue?

Thanks,

Igor.

> Multilingual templates showing up without the tokens being evaluated would be symptomatic of (2) or (4), while completely blank templates would be symptoms of either (1) or possibly (3).

Thanks for this overview. So far in this issue we've had reports of both symptoms, so that narrows it down to...1-4 :). Still it's helpful to know where to look.

I was able to reproduce the initial blank activity stream, followed by incorrectly evaluated tokens (tokens displayed literally/unsubstituted and as links) when viewing as a user with default language set to Spanish.

I did a bit of debugging:

1) Enabled Locale module
2) Enabled Spanish language at admin/settings/language
3) Configured the "Log activity for the acting user" action for "Editing rule Log activity when a node is created (not in a group)" rule thats displayed in the web stream
3) Added the string "ezra1" (no quotes) to the end of the English template
4) Copied the "Log activity for the acting user" template over from the English to the Spanish one and changed ezra1 to ezra2
5) Did a dpm($form_state['element']['#settings']['#eval input'], 'eval input'); right before the $record = (object) array( is built in activity_log_rules_admin_form_submit_before().
6) Saved the rule:
https://skitch.com/ezra-g/fw2w1/editing-rule-log-activity-when-a-node-is...
7) Did a "select eval_input, tid, pid from activity_log_templates where template like('%ezra%') and display_type = 'web';"

a:2:{s:27:"token_rules_input_evaluator";a:7:{s:11:"placeholder";a:1:{i:0;s:7:":global";}s:22:"grouping|group_summary";a:1:{i:0;s:7:":global";}s:26:"visibility|stream_owner_id";a:1:{i:0;s:7:":global";}s:20:"visibility|viewer_id";a:1:{i:0;s:7:":global";}s:10:"acting_uid";a:2:{i:0;s:6:"author";i:1;s:7:":global";}s:21:"templates|en|template";a:3:{i:0;s:4:"node";i:1;s:6:"author";i:2;s:7:":global";}s:30:"grouping|templates|en|template";a:1:{i:0;s:7:":global";}}s:36:"activity_log_input_evaluator_process";a:7:{s:11:"placeholder";b:1;s:22:"grouping|group_summary";b:1;s:26:"visibility|stream_owner_id";b:1;s:20:"visibility|viewer_id";b:1;s:10:"acting_uid";b:1;s:21:"templates|en|template";b:1;s:30:"grouping|templates|en|template";b:1;}} |   1 |   0 |

8) All instances of "templates|en|template" had the English language. I would expect some of the templates to be saved as "templates|es|template".

So, this suggests at least 1) from comment #2.

Thanks, Ezra. So it seems like at least one thing that's happening, then, is that Rules doesn't know that it needs to evaluate non-English templates. activity_log.rules.inc lines 714-727 (function activity_log_rules_action_info()) tells Rules what needs to be evaluated. It takes languages into account, but maybe that gets run and stored by Rules before other languages are enabled?

I believe that the eval_input value is stored in the $form or $form_state somewhere... maybe dsm() those variables in activity_log_form_alter() and see if eval_input is already wrong by that point?

I assume that it will be wrong... don't have any ideas off the top of my head for how to fix that.

I have debugged the module with dsm and the devel dpm function and the activity_log_rules_action_info function produces a multilingual eval input but then the activity_log_form_alter function loads the eval input with just english templates. I can't track where the eval inputs are stored nor modified...

I have debugged the module with dsm and the devel dpm function and the activity_log_rules_action_info function produces a multilingual eval input but then the activity_log_form_alter function loads the eval input with just english templates. I can't track where the eval inputs are stored nor modified...

Thanks for confirming, isellakuria.

hook_rules_action_info() is most importantly invoked from rules_retrieve_element_info() in rules.module when rules_admin_form_add_submit() calls rules_init_element_info(). (That's hard to trace because Rules abstracts all of this away.) In other words, the list of fields that might need to be evaluated is stored more or less permanently as soon as the action is selected. (When the form is saved, Rules passes the text from each of those fields through hook_INPUT_EVALUATOR_prepare(); the prepare() functions that return data are stored in eval_input.) So probably what's happening is that Activity Log is installed; Rules imports the default AL Rules including saving the potential eval_input fields; a new language is enabled, but that doesn't affect the already imported default AL Rules.

If this theory is right, I suspect that creating an Activity Log rule from scratch after enabling a new language (rather than modifying the default Rules) would work.

I'm not sure what the right solution is here. It sounds like a flaw in Rules to me. It's probably one that we can work around by manually fixing the data, but doing that will require some finagling.

Thanks for the clarification, I have tried to create a rule from scratch and the templates are stored in the correct languages in the database. I guess modifying the default rules by adding duplicate strings in the activity_log.rules_defaults.inc file for the different languages like the following examples will do the trick for my case:

5 => 'templates|en|template',
6 => 'grouping|templates|en|template',
7 => 'templates|es|template',
8 => 'grouping|templates|es|template',
9 => 'templates|eu|template',
10 => 'grouping|templates|eu|template',

'templates|en|template' =>
array (
0 => 'node',
1 => 'author',
2 => ':global',
),

'templates|es|template' =>
array (
0 => 'node',
1 => 'author',
2 => ':global',
),

I assume that if we uninstall activity_log and rules modules and then reinstall the activity_log in first instance (with the modified default rules) and rules in second instace the rules module will load the correct multilingual configuration of rules, am I right?

On the other hand, I've seen two strange behaviours with these modules:

- While the activity_log_templates table contains all the rules the rules_rules table just contains a subgroup of them (7 in my case). Shouldn't all the rules be in the latter table?
- The activity log for a node creation produces 6 different row entries in the database, is this the normal behaviour?

Thanks for your help, this set of modules (activity log, fbss, rules) is really what Commons missed.

I have tried to create a rule from scratch and the templates are stored in the correct languages in the database.

Awesome, that means my theory is probably right.

I guess modifying the default rules by adding duplicate strings in the activity_log.rules_defaults.inc file for the different languages like the following examples will do the trick for my case... I assume that if we uninstall activity_log and rules modules and then reinstall the activity_log in first instance (with the modified default rules) and rules in second instace the rules module will load the correct multilingual configuration of rules, am I right?

Yes, but modifying module files makes it difficult to upgrade later, since you need to remember the change you made, assess whether the problem you were fixing has been fixed in the upgrade, and if not re-apply the changes. Also that's not a generic solution, since we can't include default values for every language.

While the activity_log_templates table contains all the rules the rules_rules table just contains a subgroup of them (7 in my case). Shouldn't all the rules be in the latter table?

The {rules_rules} table contains only custom(ized) Rules. The others are default Rules, and they are stored in code.

The activity log for a node creation produces 6 different row entries in the database, is this the normal behaviour?

That depends on a number of factors. The current architecture can sometimes save dozens of activity messages for a single node depending on Rules action setup and the node access configuration. That behavior will change in later versions of the module per #1259306: Re-architect activity message visibility.

Thanks for your help, this set of modules (activity log, fbss, rules) is really what Commons missed.

I'm glad you're enjoying them.

--

I committed a possible fix to dev, but haven't tested it. I think that this change should force Rules to recalculate which fields need to be evaluated. I'd appreciate if anyone can test and confirm.

I have committed the changes of your fix and cleared all message caches but the eval input field is not stored with all the language templates in the database...

Removing Commons release 2.0 tag.

Subscribing..

I have committed the changes of your fix and cleared all message caches but the eval input field is not stored with all the language templates in the database...

Looks like some more research will be required, then, to figure out how to rebuild the list of fields that should be evaluated before Rules invokes the INPUT_EVALUATOR_prepare() hook.

Subscribing...

subscribing...

I'm rebulding all rules from scratch but I can't delete the old ones like "Log activity when a node is created (not in a group)", "Log activity when a node is created in a group", ... I even delete the corresponding rows from activity_log_template, activity_log_messages and activity_log_events but the rules still appear in the rules list page and I can modify them. If I delete the from the activity_log.rules_defaults.inc file the Rules page shows a WOSD. Where can I delete the old rules securely?

Seems that deleting the activity_log.rules_defaults.inc is enough...

How to fix this? Adding German language to a fresh install of Commons 2.0 (RC) will result in a blank (only dotted lines) activity stream. This is a serious issue.

I'm also having the same problem for a site in Portuguese (Brazil).
Is there anyone with some solution to this problem?
Thanks.

Subscribe
http://drupal.org/node/1272886

Subscribe

I've tried to create a group and post some content after switching default language from English to Italian.
Activity stream area shows [account:user] è entrato nel gruppo [group:title] whitout replacing tolkens. See screenshot at http://lapapainterrogadomani.net/sites/default/files/stream.jpg
Romina

PS I translated Rules in mysite/admin/rules/trigger filling "Italian activity message template" textarea keeping tokens unchanged.

I opened #1281168: Adding fields to action forms after a Rule is created (for translating fields) to see if anyone more familiar with Rules' internals has any suggestions as to how Activity Log can rebuild the list of fields that should be evaluated before Rules invokes the INPUT_EVALUATOR_prepare() hook. Worst-case scenario it should be possible to manually pull Rules out of the database, decode the blobs, change the values of the MAOD (Mega-Array of Doom) and then save it back. However that sounds like a lot of work and might be pretty hard to do at the right time (the easiest time to do it would be in the action form_alter, but by that time the cached $element has already been retrieved so it might be too late. The confusing thing to me here is whether it's enough to just change the cached version manually -- and also it's not clear to me how to change it correctly).

There is also the possibility of using i18n to translate the fields (see https://drupal.org/node/789286). It seems to me that this ends up being unintuitive, extra work, and additional modules/overhead, because the translation interface gets moved elsewhere. That said, maybe it's better because there is a single consistent interface for translating everything. I don't know; an expert would need to weigh in on that. If we take that approach then we have to do a pretty significant refactoring because there are a lot of places where we assume Activity Log is dealing with an array of language templates.

I'm rebulding all rules from scratch but I can't delete the old ones like "Log activity when a node is created (not in a group)", "Log activity when a node is created in a group", ... I even delete the corresponding rows from activity_log_template, activity_log_messages and activity_log_events but the rules still appear in the rules list page and I can modify them. If I delete the from the activity_log.rules_defaults.inc file the Rules page shows a WOSD. Where can I delete the old rules securely?

You can't delete them, but you can mark them disabled by editing each rule and un-checking the "This rule is active and should be evaluated" checkbox.

Is there anyone with some solution to this problem?

There are various work-arounds:

• Disable all the default Activity Log Rules and create new ones from scratch yourself.
• Reinstall Activity Log after adding your new language (just a guess that this would work -- it might not).
• Edit activity_log.rules_defaults.inc so that the exported default Rules expect multiple languages as described in comment #10. However, this makes it harder to upgrade until this issue is fixed.
• Edit the values in the eval_input column in the {activity_log_templates} table in the database as described in comment #3. However, this will go back to being broken if you ever click the "Clear message caches" button at admin/settings/activity_log.

Hi! Solutions 2,3 and 4 didn't work for me. And I don't know how to create new rules: can I clone the existing ones changing something (that I don't know now) or not? Thank you for your reply and for your great work. Romina

I'm trying to setup Drupal Commons 2.0 in Italian

I've tried solutions 4 and 2 cited in #26 but nothing was working, may be because I didn't follow the correct steps to do it.

I tried the solution #3 as described in http://drupal.org/node/1272886#comment-4963382 with different combination of regenerate Activity log or clearing the cache (Message cache and/or drupal cache) without success.

I tried the solution "Reinstall Activity Log after adding your new language" doing the following steps:

1. disable module Commons Activity Streams
2. disable module Activity Log Digests
3. disable module Activity Log
4. uninstall module Activity Log Digests
5. uninstall module Activity Log
6. install (enable) module Activity Log
7. install (enable) module Activity Log Digest
8. enable module Commons Activity Streams
9. regenerate Activity Log

As said also this solution was not working for me, but, different from solution #3 that continue to show a line of dots for each entry of the log, this solution leave the "Stream page" of Drupal Commons 2.0 empty
I found that after applying this "re-install" solution the table "activity_log_templates" is empty; may be this lead again to solution "Disable all the default Activity Log Rules and create new ones from scratch yourself."

So the question for me now is the same of Romina in #27. (always thing from the Drupal Commons 2.0 point of view)
or
I think it will be useful to have a step by step procedure to apply the different workarounds.

Thanks to everybody who knows the answers
Andrea

Now it works!! I was working without Activity log (disabled, drop all tables, deleted row in system table) with my new language but from time to time I was giving a look for new dev versions and I installed the last one. Soon Activity Stream began to work but in English language. I continued to publish my content in Italian language with activity stream being published in English language. After a while I opened mysite/admin/rules/trigger and I noticed that in the requested field "Italian activity message template: *" there was the English message (in erlier versions the field was blank). I replaced plain text leaving tokens unaltered and it began to work! I hope all you can reproduce my success. Romina
see: http://lapapainterrogadomani.net/sites/default/files/activity.jpg

PS After regenerating also old messages appear in Italian

Ciao Romina, mi chiamo Raffaele, sto incontrando lo stesso problema della lingua, puoi spiegarti meglio cosa hai fatto, in inglese non l'ho capito tanto bene.
Grazie per l'aiuto.

Ehm, my English is awful...
I replied to you in Italian through the contact form but maybe the drupal community wants some more details. I'll try to be clear.
1. After a lot of combinations I decided to reinstall Drupal Commons, a fresh install. Sincerely I don't remeber if I deleted Activity log from profiles/drupal_commons/modules/contrib before Commons installation or after points 2., 3. and 4. (I did it so many times!)
2. I disabled Activity log (and also Commons Activity Streams)
3. I opened my database and I dropped all the tables related to Activity log.
4. I opened also System table, ordered rows by name and deleted Activity log row.
5. I enabled Locale and installed also l10n_client, l10n_server e l10n_update in a directory called sites/all/modules/contrib that I have created.
6. I opened Language (.../admin/settings/language) and added Italian Language. Italian Language is then setted to Default. I made no other changes (path prefix: it)
7. I added some groups and discussions in order to publish some content
8. Now a digression: I enabled Commons Shoutbox but this is not important I think. Later I disabled this module.
9. I visited the page .../admin/reports/status to control if there were new translations to import (this is a functionality of l10n_server I think)
10. Finally I installed Activity log 6.x-2.x-dev enabling first Activity log, then Activity Log Digest and last Commons Activity Streams.
11. Activity Stream works but in English language (maybe I published some content to see Activity Stream working, I don't remember)
12. I visited .../admin/rules/trigger and I opened the rule "Log activity when a user joins a group". The action (DO) called "Log activity for the acting user" showed the field "Italian activity message template: *" with some content (tokens and words) in English language. I changed "joined the" in "fa ora parte del gruppo".
13. I created a new group and the stream appeared first in English and then after a refresh, in Italian.
14. I've translated all the DO inside the triggered rules.
15. The old stream turned in Italian after regenerating Activity log.
That's all! Romina

PS Before this great result I tried many times to translate triggered rules (copy and past from English into blank Italian field and manually transalated) but without any result and the difference now is that Italian field is already filled (with an English message) and I have had only to translate it.

I tried to follow Romina's instructions (thanks for your details) but I had no success at all.

I could not follow the exact steps since I am migrating from an existing commons 1.7 which already had another language enabled as default. I am already using i18n and l10n_client, l10n_server and l10n_update.

That's what I did:

1. I uninstalled activity log, activity log digests and commons activity streams
2. I opened also System table, ordered rows by name and deleted Activity log row
3. I already had Spanish as my default language
4. I enabled activity log, activity log digests and commons activity streams modules
5. I translated rules' messages
6. I recreated activity log
7. I get the all the activities translated but tokens are displayed as text instead of displaying users' images, links...

I am more and more convinced that all depends on overall translation. In detail at point .9 I have also exported, adjusted and reimported the following files .po:
it.po
contrib.it.po
features.it.po
Maybe Italian sites can save their files .po and try theese ones. But there is no mention in these files to rules or tokens...
There is another question: today somone registered into my site and posted some content: no activity was logged in the stream. Maybe this user has not permissions or rules? I have to understand. Romina

edited: I have created a new user and his activity is correctly logged.
There is another thing I have to say: I have enabled Facebook Style statuses activity and, dependent on that, I have also installed Activity module.

Here are the files:

Thank you Romina, you are helping to let things clear.

• I did a fresh install of Commons 2.0 but changing the "Activity Log" module provided with commons profile with the Dev version: still empty Stream after I enabled Italian.
• I translated the the rule "Log activity when a user joins a group" as you said in #31. In my site was empty so I copied from english and then translated.
• I regenerate the Activity Log and one line appears, with the right token correctly processed but with the left one printed as in the rule (as it was for you in comment #25)

I would like to try the .po files provided by you. I will import the it.po as "Interfaccia incorporata"
How/where I have to import the contrib.it_.po and features.it_.po?
------
P.S.
Imported all as "Incorporate interface": nothing changed, still the first token is not processed

I imported them also in "interfaccia incorporata". Romina

IT WORKS .... WORKS. Finally after many trials and an almost sleepless night I could see something. I followed what he said in his post, Romina.
1. Uninstalled (not disabled) activity log, activity log Digest, and activity Commons Stream.
2. Install the Italian language.
3. Reinstalled everything in step 1.
4. Go to the table activity_log_templates, in eval_input change all | en | in | it |.
5. Go (Rules / Rules Triggered) and each rule (DO), fill the field (Italian activity message template) with the same written there in English (after translating).
6. Go to .. / admin / settings / Activity Log, reclaimed, and all should work.

I hope I was clear, and have helped solve this problem.
A THANK YOU to Romina for opening my mind, a virtual kiss.

I want to add something.
Clearly, this technique can not fix the problem.
If you find yourself having to reinstall the site must start all over again, and not good.
The solution is to find the programmer who created the code (Icecreamyou), or some kind soul who puts them in front of the code and tries to solve the problem, because in previous posts Icecreamyou gave hints of where he thinks the problem arises .
So come to the most good with php.

Icecreamyou Thanks for the wonderful work you do for us all.

I should have been more clear about how to make use of the work-arounds.

1. Disable all the default Activity Log Rules and create new ones from scratch yourself. This will always work.
2. Reinstall Activity Log after adding your new language. This will only work if you haven't edited any of the default Activity Log rules. If you have, reinstalling Rules should fix it. (Note: this solution is still a guess and might not work.)
3. Edit activity_log.rules_defaults.inc so that the exported default Rules expect multiple languages as described in comment #10. Then go to admin/settings/activity_log and click the "Clear message caches" button. Note that this makes it harder to upgrade until this issue is fixed.
4. Edit the values in the eval_input column in the {activity_log_templates} table in the database as described in comment #3. However, this will go back to being broken if you ever click the "Clear message caches" button at admin/settings/activity_log. But if you do this correctly it should work.

(disabled, drop all tables, deleted row in system table)

Don't do this. The correct way to uninstall a module is to go to the "Uninstall" tab at admin/build/modules and check the box for the module you want to remove.

EDIT: You should never need to reinstall your site. Worst case scenario you can just reinstall Activity Log and Rules. The easiest way to do this is to install the Devel module, go to /devel/reinstall, and check the boxes for Activity Log and Rules. However note that if you reinstall Rules you will lose any custom rules or customizations you have made to default Rules.

I also want to add that I noted the two possible paths to real solutions here in comment #26.

Thank you IceCreamYou. I am very unexpert :-)
But I'm happy that someone else find the way. Bye bye

I'm trying to apply the solution 1 "Disable all the default Activity Log Rules and create new ones from scratch yourself". I can confirm that it works and it seems a solid solution; you can also clear the message cache and regenerate the Activity Log and you don't loose the new language settings as it happens with solution 4

As IceCreamYou wrote, disable, NOT delete, the default Activity Log Rules. If you delete them they will be automatically recreated.

Just because IceCreamYou wrote "create new ones from scratch yourself" I created some rules by hand, copying them from a test installation of "Commons 2.0" prepared only for this job.
This is an heavy task, also because what you see when you create a rule is different from what you see when you edit it. When you create a rule you can choose values from some drop down lists that are not presented in editing. For that reason, when you try to create a rule equal to the one disabled, sometime you have to guess which is the right value to choose, and I'm not sure I'm doing well everything.

Sorry IceCreamYou, do you think that, instead creating the rule from scratch, we can also clone it from the one disabled?
Or cloning a rule will reproduce the same error we want to correct?
(of course, after cloning we need copy the message included in the rule from english to the language we added, and then translate it)

Tested: from scratch means from scratch!
Cloning a rule and then modify the cloned one doesn't work.

Now the doubt is: how to be sure to recreate the rule equal the one disabled?
e.g. for conditions in rule "Log activity when a user sends a private message"

For the second condition I wasn't able to find the same value of the one in the label so I took the one who most looks like.
But not sure it's right.

I asked Gábor Hojtsy what the best user interaction pattern would be for the translation interface and he recommended using i18n to provide a consistent interface instead of building and maintaining the (currently existing) custom one. That means the solution I will be pursuing is i18n integration as described at https://drupal.org/node/789286. Short-term, the goal will be to change as little code as possible while integrating with i18n. Longer-term, a lot of code will need to be refactored because we currently handle activity message templates as arrays of templates keyed by language instead of a single string in the site's default language that can be dynamically replaced.

Help with this (in terms of patches) is appreciated. It's not an overwhelming amount of work to implement the short-term solution; it requires removing the language-specific template fields, running message templates through i18nstrings() before evaluating them, implementing hook_locale(), and calling i18nstrings_update() when a template is saved.

I am unable to get things work #1286464: Activity stream remains blank despite fresh install and everything suggested.
Can someone kindly, kindly post a working database dump please so things can be started from there and worked out ?

Desperate to see this working!

subscribe

I don't know if this is the case but I had a blank stream when -in my new created rule- I didn't checked "This rule is active and should be evaluated when the associated event occurs." in Rule settings. Romina

Subscribe

I don't know if I did a mistake but the solution 1 (as I described it in #41 and #42) worked only for some event; e.g. for me it worked for "Log activity when a user joins a group" but it didn't work for "Log activity when a user saves a personal status update" or "Log activity when a node is created in a group"

I moved to solution 4 as described in more details here: http://commons.acquia.com/discussion/new-stream-locale-problem#comment-2...

Subscribing..

Hello ..I'd like to hear a comment on the suggested updating strategy for non-english sites currently on hold in Drupal Commons 1.7 due to this bug.

The workarounds that has been proposed here include changing quite deeply the structure of the website, removing rules and manually adding equivalent ones or performing manual SQL queries on the DB.

Even if the workarounds will work, I am concerned of ending up with a dirty installation that may have dificult in the future to perform further upgrades.

So, would you suggest to try to migrate a Drupal Commons 1.7 site to 2.0 now and performing such workarounds or wait for an official clean upgrade path solution (maybe available in Commons 2.3 ??).

Best regards,

Antonello Lobianco, univpm

subs

@sylvaticus - my personal opinion: wait
not only for this issue (that you can bypass) but also for #1244998: User relationships not working as expected (version 2)
I use Commons 2 because I started a new project and I don't want to teach to my users something (1.7) and change it after one month (2.x). But if you are on 1.7 I think is better to wait.

I don't work for Acquia (any more) so don't take my recommendation as official -- but I'd say if you need language support then wait until this issue is resolved. If you do upgrade, rebuilding all the default Rules from scratch (or whichever ones you need) will take a few hours probably, but it's an easy process to revert if you want to do so before upgrading to a future 2.x release. That said, there are security releases for modules in the 1.7 release, so if you stick with 1.7 you should still deviate from "stock" Commons in order to upgrade those modules. (I'm 99% sure upgrading those modules wouldn't affect a future upgrade to Commons 2.x, but as far as I know no one has tested it, and Acquia probably doesn't officially support it.) It's kind of an awkward time in Commons' multilingual life... the answer won't be the same for everyone though, so if you feel comfortable working with Rules, go ahead and upgrade.

I should add that this issue is a priority for me as well as the Commons team, since obviously no one wants to have this functionality broken for a large portion of users.

Committed an initial attempt at the short-term solution I proposed in #43. With this change, translation is now supplied by the i18nstrings module, which is a submodule of i18n. I haven't tested it. I don't know whether it will work by just dropping the dev build in over an existing installation; it might require reinstalling.

IceCream, can you help me to test the new commit please?

I'm using the last dev, I mean the one form Oct 20.

I have being tested on a test installation whit english as the only languague and everything works as espected.

Also on my production site whit spanish drupal profile installation I have done the follow:
1.- Deactivate the old Activity Log module
2.- Desinstall Activity Log module
3.- Upload the new module and activate
4.- Upload the i18strings module and activate
5.- Go to admin/settings/activity_log and click on "Clear all message caches"
6.- Goto admin/settings/activity_log/regenerate and regenerate all messages
7.- Drupal stay some time working and after a couple of minutes display messages whit the number of events and messages that have being generated.
8.- Go to /activities and reamains saying: "There is no activity yet"

I can see on /admin/build/translate/search that there is a new look named "Activity log" but trying to look for any message on Activity messages result on a blank search.

Also go to the database and can confirm that the tables are being populated.

Don't know what other information could I give to you in order to help debug this issue.

@atin81: I missed a necessary change that I've now committed. You can make the change yourself or upload the new files without reinstalling.

I can see on /admin/build/translate/search that there is a new look named "Activity log" but trying to look for any message on Activity messages result on a blank search.

Hmm. Probably the template strings hadn't been saved to i18nstrings yet. I committed a change that I think should force i18nstrings to rebuild its list of Activity Log strings to translate when you click the "Clear all message caches" button at admin/settings/activity_log.

The first commit from #57 is actually wrong, and would make the module only work for single-language sites. Reversed that change. The second commit by itself might be enough to make translation work...

Actually, I think we should be using $GLOBALS['language']->language instead of user_preferred_language($GLOBALS['user'])->language. But 99.9% of the time they will be the same thing, so that shouldn't really matter here...

Hello.. I done the steps as in #56 over a 6.x-2.x-dev (29 october) version.

All fine, I can now see the feeds.

However my site in default in Italian, with English as optional language. When I go to /admin/build/translate/search and I try to translate the strings in Italian I got instead that the system is trying to translate them in .. English!

There is another problem. We are not allowed to translate activity templates usinig admin UI (include import .po files) because they contains a lot of HTML tags like

Well, that's problematic.

I would really like to avoid having markup in the default templates, but I didn't see a good way around that during development; and it should be allowed at least.

There don't seem to be any obvious solutions here...

One possibility might be to go back to what we had before -- i.e. different fields in the Rules action for different language templates -- but not tell Rules to evaluate them. Instead there could be a hidden placeholder field that Rules is told to evaluate. After saving a "Log activity" action the various language templates would be concatenated and saved into the placeholder field so that Rules knows which input filters to run on the templates. Then when Activity Log is rendering an action, it would simply replace the placeholder field's contents with the correct language field's contents before asking Rules to evaluate the template. Sounds complicated, but I think it would work. And it wouldn't require i18n.

@gdud: as a workaround you can follow http://drupal.org/node/372965
As translating the activity log messages is a one-time effort, I don't see much of a problem to comment a couple of lines and then uncomment them back.. but of course.. it's just a dirt workaround, and doesn't solve the wrong-language issue.. the solution of IceCreamYou sounds much more solid..

We are not allowed to translate activity templates usinig admin UI (include import .po files) because they contains a lot of HTML tags.

I'm not sure that's actually problematic for us: We're implementing the i18n strings API, not submitting a form. Based on the current Activity_log code, we're calling i18nstrings_update(), which calls i18nstrings_update_string(), which takes a $format parameter. Couldn't we pass a less restrictive format there as a solution to that part of the problem?

As someone following this issue, I suggest that we avoid the practice of making significant commits before they are tested (eg, see comment #58). There are a lot of people trying to provide feedback and as the codebase changes, it's tough to tell which version people are reviewing. Having a single commit also makes these changes easier to track once the final fix is in.

Sounds like the problem is that the translation form won't submit if there is HTML in the translation?

Can we set $context->format to Full HTML or equivalent, thereby making $safe_check_needed FALSE?

/**
 * Validate string editing form submissions.
 */
function locale_translate_edit_form_validate($form, &$form_state) {
  // Locale string check is needed for default textgroup only.
  $safe_check_needed = $form_state['values']['textgroup'] == 'default';
  foreach ($form_state['values']['translations'] as $key => $value) {
    if ($safe_check_needed && !locale_string_is_safe($value)) {
      form_set_error('translations', t('The submitted string contains disallowed HTML: %string', array('%string' => $value)));
      watchdog('locale', 'Attempted submission of a translation string with disallowed HTML: %string', array('%string' => $value), WATCHDOG_WARNING);
    }
  }
}

function i18nstrings_translate_edit_form_validate($form, &$form_state) {
  $context = $form_state['values']['i18nstrings_context'];
  if (empty($context->format)) {
    // If not input format use regular validation for all strings
    $copy_state = $form_state;
    $copy_state['values']['textgroup'] = 'default';
    locale_translate_edit_form_validate($form, $copy_state);
  }
  elseif (!filter_access($context->format)) {
    form_set_error('translations', t('You are not allowed to translate or edit texts with this input format.'));
  }
}

As a test of the approach in the previous comment, here's a patch that makes activity log templates save-able through the UI, even when they contain HTML. Note, the '2' for full HTML should probably not be hardcoded.

With this patch I'm able to do a crude translation where I replaced the text for "Created the" (as in "Created the discussion") with "hacer" (poor Spanish) and see the Spanish translation appear in the stream.

However, there are a few things to consider:

Activity log can't respect "Language negotiation" setting

The i18n and Locale modules provide a configurable option for choosing which language should be displayed on a page. This option appears at admin/settings/language/configure and is labeled, "Language negotiation": and has the options:

- None.
- Path prefix only.
- Path prefix with language fallback.
- Domain name only.

With either of the path prefix options, page elements such as the "My groups" block title provided by the Organic groups module would be presented in Spanish when the user visits http://example.com/es, and in English when going to http://example.com/en. This follows the Drupal convention of styling, sanitizing and translating content on output.

Based on my understanding of Activity log, activity stream elements cannot react to this URL-based setting because activity stream messages are generated and translated once and then stored, rather than on each page view. As a result, when either "path prefix" setting is enabled on a site, the activity stream messages are not translated along with the rest of the page content.

I think the most practical way to address this is to make these streams use the language default of the viewing user in all cases. They currently seem to be hard coded to English. See activity_log_evaluate_record() for the relevant section of the code that should be revised in a followup patch. With that change, I think we have the best case scenario for translatability of activity streams.

Making Activity log messages respond dynamically to the language with the rest of the page seems like it would require significant re-architecture of Activity log, per #1259306: Re-architect activity message visibility.

- This approach effectively gives people editing the activity templates ability to post full HTML on the site.

In general people configuring rules on a site should be trusted users anyway. We should make this extremely clear in the UI and documentation.

- Activity log doesn't appear as an option to refresh in the UI at admin/build/translate/refresh.

I triggered a refresh by doing drush php-eval "activity_log_locale_refresh();" Hokey, but it works.

- The UI to translate strings is cumbersome

The UI for translating these strings is extremely difficult to navigate. The i18n strings module lists the translatable strings by their original versions.

Activity_log's strings are long and full of HTML, so they get truncated, making them harder to scan. Sites are likely to have many Activity log templates to translate for each of the various actions that are possible, and because Activity log's design requires a separate template for posting a status to the web versus to an email digest.

For example, when we have the default rule sets that come with Commons and I want to edit one of them, the form looks like this:

Many of these translations can be done once and saved for all sites, but this definitely makes that task more difficult than translating smaller strings, which I think is what the i18n UI design anticipates.

How do we conjugate verbs? Do we even need to do this

I believe Locale makes this possible, but I'd like to test to be sure and I'm not familiar with how to test it.

At this momment I can't put on maintenance the site becuase an event we are gettin on next days, but would like to fix the Activity Messages that still showing "Ther is no activity jet" event whit the commit from Oct 29th, is there anything I could look and change by hand on database???

People on productions is pushing for have this feature working ASAP :(

I found the problem, on "activity_log_templates" table all the templates were being generated whit out "display" type, after manually add the "web" type to all of them everything star to work as spected.

Just that don't know if is for my installation bad upgraded but the case is that whenever I click on "Empty Templates" the "web" type gone away!!!

It works but after a while , the activities aren't shown at stream , when I looked on the database I saw that all |en| that I've replaced returned . Any solution ?

there is lot of comment , wish solution we have to follow ?

Note, each Activity log template does appear in the i18nstrings UI for translation once that template is saved through the UI.

Here's a revised patch that addresses "Activity log doesn't appear as an option to refresh in the UI at admin/build/translate/refresh."

I think we need to trigger a re-saving of the already defined rules in order to address the many "The string group_template:44 for textgroup activity_log is not allowed for translation because of its input format." errors we get after refreshing with this patch applied.

Leaving as "needs work."

I'd like to commit the patch from #71 at least until we can figure out a better way to do it, but I don't want to use 2 directly and just assume that it's going to be the ID of the HTML filter because (A) it won't be on sites that don't auto-increment by 1 and (B) every input format can be deleted, so there may be sites with no HTML input format at all.

That makes this complicated, because although i18n doesn't really care if we're using an input filter or not, it does check locale_string_is_safe() if we're not (both in the administration form and when the translated string is requested) and that will be unhappy if we have structural markup.

I committed the first part of the patch (fixing my copy-paste error). But given this challenge and how complicated the i18n interface looks anyway when we add all these similar-looking template strings to it, I'm inclined towards the solution I suggested in #61 .

The solution for 61 adds a lot of complexity and doesn't depend on I18n. In general, since i18n is meant to translate UI strings, it feels appropriate for us to depend on it, so I prefer proceeding with the current solution of using I18n.

One solution to the long listing of translatable Activity Log strings is to provide a link from the rule configuration page where folks enter the site-standard language template that goes directly to the relevant i18n page. That way folks don't need to use the I18n listing to configure Activity log strings, and can still configure other modules' strings by filtering for that module.

@IceCreamYou, what do you think of this solution?

Also, note that the commit from #72 simply gets Activity log showing as a refresh option, but it's not refreshable, per #71.

Here's a revised patch that provides a "Translate this" link in the regular and group template field which links to the i18nstrings UI for translating that template. Since these links are present, it removes the textareas for templates not in the site's default language. This patch also resolves the issue with being unable to refresh all the Activity log strings.

I don't want to use 2 directly and just assume that it's going to be the ID of the HTML filter
[snip]
although i18n doesn't really care if we're using an input filter or not, it does check locale_string_is_safe() if we're not (both in the administration form and when the translated string is requested) and that will be unhappy if we have structural markup.

Good point. It seems like it's by-design that Activity log intends for strings with HTML/structural markup to be translatable, so using a less restrictive format seems like a reasonable solution. I propose we make it a configurable option within Activity log to select with input format should be used as the default when translating with i18n strings.

This revised patch sets a destination on the "Translate this template" links to bring the user back to the template she was editing after entering a translation.

It also allows site administrators to specify the input format that should be used with i18nstrings, and tries to determine the format ID of the "Full HTML" format if it exists.

One remaining item that is probably necessary is to change the exported message templates to not be hardcoded to 'en' and instead look for the site's default language.

This definitely needs testing, but I believe it brings us close to a workable solution. Marking as NR based on the above changes.

Activity Log doesn't use input filters because it doesn't accept user input. Its templates support structural markup, as do the tokens that get used in them, and so it makes no sense to allow input filters that don't support full HTML as they would actually break the module's output. I'd rather take structural HTML out of the templates, but I can't figure out a viable way to do that.

If we do decide to use input formats, then Activity Log should provide its own Full HTML input format and we should make sure it's hidden and can't be modified from the UI. That seems to me to be as much of a hack-y workaround as the solution in #61, but if a patch gets written that does that I'll accept it just so we'll have something that works and we can move on from this issue.

Activity Log doesn't use input filters because it doesn't accept user input. Its templates support structural markup, as do the tokens that get used in them, and so it makes no sense to allow input filters that don't support full HTML as they would actually break the module's output[snip]I'd rather take structural HTML out of the templates, but I can't figure out a viable way to do that.

That's exactly my motivation: To make sure that the site-administrator can chose a single format equivalent to Full HTML so that i18nstrings will allow users to translate these strings. The control is radios, not checkboxes because we need to ensure that the most permissive filter is used in all cases. It is an architecture decision of Activity log to store HTML in the database as user-entered input, albeit administrator-entered input, and thus we need to specify an input format.

If we do decide to use input formats, then Activity Log should provide its own Full HTML input format and we should make sure it's hidden and can't be modified from the UI. That seems to me to be as much of a hack-y workaround as the solution in #61, but if a patch gets written that does that I'll accept it just so we'll have something that works and we can move on from this issue.

Can you explain what you see as the benefit to that approach?

In my view, it adds a great deal of complexity not just to Activity_log but to any other time we deal with input formats on a site, whereas the solution in #75 makes this an optional configuration, present only on sites with i18nstrings.

Activity Log doesn't use input formats for activity messages. The reason we are having this conversation at all is because of a quirk in the way i18n works. Activity Log was built in part to minimize the awkward technological restrictions behind most other activity solutions and try to focus on what's easiest for the user. There is obviously plenty of room for improvement when it comes to usability, but the point is that we should try not to expose anything to the user that isn't strictly relevant to their goal of getting a functional activity stream. There are a ton of technical hurdles that Activity Log has overcome in order to be as functional as it is, and I believe this one can be overcome as well.

I am concerned about the complexity of the code -- a concern I'll address more fully elsewhere. And I agree that attempting to hide a custom input format would be confusing on other parts of the site, so maybe that's not a great way to go. On the other hand, many production sites probably shouldn't have a Full HTML filter.

All that said, this is a complicated issue and I don't know much about translations, and I'd really like to move on to architectural issues. If people will try the patch in #75 and report that it works for them, I will commit it and we can open another issue for making the process easier to use in the future.

So everyone please test the patch in #75 so we can get a working solution in place.

This was bothering me so I implemented the approach I suggested in #61, which restores the original functionality of entering translations while you are creating/editing an activity message template. To be clear: I have tested this and it works for me. I like it better than the ugliness we'd have to do to support i18n, even though i18n is built for the purpose of translating user-submitted strings. If people test this and confirm that it works, I will commit it and mark this issue fixed.

This patch is now the one to test.

I did an initial test on the patch in #80 from a fresh install that had the patch applied.

The steps I followed were:

1) Install Commons from the 6.x-2.x branch, Activity log 6.x-2.x branch + patch in #80
2) Enable Locale module
3) Enable Spanish
4) Provide a Spanish translation for the "Log activity when a node is created (not in a group)" logged to an individual's stream translation.
5) Create a "Bob" test user
6) Set the Language negotiation setting at admin/settings/language/configure to "Path prefix with language fallback."
7) Set Bob's default language to Spanish
8) Logged in as Bob, view Ezra's profile. Ezra is user 1 in Commons.

My rough "ezra hacer la Grupo Our Community" Translation seems to be taking effect. Even better is that based on this approach the stream is able to respond to path prefix changes. Nice work, @IceCreamYou!

Note, I have not tested an upgrade from a previous version of Activity log nor the version of Activity log in Commons but will do so next.

Between Locale and Activity log, there are a lot possible configuration permutations, so this is challenging to test completely.

I suggest we get at least one other functional test and commit this to the dev branch for more exposure.

I agree, if one more person confirms that the patch in #80 works for them, I'll commit it and we can address any follow-on problems in other issues.

My sense is that based on the number of conflicting solutions, commits and patches in this thread, folks might be confused about how to properly test.

Perhaps it is time to commit this and get some testing either in dev or in a new beta.

I agree. Committed fix to dev and marking this issue fixed. Continued problems with translation should be opened in new issues, unless it turns out that this commit completely fails for everyone.

Note that in order to take advantage of this patch, you might need to force Rules to refresh its cache of the default Activity Log Rules. I think that Activity Log should do this for you when you click the "Clear all message caches" button at admin/settings/activity_log. Additionally, if you want to translate activity messages that already exist on your site, you should be able to do that by regenerating activity (after translating the templates, of course).

Again, to be clear: with this commit, translating activity templates happens in the Rules actions. There is no dependency on i18n or similar. If a template doesn't have a translation for the language of the current page, it will fall back to the site's default language and then to English.