Domain and language detection

Please don't begin a support request by insulting the maintainer's intentions.

Language detection is a core feature of Drupal, and can be configured per-domain here -- admin/config/regional/language/detection/url -- but that method is incompatible with how Domain works.

You need to overwrite the `default_langcode` per domain, which should be available using Domain Config module. See the README.md file in that module.

You would need to enable the module and then provide a configuration file for each domain, something like so:

domain.config.[YOUR_FR_DOMAIN_ID].system.site.yml

langcode: fr
default_langcode: fr

domain.config.[YOUR_DE_DOMAIN_ID].system.site.yml

langcode: de
default_langcode: de

It is not necessary to reproduce the entire system.site file, as noted in the README.

You could also do this dynamically in settings.php if you don't want to enable Domain Config.

In this scenario, you would set the core Language detection settings to 'URL' and 'domain' and leave the form values empty on /admin/config/regional/language/detection/url

It is possible, however, that setting the default language in this way will have unintended side-effects. I simply don't have time to test all possible iterations, and need to rely on people who need these features to help provide solutions.

In my limited tests, that won't work either -- at least not for interface translation. I have not tested it with content translation.

We may need a new language negotiator that accepts an array (list) of domains.

Looks like someone already wrote this -- https://www.drupal.org/project/domain_language_negotiation

So this turns out to be a fascinating problem. The baseline plugin is pretty solid. Here's a patch for that.

The problem, however, is the Language Switcher links, which are expecting each language to have a distinct URL. So if we have a case where two domains use the same language, it's not clear which site to send people to.

Since we cannot key by unique langcode, for now I added this comment, which should go in the README:

  /**
   * {@inheritdoc}
   */
  public function getLanguageSwitchLinks(Request $request, $type, Url $url) {
    $links = [];
    // The links array expects a 1:1 relationship between language and domain.
    // That is not the case for us, so we recommend using the provided
    // Domain Navigation block instead.
    return $links;
  }

The attached patch needs testing by people with this use-case.

Credit to @flyke for the original implementation.

Remove the blank settings yml.

Try again without the typo.

To test this patch:

- Download and apply the patch from the domain project root.
- Clear cache
- Enable languages as normal
- Go to admin/config/regional/language/detection
- Select Domain record as the detection method
- Go to admin/config/regional/language/detections/domain to configure default languages
- Test the behavior

Note that the "language switcher" block does not allow multiple links to use the same language, so you cannot use it. The "Domain navigation" block can be used instead.

I'm maintaining domain_path module and going through the chaos of domain and language for D8 to D9 update.
First thing first, disable the core content_translate module which will bring your trouble into another dimension when dealing with interface language and content language X multi languages.

For @seyfcom requirements, it's fairly easy and bug free now if the domain name and language relation was 1 <-> 1 (and only).
www.example-fr.com for french
www.example-de.com for german
www.example-it.com for italian

You just need to enable domain and language modules and don't need domain_lang.
After clean install and set up three domain names and three languages, go to admin/config/regional/language/detection and enable "Language from the URL (Path prefix or domain)". Then go to /admin/config/regional/language/detection/url and select Domain and put three domain names match three languages.
I didn't find bug so far to use domain_config after this setup.

For more compilated use case - each domain needs to support multi-languages and has different default language (you may also want the default language won't have a URL prefix) - you can't set up everything from the web UI.
Config editor from devel module may make your life easier.

Here are the steps:

1. clean install and enable domain, domain_config and language modules

2. set up domain names like domain1.com and domain2.com and languages like langA and LangB

3. go to /admin/config/regional/language/detection/selected and enable domain configuration. Create configurations like:

DOMAIN CONFIGURATION

• Domain: domain1.com
• Language: default

Language: LangA

DOMAIN CONFIGURATION

• Domain: domain2.com
• Language: default

Language: LangB

4. go to /devel/config and delete language.negotiation if you have it, so you can have different settings for different domain.

5. go to /devel/config and you should be able to see domain.config.domain1.language.negotiation and domain.domain2.ca.language.negotiation.

Change values (don't copy and paste to cover the whole config) like:

domain.config.domain1.language.negotiation ->

session:
parameter: language
url:
source: path_prefix
prefixes:
LangA: null
LangB: lang-b

selected_langcode: LangA

domain.domain2.ca.language.negotiation ->

session:
parameter: language
url:
source: path_prefix
prefixes:
LangA: lang-a
LangB: null

selected_langcode: LangB

After you set up it once, you can export all the config files for future use.

With this setup, I find that domain_config may be buggy to use certain domain specific config like the "Basic site settings". It seems because the absence of the global language.negotiation.

I also tested the patch. Please correct me if I'm wrong. I think we don't really need it for the first setup and for the second setup it won't help.
What we need is to alter the language module to allow each domain have different "default language" and flexible URL prefix.

Making domain_config working consistently in complicated domains and languages detections should be a separated issue.

I found out where the issue lies. I am maintainer of the domain_language_negotiation module and had this issue as well. The problem lies in the caching of the configFactory. Because in a very early stage some inbound, outbound uses the language negotiation config from the main yml, because it is not possible yet to determine a domain and therefor a domain config override. The config factory will static cache it and in a later stage the domain config overrides will not be loaded again because of the static cache when the domain is available.

So the solution I have ready will handle 2 static caches to alter and update the overridden data in config the moment the domain is available.

@jefuri

Do you think we can abandon this patch in favor of the other module? Or vice versa?

No, I think it should land in the domain module. The thing is that you cannot really override language settings on a domain level because the way Drupal needs the language on a very early stage. The Entity Type Manager it self needs it, and the Domain record is an entity, because of translation situations (maybe) in usage of the Entity Type Manager.

So ones the domain modules knows the language, whatever you do later on through domain config (in combination with language negotiation) does not matter anymore. The language is set.

So if you want to use the domain config module in some way to determine language negotiation, it should handle that information from the domain config overrides before the domain logic.

I'm actually running into this problem now. The project in question uses Domain, and has a different language negotation per domain via domain_config (at least one uses a prefix for the non-default language, while another uses a different domain per language). Because the domain config and the language negotiation rules depend on each other, the site ends up using the default language negotation rather than the one for the domain, and ends up using the wrong language. The result is that some of the content is in the correct language, but mixed with config that wasn't translated.

domain1.com (english)
domain1.com/es (spanish)
domain2.com (english)
es.domain2.com (spanish)

Based on this thread, it seems like this approach may not be fully supported. Would the fix may be a custom language negotiator that doesn't use config, and thus doesn't cause the circular dependency? Although that may need to be implementation-specific at that point.

Right. See also #3280884: Frontpage nodes changes randomly to other domain configured frontpage node which I'd like to get reproduced in a test case.

We do have tests for translated config, and they pass -- see domain_config/tests/src/Functional/DomainConfigOverriderTest.php and domain_config/tests/src/Functional/DomainConfigHomepageTest.php

It's *changing* language that seems to be the special case problem.

I agree that this should go in the main module. The real question becomes how to avoid the loop that @jefuri points out in #18.

It may be that we have to tell people: the only way to override language per domain is via settings.php, since that wouldn't require entity / database lookups.

I think that's an acceptable answer, so long as we can support it.

The first step is writing a test that can reproduce the issue.

Reviewing for #3366588: Documentation for 2.0.x

Changing component to code, should Version be updated to 2.0.x?

Can someone confirm that it is still an issue on latest 2.0.x-dev branch and/or 3.x, please?

Problem might have been fixed with recent updates.

Unless new, valuable information is provided, this issue will be closed in 3 months.

This could be definitely fixed by this issue's MR: #3547029: Initialize Domain before language negotiation

The original expected behavior is working perfectly fine when tested locally.

Closing for now.

A new path prefix feature similar to what the country_path module is doing has been released in Domain 3.0.0-beta8.

Could solve the problem of those in need of mixing hostnames and path prefixes to handle multiple languages.