Can't have a page in another language in a non multilingual site

[djay]

Describe the bug

If you have multilngual set it makes sense that the whole page should get translated. However there are cases where you want to have some pages in other languages but not have a full multilingual site. Putting other character sets will work but if the language is RTL then it will be wrong.

To Reproduce Steps to reproduce the behavior:

1. Go to control panel and add arabic as possible language
2. Go to a page and edit
3. Go to page catagorisation and set language to arabic
4. add some arabic text
5. save
6. Notice the arabic text goes the wrong direction

Expected behavior

In the case where its a single page in another language and not a full translated multilingual site (ie p.a.multilingual installed). I would expect

• [ ] the header and footer to be set to the default site language. since these are unlikely to be translated
• [ ] the content area to be set to the page language and a dir attribute set to the direction of that language
• [ ] The title set to default language since you would expect this to appear untranslated in listings and navigation etc

An alternative might be to give the ability of sections of blocks to be set to another language. I'm not sure thats the right way to go as I'm not sure how common it is to mix different languages on one page? Or maybe a container block to set a language in a specific context?

Screenshots N/A

Software (please complete the following information):

tested with demo.plone.org on 2025-03-20

Additional context

This is the code for the lang attribute is set but not sure yet why its not changing the language.

But I do think a more full solution is needed for the case where its not a full multilingual site.

I couldn't find any code that sets the text direction so I think this is completely missing for p.a.multilingual sites.

[ranjangupta4590]

Hi @djay

I would like to work on this issue and contribute a fix. Could you please assign it to me? Let me know if there are any specific guidelines or requirements I should follow.

Thanks!

[stevepiercy]

@ranjangupta4590 no. Please read and follow First-time contributors, especially Things not to do, Contributing to Plone, and Contributing to Volto.

[pbauer]

Over 2 billion people read rtl-languages like Adlam, Arabic, Hebrew, N'Ko, Syriac, and Thaana (see https://www.w3.org/International/questions/qa-scripts.de#directions).

As a right-to-left language does not enable dir="rtl" on the body-tag. When I add the tag to the body in volto/src/helpers/Html/Html.jsx basic rtl-functionality is there and view does not look too terrible but there are still many issues, most notably the sidebar is still on the right hiding the toolbar which moved to the right, making is essentially impossible to work.

Additional context Given the plan to have the user-interface translated to virtually all languages as presented by Mack Palomäki at the Beethoven Sprint 2025 fixing rtl-support would open up a huge potential user-base.

Screenshots Here are screenshots of a dummy page with rtl in view, edit, default and volto-light-theme:

[djay]

@pbauer I need to rewrite the issue because its really two different things.

1. That you can't set a language for the content of a page outside of p.a.multilingual and setting the whole site to a given language.
2. RTL language support for both setting the whole site to certain language and in the case where you have set just the content to a certain language.

The case we needed fixing was 1. and we have a fix and there will be a PR soon. The solution is to set the language just on the content area and not anything else and in that case it is less problematic for RTL.

In addition I think fixing RTL for the the editor is yet another case thats seperate from p.a.multilingual case. The UI should only be translated if the user prefered language is changed, not if someone picks a site language using p.a.multilingual.

[davisagli]

I read this too quickly earlier, and thought it was primarily about RTL support. @pbauer Let's re-open #7193 and use that as the main issue for supporting RTL languages.

@djay I don't quite understand your references to plone.app.multilingual. If I understand correctly, you want to remove Volto's current behavior of always changing the UI language to match the language of the current content. I think it does this whether or not you're using plone.app.multilingual.

I also want to fix this and let editors see UI text in their preferred language even if they're editing content in a different language. I think we need to do the following:

1. Set the UI language based on the current user's personal preference (or fall back to negotiating a language from the Accept-Language request header, for anonymous users or users without a preference set)
2. Stop automatically switching the UI language based on the language that's returned from a content request.
3. Set the lang and dir attributes on the html element based on the UI language, and on the content area based on the content language, like you suggested.

Any thoughts, @erral?

[erral]

Having the edit interface in a custom selected interface is a nice to have, but it is a feature @JeffersonBledsoe

Another thing is to support ltr languages correctly adding the proper ltr attribute and the required CSS changes as @pbauer points

Another thing is what @djay expects having the header and footer in the default language, the content in another and marked with the ltr.

I would say that this has little to do with p.a.multilingual (perhaps p.a.multilinguan would benefit from the ltr thing), but with the standard way of working.

As I always do, I would ask: what are we doing in Classic? Can we learn from it?

• We had silvuple for Classic that made the user interface in a differwnt language. I don't know how can it be done in Volto. We can start as an addon before having it in core.

• LTR support should be the easiest: there is a list of ltr languages, add the attribute and fix the CSS (the most difficult task). We need this in core.

• Mix languages: I would say this is not something for core, but an addon.

[djay]

@davisagli

@djay I don't quite understand your references to plone.app.multilingual. If I understand correctly, you want to remove Volto's current behavior of always changing the UI language to match the language of the current content. I think it does this whether or not you're using plone.app.multilingual.

Current behaviour of both classic and volto if you set the language field. nothing. Not sure if classic at least sets the lang attribute anywhere, but volto doesn't and neither will let you type content RTL without having a fully multilingual site.

So there is no switching of the UI based on the content language or at least until multilingual is installed.

Set the lang and dir attributes on the html element based on the UI language, and on the content area based on the content language, like you suggested.

Actually I think it should be

• html lang based on the public picking a language they want to see the site in (multilingual site)
• content lang based on the language field
• UI based on the currently logged in user preference.

I don't think we should conflating the logged user UI with the content. If I am translating a site into german but I'm an english speaker, does it mean I need the editing UI to be in german?

So this is not really about mixing languages. More saying there choice of language by the anon user for a whole site vs the choice by the editor of what the actual content is written in and they won't always be the same.

[davisagli]

So there is no switching of the UI based on the content language or at least until multilingual is installed.

I'm pretty sure this happens in Volto without multilingual installed as long as the language is included in the supportedLanguages volto setting.

[davisagli]

Regardless of all the other related discussion, setting a lang on the content area based on the content language sounds uncontroversial. I can review that PR when it's ready as long as it doesn't try to do a lot of other things at the same time.