Language default

You should be able to do this with Domain Config.

You'll want to clone the "system.site" configuration and set the proper values.

name: 'Drupal 8'
mail: admin@example.com
slogan: ''
page:
  403: ''
  404: ''
  front: /node
admin_compact_mode: false
weight_select_max: 100
langcode: en
default_langcode: en
_core:
  default_config_hash: yXadRE77Va-G6dxhd2kPYapAvbnSvTF6hO4oXiOEynI

So in this case, you would create the following file:

domain.config.ru_mysite_com.system.site.yml

Which contains:

name: 'Russian site name'
langcode: ru
default_langcode: ru

Note that all the items in that new YML file are optional. See the documentation in domain_config/README.md.

Then load that into your configuration as a "Simple Configuration file."

That's a render cache issue. See the instructions in the Domain Config README concerning required_cache_contexts in services.yml.

We've never seen that import error. What did you name the file? How did you try to import it?

IMPORTANT: What would be the answer for question #3

n this case i have 4 domains and i would like only enable x languages in x domains

mysite.com = english
= spanish
= russian

en.mysite.com = english
= spanish

es.mysite.com = spanish
= english

ru.mysite.com = russian

It looks like (though I have not tested), you may need to create a domain-specific language.negotiation.yml file for each domain. And then a domain-specific language.entity.LANGCODE.yml file as well.

Take the following generic case, where I enabled English and Afrikaans on a normal Drupal site.

language.negotiation.yml

session:
  parameter: language
url:
  source: path_prefix
  prefixes:
    en: ''
    af: af
  domains:
    en: ''
    af: ''
selected_langcode: site_default
_core:
  default_config_hash: uEePITI9tV6WqzmsTb7MfPCi5yPWXSxAN1xeLcYFQbM


language.entity.en.yml

uuid: 0a1ffc3e-1330-4e75-9c2d-ebdc0f65c1a4
langcode: en
status: true
dependencies: {  }
_core:
  default_config_hash: lBXDpdDPXQtrfTJQhr6MjRJJEEyYSoRJ0acdvHLsWeA
id: en
label: English
direction: ltr
weight: 0
locked: false

language.entity.af.yml

uuid: 433a3170-b4d2-4187-b57c-d2f5f9be5b53
langcode: en
status: true
dependencies: {  }
id: af
label: Afrikaans
direction: ltr
weight: 1
locked: false

In the sample below, we disable Afrikaans on one domain. I would expect that you need a domain file for the negotiation:

domain.config.example_com.language.negotiation.yml

session:
  parameter: language
url:
  source: path_prefix
  prefixes:
    en: ''
  domains:
    en: ''
selected_langcode: site_default
_core:
  default_config_hash: uEePITI9tV6WqzmsTb7MfPCi5yPWXSxAN1xeLcYFQbM

And one for the language, where status is set to false:

domain.config.example_com.language.entity.af.yml

langcode: en
status: false
dependencies: {  }
id: af
label: Afrikaans
direction: ltr
weight: 1
locked: false

These files are in addition to the domain-sensitive default language override.

That last question does not have enough context to be answerable.

Hi agentrickard,

So if I understand correctly, domain doesnt work as it used to, where you could manage available languages per domain directly from the backoffice.
Now we have to use language negotiation files ?

Thanks

That is correct.

It looks like it is not possible to disable a language on a specific domain because this feature has been drope, see:
https://www.drupal.org/node/1539072

Regarding to disable a language, we can not use the property status set to false to do it.
But the default language doesn't work either.

Hi all,
This weekend I worked on this issue. I found an interesting solution and I'm currently working on a patch which could end by a "domain_language" submodule.
This goal is to set the default language and limit suggested languages by domain.
My current work is about generating config UI to simplify administration.
I hope to able to provide a patch by the end of this week.
See you

Here is a first draft of a new submodule dedicated to handle language restrictions: "Domain Language".
I need to review the code and comment it, but globally it is currently fully efficient.

A new entry is now available in the domain admin listing, to handle "Language" settings.
I've been obliged to alter a few the DomainConfigOverride class to be able to access to the Domain object instance before settings default language.
Is this situation, there is one or two calls to this override while "domain language overrides" are not called because default language is not known.
Let me know if you think it's acceptable or not.

Feel free to test it and report any issue (entity error, route error, needs cache reset ...).

A new release of my patch after a code review/clean.

Hi Roberto,
My patch has been made on top of the DEV branch.
Did you encountered any notice while applying the patch ?
Did you see this issue on a fresh and "standard" install ?
BR
---------------
in addition, can you indicate me which "domain" modules has been activated and any other modules than drupal core's ?

Nice news.
Thanks for your feedback.

So, currently, no drawback related to the last patch ?

Works perfectly for me too =)

Thanks for the patch

I can confirm this patch works with Domain: 8.x-1.0-alpha6.
No clean installation needed, works with existing domain access configuration.

Thanks for the patch.

The latest patch is not included in the last release and no more in the dev branch.
@RobertoGuzman I think you could send a private post to the project owner to ask him to review this patch.

Currently, this issue is only flagged as "Reviewed & tested by the community". The project owner needs to review this patch, merge the patch to the DEV branch and flag this issue "Fixed".
However, if he estimate that the patch is not done correctly, not in the right way ... he has the power to reject it and ask for more work.

That's too the power of community ;-)

@RobertoGuzman That's really a complex question. Here's the state of things.

* I work in this module in my spare time
* Multilanguage suppoprt is not a core feature.
* I do my primary work in GitHub -- as noted on the project page -- largely because the Drupal issue queue is too noisy to be efficient.

This patch introduces:

* Complex behavior changes
* A new module that I am being asked to maintain.
* New hooks.
* A change (?) to how configuration is stored -- I really don't understand why that is there. Domain Config needs to handle that use case.

And it includes no tests.

I'm not going to commit any code that doesn't have tests, and it would take me several hours to write tests for this patch.

This patch also may collide with existing work going on in https://github.com/agentrickard/domain/pull/294.

@Sebastien @Actualys -

This is really cool stuff, but I really can't support it in the main module. I simply don't have the time and the use-case for it.

Clearly, just overriding language configuration is not sufficient. What we need is for someone to maintain a Domain Language module release, separate from the main module suite.

I'm more than happy to support API changes or patches that you need to make that work, but I also need to understand that changes that are being made here:

* Why the changes to DomainConfigOverrider?
* Why do we need DomainLanguageOverrider? -- Can't those changes be put into DomainConfigOverrider?
* What is DomainLanguageServiceProvider actually changing? (I think I get it, but naming the class LangugeDefault is very confusing. I would make it DomainLanguageDefault for clarity.

The rest seems to be form handling, which makes sense, but potentially interferes with what's going on in Domain Config (as noted above).

@agentrickard during the domain negotiation, the "DomainConfigOverrider" use the language manager to detect the current language.
I agree this is necessary to correctly use override mecanism of "domain config", but this force to detect the language, even if we want to restrict available languages against a domain.
In fact, language detection should be done after the domain negotiation, so the domain negatiation should be done very very early.
By switching those lines it fixes the situation, but the overriding mecanism won't be able to correctly load "domain + language" overrides.
That's why I've done the other updates on this class.

If you agree for these updates on "DomainConfigOverrider", I'll be able to create a new module to support "Domain Language" restrictions.
Unless you want to integrate this fix in the core "Domain" module.

I hope I was enough clear. If not, don't hesitate.
Thanks

Yes, let's make DomainConfigOverrider work properly to support both domain + language. Figuring out the order in which those variables are available has been difficult.

Can you spin that up as a separate patch (or pull request)?

Reviewing some old issues, I ran into this module -- https://www.drupal.org/project/domain_lang -- so there may be some coordination to do?

Hi all,
The patch has been migrated into this module:
https://www.drupal.org/project/domain_language

Basically this can be achieved with domain_config module default language lives in system.site so easy to override

`domain_config` allows such overrides. If it was so easy, this issue should be closed a long time ago.
Indeed language negotiation uses it own mechanism to load configs thanks to dependency injection, unless it has been updated (in Drupal Core or in Domain module).
This is mainly due to the fact that domain uses the current language to load the overridden file (name base on both domain id and language), so the language is negotiated before that domain itself can detect on which domain we are ...

Here is our implementation of restriction languages list per domain:
https://github.com/skilld-labs/domain_language/tree/8.x-1.x
Currently it's a test version.

Seems to be part of my patch, done 3 months ago, integrated as a standalone module hosted on github.
I don't understand the situation.
@agentrickard This issue seems to turn around

This is a totally different approach, that focused on different language negotiation settings and ability to define language subsets inside domain entity

Handling multi-language options isn't something I've had time to dig into.

The problem of default language per domain, as I recall, was simple. Restricting languages per domain was hard.

I am interested in the problem of loading domain-specific language overrides when, as Sebastien @Actualys notes, we're using language prefixing to load domain overrides.

Do we need to be loading domain overrides first and then domain-and-language overrides? That might be the correct answer. The current code in the main Domain modules just says "load language-and-domain if it exists else load domain."

That's what the code in http://cgit.drupalcode.org/domain_language/tree/src/DomainLanguageOverri... seems to be doing. If that's the case, we can change the loading behavior in Domain Config to make that domain_language module obsolete, I think.

But both modules introduce a UI as well, which I haven't had time to write.

Am I correct that the GitHub version swaps out the core LanguageManager for a domain-specific one? That's something I was hoping to avoid having to do.

I think there's other way to solve it.

domain_config module should add to container parameter (not config setting to be not affected by config overrides) that will enable language-aware domain overrides

Implementation in domain_config module will provide alter of domain settings form to enable that, the additional submit handler will check for change of the property (checkbox) and will rebuild container with proper parameter if changed.
That may require to store this property in config somehow, but this is how core's language manager rebuilds container on default language change

I've been reading through this thread and I'm wondering what the best solution to override language config right now is? Is it the domain_language module for now?

Domain language module works fine!

Closing.

These types of issues where extra logic is needed to handle non-standard core configurations are out of scope and should be handled in separate modules.

https://www.drupal.org/project/domain_language

Maybe this Domain language module could be linked in the main Domain Access project page along with other D8 related projects like Domain Country Path.

Also there's https://www.drupal.org/project/domain_lang which we actively used a year ago

PS: There's Ecosystem reference in every project, so maintainers need to point this field to domain access

See example at https://www.drupal.org/project/domain_entity

It builds the list https://www.drupal.org/project/domain/ecosystem