Trigger: After flagging the translations of a source node as outdated

The patch adds a new trigger by implementing translation_hook_info(), and adds support for node related actions.

- A new operation for nodeapi is invoked to let every module know the nodes that require a re-translation
- Implemented translation_hook_info() to provide description of the new hook operation added and to inform trigger.module about it.
- Implemented translation_action_info_alter to easily add node related actions support for the new nodeapi operation.

This way, actions may be triggered when a source post has been updated significantly and the translations are flagged as outdated. I think that it is a very useful feature for multilingual websites.

Notes to testers:
- Enable locale.module, translation.module and trigger.module
- Add languages
- Enable multilingual support with translation for at least one content type
- Assign actions to the trigger 'After flagging the translations of a source node as outdated'
- Create a new node and the respective translations
- Edit the source node and check 'Flag translations as outdated' under the Translation settings of the node.
- The actions should be executed after flagging the translations of a source node as outdated.

While this is extremely useful functionality, it does not qualify as a critical issue for D6 after RC2.

Instead of adding new functionality in Drupal 6, I'd suggest we repurpose this issue to the i18n issue queue. You can attach a submit handler to the node form and see when the checkbox was checked, on which you can trigger an action. It does not need to be in the core nodeapi.

It's very small changes, and the new functionaly in translation core is extremely useful functionality (aka Critical). It is preferable that then translation is removed from the core to l18n. ;) It does not make any since have translation without this.

This feature request is almost a bug. Because without this I can't can translate efficiently.

extremely useful functionality (aka Critical)

No. We are in feature freeze for quite a long time now. For a feature to be critical enough that it would block D6 it had to be a showstopper. Still, it is very useful, and maybe Gábor can make an exception and let this in. Maybe not. It's his decision.

Gábor's work-around solution seems reasonable to me. Is there a way this functionality could be reworked, and then the patch be submitted to the d7 queue?

The translation_action_info_alter() is a bit heavy handed. If these are core actions that are being changed, their action_info hook information should be changed.

Yes, I know that we are in feature freeze for quite a long time now, but we can consider this feature as the complement of an already existing feature and not as the aggregation of a completely new feature.

This will give us the possibility to have a new trigger included in Drupal Core and for sure it is going to help Drupal 6 rocks still more in the multilanguage world.

Of course, to include the new trigger is necessary to add a new operation to nodeapi, but really this is not big complication and will not change any Drupal 6 API. There are not new API functions added, nor modifications to function signatures in the existing API functions, etc. If the patch is committed, really is not going to affect to the API in anything.

You can attach a submit handler to the node form and see when the checkbox was checked, on which you can trigger an action. It does not need to be in the core nodeapi.

In my opinion, this is not only the trigger, is more than this. To have a really consistent nodeapi, hook_nodeapi must be invoked whenever an important operation was made on a node. In a multilingual site, this operation is extremely important. All the modules that implement nodeapi should be notified that a re-translation to the nodes marked as 'outdated' is required. For this reason I propose the new operation 're-translate'.

The translation_action_info_alter() is a bit heavy handed. If these are core actions that are being changed, their action_info hook information should be changed.

Yes, you are right, but the way it's implemented now requires fewer modifications to the existing code. If Gábor can make an exception and let this feature in, would be good to proceed the way you said.

Other point to consider is that the patch only requires very small changes to the existing code.

What do you guys think about ?

I think that this still needs more discussion, and however you like to put it, it is a feature. In Drupal 7, hopefully comes built-in multilanguage support for much more stuff in the system (settings, menus, taxonomy, whatever, we will see when the time comes). Then we will need the same kinds of mechanisms for all object types. Let's revisit this feature a bit later, instead of rushing this in.

No, let me repeat *no* multilanguage site will live without one of the contributed multilanguage modules (i18n or localizer at this time), since site settings, menus, taxonomies, content type details, polls, user profile field names/descriptions, etc are all untranslatable in Drupal 6 as-is. So sites will have one of these modules installed. That said, getting this action in any of the modules and exposing from there would have close to a similar effect, instead of rushing in something quickly cooked up now. As much as you say that a mutlilanguage system should have core actions/events about multilanguage content, a multilanguage system should have multilanguage menus, category system, settings, etc, and all these are missing from Drupal 6. We are trying to go with less earth shattering steps, so we see where are our errors, and fix them onwards.

As I said, this can be recategorized for i18n module. If you feel strongly about this getting into core and no contrib, then recategorize to the 7.x queue.

I think this should be 7.x, since it is in the Drupal issue queue atm.

i hope this gets in as being able to notify translators is really necessary!

No longer applies on 7.x.

Robin

Still looks like a good improvement however :)

I'm afraid this will have to wait for D8 :(

However this could be addressed in contrib by http://drupal.org/project/translation which aims to provide an enhanced version of the core translation module (and actually replace it in D8).

This may have already been addressed. If not, it needs some IS updating.

Moving to outdated as there has not been a follow up since moving to PNMI 7 years ago.

If you still feel this is an issue please reopen with an updated issue summary.