Allow notification language to differ from site navigation language

Hi @chrisla,

It looks like you are reconsidering the architecture for email notifications and proposing a significantly different approach. I wanted to share my perspective, as I believe the current notifications subsystem is already serving its purpose very well.

The existing system is primarily based on:

• The configuration object schema defined in recurring_events_registration.schema.yml
• Translatable configurations, so once the config_translation module is enabled, email notification messages can be translated directly at: /admin/structure/events/registrant/settings/translate
• hook_recurring_events_registration_notification_types_alter(), which allows modules to define and register custom notification types

From my experience, this covers the translation needs quite effectively.

Regarding sending multiple notifications, and determining which specific notifications should be sent and when, this can already be handled by defining custom notification types and triggering them at the appropriate moments in code. For example, in one of my projects, the client required an additional email to be sent when a user successfully registered for an event - specifically, an extra confirmation email related to a translator request, sent alongside the standard registration_notification.

To achieve this, I defined a custom notification type like this:

/**
 * Implements hook_recurring_events_registration_notification_types_alter().
 */
function mymodule_recurring_events_registration_notification_types_alter(array &$notification_types) {
  $notification_types['translator_requested_notification'] => [
    'name' => t('Requested Translator Notification'),
    'description' => t('Send an email to the registrant confirming their request of a translator.'),
  ];
}

Then, when a new registrant entity is created, I evaluate the relevant conditions and dispatch the notification via recurring_events_registration_send_notification() if needed:

/**
 * Implements hook_ENTITY_TYPE_insert() for registrant entities.
 */
function mymodule_registrant_insert(RegistrantInterface $registrant) {
  // Send `translator_requested_notification` email if translator field is
  // checked.
  if ($registrant->get('field_translator_requested')->value) {
    recurring_events_registration_send_notification('translator_requested_notification', $registrant);
  }
}

Because of this flexibility, I don't believe an additional architecture is required to handle translations or notification dispatching.

Coming back to the multilingual aspect: by default, when configuration values are retrieved programmatically through Drupal's config.factory service, those values are automatically returned in the current site navigation language. This is the behavior currently implemented in \Drupal\recurring_events_registration\NotificationService::getConfigValue():

$notifications = $this->configFactory->get($this->getConfigName())->get('notifications');

In most cases, this default behavior is sufficient.

However, as described in this issue, there are edge cases where notifications must be sent in a language different from the one used to navigate the site. Determining the correct language in those scenarios may require additional computation or custom business logic. This is precisely the use case that the proposed hook,
hook_recurring_events_registration_notification_language_alter(), is intended to support.

It sounds like a powerful addition to the events system. The ability to create notification entities with their own fields, attached them to a specific event - and to control how and when they are sent - beyond the default notification types already provided by the module, would be a significant enhancement. This would add great flexibility to event management.

That said, I agree that this feature should be proposed and discussed in a separate issue.

If you go ahead and create a case, I'll be happy to follow it to see how the discussion evolves and to help move the proposal forward.