Fallbacks for config translation

The core config system doesn't do translation in the same way as content entities, they use 'language config overrides'. Language hierarchy does not support this yet, thanks for pointing this out!

Patches welcome :-)

Hi.

I tried the following approaches, but I didn't manage to find a solution:

• Use Drupal events to define the correct language fallback for the configuration, but I didn't find any event for config get
• Use ConfigurableLanguageManager and LanguageConfigFactoryOverride classes to implements functions to translate the displayed configuration values
• Intercept kernel.response and kernel.request events. Using LanguageManager::setConfigOverrideLanguage() results in a translated configuration, but it translate all configration loaded in the request. We didn't find any option to look each one of the configurations to validate if there must be a fallback or not.
• Implements a language.config_factory_override service. We didn't manage to get the implementation results as expected.

I think overriding the LanguageConfigFactoryOverride class is the way we should go.

You can add a new event as a temporarily workaround in src/EventSubscriber/LanguageHierarchyConfigEventSubscriber.php. (Requires the patch from https://www.drupal.org/project/language_hierarchy/issues/2825851)
But it will overrides each language with its fallback.

 namespace Drupal\language_hierarchy\EventSubscriber;
 
 use Drupal\Core\Config\ConfigEvents;
+use Drupal\language\Entity\ConfigurableLanguage;
 use Symfony\Component\EventDispatcher\EventSubscriberInterface;
 use Symfony\Component\EventDispatcher\Event;
+use Symfony\Component\HttpKernel\KernelEvents;
 
 /**
  * Class LanguageHierarchyConfigEventSubscriber.
@@ -23,11 +25,29 @@
     \language_hierarchy_update_priorities();
   }
 
+  /**
+   * Set config fallback language on requests.
+   *
+   * @param Event $event
+   */
+  public function onRequest(Event $event) {
+      $language_manager = \Drupal::languageManager();
+      $current_language = $language_manager->getCurrentLanguage();
+      $config_language = ConfigurableLanguage::load($current_language->getId());
+      $fallback_langcode = $config_language->getThirdPartySetting('language_hierarchy', 'fallback_langcode', '');
+      $original_language = $language_manager->getConfigOverrideLanguage();
+      if($fallback_langcode) {
+          $language = $language_manager->getLanguage($fallback_langcode);
+          $language_manager->setConfigOverrideLanguage($language);
+      }
+  }
+
   /**
    * {@inheritdoc}
    */
   static function getSubscribedEvents() {
     $events[ConfigEvents::IMPORT] = ['onConfigImport'];
+    $events[KernelEvents::REQUEST][] = ['onRequest'];
     return $events;
   }
 }

I like the idea! If we're to use events like that, I suspect it may be worth also subscribing to the DrupalKernelInterface::CONTAINER_INITIALIZE_SUBREQUEST_FINISHED event which core's LanguageRequestSubscriber also acts on. I've not actually come across that one before, but I imagine if core acts on that one, we probably should too!

But as you say, it overrides the whole language's configuration with that of its fallback, which won't suit many (most?) use cases. I suspect overriding the actual config override system itself in some way to fallback will be needed, but as geovanni.conti found, that may not be easily viable. I'm hopeful there will be a way!

Here is the patch for the EventSubscriber as described in #5.

Here's a version which applies to the latest 8.x-1.x branch code, and adds the same event subscriptions as core's language override subscriber as suggested in comment 6.

Next step will be to figure out if we can override per-config, or make it configurable perhaps. This patch's implementation only falls back a single level too, we should figure out if we should/can go further.

Here's a first pass at using real fallbacks for individual config, just to demonstrate an approach. But I haven't done any testing at all with this yet!

Note, it's possible that I shouldn't override getOverride() at all, if I want fallbacks to stay out of a child's config collection entirely, e.g. on writing back to storage?

OK, so on testing that last patch, it's immediately clear that doesn't work because of circular dependencies in the container, etc.

This one resolves all that. More testing is still needed, but I've ensured this one does at least pick up config from fallback languages. I particularly want to look into what happens on config import/export/installation, as I rather want those situations to remain untouched, ideally. I'm not quite sure of what to do on configuration forms, where translations might show. But this patch is at least a bit more useful now!

OK, I think I'm done now. The regular configuration forms now allow writing to a more specific language, when config was coming from a fallback language. The translation overview pages don't highlight languages that are using fallbacks, but they show the 'Add' link for those, which at least demonstrates they don't have their own translation in place. Exporting, importing & installing configuration seems to work as I'd hope.

Wow. Great work!

I've played around with some configurations and translations and can't find any problems until now.

Found only one unused use statement:

+++ b/src/Config/LanguageHierarchyConfigFactoryOverride.php
@@ -0,0 +1,143 @@
+<?php
+
+namespace Drupal\language_hierarchy\Config;
+
+use Drupal\Core\Language\LanguageInterface;
+use Drupal\language\Config\LanguageConfigFactoryOverride;
+use Drupal\language\Config\LanguageConfigOverride;
+
+/**
+ * Provides language overrides for the configuration factory, with fallbacks.
+ */

Drupal\language\Config\LanguageConfigOverride is never used.

Good spot :-) Updated patch here. Only that unused statement has been removed, so I haven't added an interdiff.

I'll leave a little more time for feedback before committing this. I expect to then create a new release candidate version of language hierarchy! :-D