Translation support for configuration

See previous discussion about llms.txt (as standard) vs multi-language support.

#3548950: llms.txt should be only available on the default language for now especially comment 12 #3548950-12: llms.txt should be only available on the default language for now

Let's keep the conversation in this issue.

Do you use Domain module in this setup?

Right, I was just really hoping that this discussion could turn into building a bridge between llms_txt and domain module _without_ changing something on the current logic 🙃

I need to think about more on this, unless you have an idea or proposed code change that keeps the current path based logic but also supports your case.

Hello,

I believe that the reason for this issue should be to enable the generation of multiple "llms.txt" files for each language on multilingual sites. (This could be configurable or only have the original behavior, the current one).

There is no unified decision on how the “/llms.txt” file should be generated, however, they comment on how to build the file if you have different domains (Doc: https://llmstxt.org/domains.html), and it could be extrapolated to a site with different languages.

* For example:

# My site name

## Language Guides
- [English](https://my-site.com/en/llms.txt): Documentation and services in English.
- [Française](https://my-site.com/fr/llms.txt): Documentation et services en français.
- [Español](https://my-site.com/es/llms.txt): Documentación y servicios en español.

Some international websites are presenting their sites in this way (For example: https://www.lg.com/llms.txt or https://docs.nvidia.com/llms.txt)

The conclusion is that, whether for language or other purposes, it may be useful to generate several "llms.txt" files that are linked to the main one.
Use cases: Different languages (/en/llms.txt; /fr/llms.txt), different subsites (/earth/llms.txt; /mars/llms.txt), other uses.

The problem has been caused by the language, but abstracting the need, I think it would be interesting to discuss the relevance of creating several "llms.txt" files, to which you can configure the desired path (/fr/llms.txt; /cosmos/llms.txt; etc.).

* For discussion:

• Current implementation: "llms.txt" file rendered in the default language. Some corrections are required. (https://www.drupal.org/project/llms_txt/issues/3548950#comment-16423540)
• Second iteration: Add some way to generate different files for languages, which can be linked to the main one as recommended in the documentation (https://llmstxt.org/).

I propose taking advantage of this need with languages, which is also useful for other aspects, by creating a new entity, similar to the existing Section entity.

For example:
Entity Context LLMs.
A context could be "French Language".

• "Title" field for the context: French Language
• "Content" field (plain long text) with the content of this dedicated file.
• "Path" field to configure how to access the dedicated context file: /fr/llms.txt

Each of these generates its own llms.txt file, with the possibility of adding the desired path using a Path field (just as paths are managed in nodes).

If necessary, we will address it in this issue, or we will create a dedicated issue, but I would like to discuss it and hear your opinions and possible solutions.

Added `translatable: true` to the content field in the config schema. This enables the llms.txt settings to appear in Configuration Translation UI at `/admin/config/regional/config-translation`.

Added `translatable: true` to the content field in the config schema. This enables the llms.txt settings to appear in Configuration Translation UI at `/admin/config/regional/config-translation`.

Regarding the documentation you referenced about building the file for different domains:

https://llmstxt.org/domains.html

@albeorte I do not think that “domain” on that page refers to the same concept we are discussing here. 🙂

https://docs.nvidia.com/llms.txt

In this example, what we actually see is that subdomains, or more precisely sub-brands or sub-divisions, expose their own llms.txt files. That is a different problem space. What we are discussing here is serving different llms.txt content per site language, where the language is inferred from the site’s web domain.

Serving multiple sub-sites, such as brands, divisions, or microsites, from the same Drupal instance is a classic Domain module use case.

https://www.lg.com/llms.txt

Notably, https://www.lg.com/pl/llms.txt still serves English content. This suggests that the /pl path is not being used for language-specific llms.txt output.

My current work-in-progress hypothesis for this problem space looks like this:

Sub-brands or sub-divisions

Handled via the Domain module, and potentially requiring a dedicated domain_llms_txt bridge module.

Reason: Multiple llms.txt files across domains or subdomains are not multiple versions of the same instruction set. They are separate contracts for separate site identities.

Multilingual sites

• Path, browser language, or user-preference detection: a single llms.txt file which MAY contain multiple languages, with English as the primary language. This mirrors how docs.claude.com/llms.txt previously worked, before becoming English-only like its successor at https://platform.claude.com/llms.txt.
• Domain-based language detection: support translated configuration and translated LLM section config entities.

The key difference with domain-based language negotiation is that we do not change the core rule that https://HOST/llms.txt must resolve. Whether that is https://foo.com/llms.txt or https://hu.foo.com/llms.txt, the rule remains consistent.

The reason behind this is simple, those bots that fetch /llms.txt they stop at https://host/llms.txt and do not perform language negotiation.

Based on the information we got from this thread we created the submodule that makes the bridge with Domain module: https://www.drupal.org/project/domain_llms_txt.
All feedback is welcome.

Wow! It is a great to see that llms_txt ecosystem is expanding. Will take a look when I find time.

I still haven't had a chance to take a look, but I have decided to document that extension in this module's README.md/project page for those who are looking for similar solutions. Also mark this issue as won't fix for now.

#3609204: Add documentation for multilingual and multi-domain support via Domain LLMs.txt

MRs welcomed! :)