I'd start with a hook form alter on the content type config form. Each content type could have two fields: one for created, one for updated. Store these strings/patterns (if you hook in tokens, which you should) in the variables table (using a pattern like csm_update_blog, csm_save_page). If these are output using t() then the language stuff will be taken care of.

Make sense?

T

Comments

tom_o_t’s picture

Just noticed mcjim's comment on Twitter about using drupal_get_messages() to intercept the default messages that the Drupal module outputs when a node is saved/updated. Very good idea. Will be a bit hacky to intercept and remove the right ones, but totally possible.

jim0203’s picture

The problem here is the output part: how should the original message be killed and replaced with the new message?

Using the technique that String Overrides deployed is what I'm doing at the moment. This allows me to replace a dynamic string like '@type %title has been created' with '%title, a node of type @type, has been created' by just creating the appropriate locale entries in the variables table.

The problem with trying to localise this technique for individual node types is that the node module gives us only two strings for all node types: one for new nodes, and one for updated nodes.

See node.pages.inc ll. 461-468:

if ($insert) {
    watchdog('content', '@type: added %title.', $watchdog_args, WATCHDOG_NOTICE, $node_link);
    drupal_set_message(t('@type %title has been created.', $t_args));
  }
  else {
    watchdog('content', '@type: updated %title.', $watchdog_args, WATCHDOG_NOTICE, $node_link);
    drupal_set_message(t('@type %title has been updated.', $t_args));
  }

So, using the tranlsation method, there is nothing in the original string to tell the translation system what node type it is translating from: at the point that translation takes place, we're still working with @type and %title.

By the time we get to the theme layer, where I could kill the default message and replace it with my own message (probably using hook_theme_registry_alter()), we're dealing with the string as it is going to appear in the page: i.e., the @type and %title have been replaced. So if I kill the message at that point (when we can be node-type specific) it's difficult to put the dynamic stuff back in.

One solution I did come up with is to do both of these things: do a standard locale/string overrides swap that changes '@type %title has been created' so that by the time it's got to the theme layer, it's still possible to pick out type and title before the message is killed. Then the new message can be built and displayed. For example, '@type %title has been created' could be replaced with '@@type %%title has been created', as long as everything is escaped properly. I don't know if this would work but if no-one else knows then I'll give it a crack.

jim0203’s picture

Thinking about this a bit more, I don't think the translation technique that SO uses is the way to go at all.

I can just kill the original message in the theme layer (it'd be easy to find as it'd be of a standard form) and then cobble together a new version of the message from what's in $form. It'll need a bit of work to get the UI to work properly so that people can still use @type and %title, but I think I see how this is going to work now!

mcjim’s picture

Yes! You're on to something there...
hook_nodeapi knows when the node has been updated, so maybe set the brand new message there? Grabbing the custom bit from wherever you've stored it.
And then kill the boring default message at whichever point you find convenient :-)

jim0203’s picture

Assigned: Unassigned » jim0203
Priority: Normal » Critical

I think I've got a solution...

...searching the messages will reveal whether a message has been set, as they have a standard format (especially if they've been translated to something wacky). Then, $_SERVER['HTTP_REFERRER'] gives the actual node id of the node that's been saved or edit (give or take a bit of parsing). From there you can get the node title and type, and build the message. In fact, this would allow anything in the node object to be included in the message.

The only extra strain is the check each time a page is loaded to see if there's a message to be translated, but this can be minimized.

jim0203’s picture

Status: Active » Fixed

Just about to roll the first version. Actually spotting the messages is the hacky part, but it's all done in the theme layer with no use made of the original String Overrides/translation techniques.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.