1

Intended behaviour / question

  1. Writer creates /node/5001
  2. Translator translates /node/5001 to french using all the niceties of the Content Translation backend system
  3. Visitor goes to /node/5001 and sees a link in the sidebar to the french version
  4. Visitor arrives at /fr/node/5001, reads it, and then clicks away using one of the main menu links or anything in the sidebar
  5. Visitor is now browsing the website in English, since that's the main language of the website, and the language menu links are written in. The viewing of translated content behaves just like viewing any other page on the website; it doesn't change languages for good.

Things are going wrong between steps 4 and 5, since step 4 puts the website in "French mode" which means all menu links point to french versions of content. In theory, all subsequent browsing will be in French (which is not what I want), and in practice the language will switch back and forth between French and English depending on the availability of translations (which is even worse), even though the URL will include the /fr/ prefix no matter what is actually displayed.

Is there a practical solution to this?

Background / supplemental

I've enabled Drupal 8's Content Translation and Language modules. Language detection & selection is done using the default mechanism, which recognizes language code prefixes in the first component of the website's path (for example, /fr/node/1, for the french version of node 1).

I'm now wondering if there's any way, without going toe to toe in a fight to the death with the Drupal final boss, to provide translations ONLY of the content on select pages, but NOT of the entire site, such that the content is made available through links on my website, with the default language being restored to English when navigating away from those same pages?

The intention is to use Drupal's built-in (though other non-core suggestions are welcome) translation management features to create and manage subordinate multilingual content on the backend, but then access these translations on a case by case basis through links in a block for example, without having these navigation actions trigger persistent language selection events (from a user perspective) which rewrite all the menu URLs to match.

Basically, I'm trying to get something to work that would be the Content Translation module equivalent of a bunch of multilingual PDFs attached to a single piece of English content. Except I don't want to link to PDFs, I want to link to ordinary web pages, with the only real difference being that they're written in another language, and linked to an English version behind the scenes.

Am I wasting my time with this, or is there a way to translate just a subset of my content, with access opened up to those translations from the english site, minus the persistence of a full-on language switch for the remainder of the browsing session?

2

Drupal multilingual features are very versatile and can cover most if not all cases. It is still a fairly complex feature and it is necessary to understand some concepts before you know how to configure everything to satisfy a particular need.

The most important concept to understand in your case is the two-part nature of the multilingual system. One part is called the interface and the other is content. Interface and content are translated separately. Once you translate your interface you can add as many nodes/content as you like and you don't have to translate the parts of the interface again, you only have to translate the node content (if you wish to have that content translated at all).

Interface language and Content language don't need to match. You can have the English interface being active while watching a French node.

The Detection and selection configuration under Languages configuration allows for different settings when it comes to selecting which language to choose for either the interface or content.

There may be more than one combination of options that solves your particular problem, and I haven't tested this, but I'll offer the most likely solution.

You don't want the interface language to change, you always want the English menus etc. That means you shouldn't use the URL under Interface language selection at all, just use the default fallback. This means your URLs won't ever have the /fr/ in from of them (path prefix selects the interface language, not the content).

You need to enable the separate Content detection (separate from Interface selection), and set that to Content language. This option adds a special parameter to your nodes links that tells Drupal which node translation to serve.

Here's the likely config:

Drupal language selection

Here is what the links might look like:

/node/97?language_content_entity=en

/node/97?language_content_entity=fr

You can use Views or simply create language-specific Menus or menu items that list those links.

  • +1 for this in detailed answer. Although the result is not always the expected one, because rendered content contains often interface translated strings, the field configuration runs through it, but also any string added by t(). – 4k4 Jul 14 at 9:45
  • Thank you @4k4! Yes, the interface/content separation isn't exactly pure, and it isn't easy to predict what all the configuration combinations might effect. It's best to know what you're after, learn about the concepts and go from there, the right configuration combination can then be found. – prkos Jul 14 at 16:34
  • Unfortunately, I just discovered that this still rewrites menu links, albeit inconsistently depending on which language a page is viewed in first following a cache clear. Translate a few nodes and add links to them in the main menu, then clear the cache, then visit one of the nodes incognito in a non-default language. All menu items that include translated content in that language will be rewritten from that page. – Joe Taylor Jul 15 at 21:52
  • Can you update your question with more details about the symptoms and menu multilingual configuration? What links do you get in the menu, and which ones do you expect instead? – prkos Jul 16 at 12:03
  • Sorry prkos, just got your message now. I've created a little demo of the problem at translation-menu-bug.textninja.net - I hope that brings clarity to the issue. – Joe Taylor Jul 22 at 4:01
2

A simple solution in such cases would be to remove the language switcher and provide for translated content only modal links:

<a class="use-ajax" data-dialog-type="modal" data-dialog-options="{&quot;width&quot;:800}" href="/fr/node/1">French version</a>

You could add the links to the node, in a template or preprocess hook. Or create a block (View or custom block plugin), which lists the available translations of the current node as modal links.

How to build such links see How to open a popup form from a view link?

1

Just to add to prkos's excellent accepted answer, I found that once I configured my website according to his instructions, if I really wanted to let end users use /fr/ language path prefixes, thereby making pages accessible without full-site switching at paths like /fr/node/1, I could do so via the following .htaccess / mod_rewrite rule:

RewriteRule "^fr/(.*)" "https://%{HTTP_HOST}/$1?language_content_entity=fr" [P,QSA]

That assumes that mod_proxy and SSLProxyEngine are both enabled / on.

One issue with the above is that pages will be suddenly be accessible at two different URLs, without a visible redirect, which may or may not interfere with analytics. Also, the canonical URL in the site's meta will differ from the URL shown, even if the Redirect module is enforcing canonical URLs.

Anyhow, I just thought I'd throw that "solution" out to the wind, in case someone reading this in the future REALLY has their heart set on parameterless URLs. As for me, I'll probably just stick to the default of node/1?language_content_entity=fr.

  • Great thinking, and you can do a lot more with Rewrite rules, including redirects. Duplicate content is definitely something to avoid, for more than one reason. The shown URLs don't need to be identical to the canonical URL, I guess that's the whole point of them. Machines will care about the canonical, users will care about the shown. I expect lang href is more important for SEO when it comes to multilingual sites. – prkos Jul 16 at 12:17
  • Although I'd by far prefer the solution where Drupal handles it the way it makes sense for the purpose of the site. If you can't find a config combination to solve your problem you should report it on drupal.org because then it's a missing feature and there will be more users in need of it. – prkos Jul 16 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.