Translation and Internationalisation

[Sephsekla]

We will need notifications to be translatable. How will this be handled?

A couple of potential solutions:

• Use the sender_key to allow a filter-based approach
• Add a textdomain key to the notification schema, much like the approach in block.json.

We could potentially adopt a combination of the two approaches.

The approach in https://github.com/WordPress/wp-feature-notifications/blob/develop/docs/translations.md uses a specific key for each string, which ensures all translations can be easily updated. However there's not a decision on sender_key vs textdomain.

[johnhooks]

@Sephsekla How are the keys to be registered and linked to a translation file? I do not understand how this is supposed to work. Is there documentation explaining this procedure? As I'm reviewing the WordPress internationalization documents, I don't see this method mentioned.

[johnhooks]

$notifications = array( 
    'plugin_slug_new_podcast_title' => __('Some title', 'plugin-slug'), 
    'plugin_slug_message' => __('Some message', 'plugin-slug'), 
);

In this example the translations are registered and translated in code, which has to be registered in some way for us to call and retrieve the translation.

This effectively means:

• Plugins have to maintain these keys forever (or at least come up with some deprecation strategy). Similar to the problem with static block types, but worse, at least blocks render html and content even when/if the block type is no longer registered.

• The bigger the system gets, not only does the db get bigger (as previously stated as a concern), but also more and more code has to be registered to add more message types to the system.

• If a plugin is uninstalled it will break all the messages it left in the system.

[johnhooks]

If a message is stored in the database, translated at the time it is emitted, this would enable:

• A drastic reduction in the number of times a message has to be translated. It would be done once, not every query for the message.
• A message could still be related to more than one user. Though it require:
  • look up which users are subscribed to a channel
  • query and group users by localization
  • translate messages for each available language.
  • store them in the db and link to users through the queue.
• A notification is not broken after a plugin that created it is uninstalled.
• It would still be possible to "refresh" the notifications if extra languages are added by the plugin. (If implemented should be a manual process initiated by the user)
• Notifications can be updated, changed, or removed without affecting previously emitted messages.