Arabic set to RTL, but punctuation LTR. How?

Following advice on other threads, I added the dir="rtl" attribute to the HTML tag in the /common/header.php file, to enable right-to-left Arabic text. This didn’t seem to do anything.

Then I went into the /application/libraries/globals.php and changed
function get_html_lang() { try { $locale = Zend_Registry::get('Zend_Locale'); } catch (Zend_Exception $e) { return 'en-US'; } return str_replace('_', '-', $locale->toString()); }

to return 'ar' That also didn’t work.

I’ve tried styling individual HTML tags using style="text-align: right;" and that only sort of works. Oddly, everything aligns right except for the punctuation, which even seems to autocorrect in the HTML editor to the right side of the word, or the far right margin.

In the /theme/centerow/styles.css file I added the direction:rtl; attribute to HTML, but that still didn’t solve the punctuation issue.

In /application/config/config.ini I set locale.name = "" to “ar”, but that also changed parts of the admin dashboard to Arabic, so had to scrap that.

Any other ideas about how to fix this? Thanks in advance!

Just to clarify, are you talking about the public theme, the admin theme, or both?

I just did some fiddling around with my sandbox site and it looks like I was able to successfully change the admin theme to support RTL/Arabic by editing the language in application/config/config.ini

locale.name="ar"

and adding dir to the html tag in admin/themes/default/common/header.php

<html lang="<?php echo get_html_lang(); ?>" dir="rtl">

I can’t say if this is a total solution for the admin view, since I am not literate in Arabic, but it seemed to work as expected.

I don’t think you need to edit the get_html_lang() function at all, but maybe I’ve missed something.

As far as the public theme, you will also need to do some work there, making the same changes to that header file, e.g. themes/centerrow/common/header.php

<html lang="<?php echo get_html_lang(); ?>" dir="rtl">

From there, I’d guess you will need to make other tweaks to the CSS file(s) (see below). Logical properties might come into play (e.g. using text-align: start end instead of text-align:left right, adding writing-mode: vertical-rl as needed, comparing between padding-right and padding-block-start, etc.)

This site seems to have some good advice for handling common RTL issues relating to CSS in particular:

I wonder if the punctuation/autocorrect issues would be helped by changing your browser language and/or if you need to add dir="rtl" (etc) to each form field, as discussed here:

Hopefully, something here has been at least a little helpful.

I’m not quite sure how to phrase this, but did the changes you made merely align the text to the right or get it to fully run right to left? This is where I’m stuck. I made all the above changes, but all that’s happening is that the text is aligning right. I’ve typed the Arabic in such a way that it reads right-to-left (the order of the characters, I mean), but the fields on the admin side are still treating the text as if it’s a left-to-right language aligned right.

You can tell by how it treats punctuation. It thinks the end of a paragraph/sentence is the last word at the bottom-right end of a string, so it moves the punctuation there. Even in the HTML editor, where I wouldn’t expect it to add any formatting, it’s moving my punctuation to the far right. Even changing the language of Omeka in application/config/config.ini didn’t change the way the fields treat text.

I haven’t had any luck adding the direction:rtl; property to any HTML element. Maybe because the styles.css doc doesn’t touch the forms on the admin dashboard?

And to answer your question, I’ve been tinkering with the CSS in the public theme. I’m not quite sure how to make sense of the styles.css file in the admin themes folder.

Any idea where the files are for the HTML editor? I’m wondering if there are defaults that could be adjusted there.

Anyways, thanks for your help.

RTL can be a little tricky, depending on exactly what you want to change. Setting rtl direction on the whole page, for example, won’t change aspects of the layout that assume left-orientation.

Is your problem exclusively with the HTML editing boxes, or is there more to it? TinyMCE has its own directionality setting that can be set to rtl, and maybe that’s what’s needed here? Default settings for TinyMCE are given in the file admin/themes/default/javascripts/globals.js, the function Omeka.wysiwyg.

If I’m wrong about the particular problem you’re having and where it’s occurring, you could perhaps share a screenshot showing the issue.

I think a bare minimum solution would be to enable RTL text in the HTML editor. It’s a bit tedious typing style="direction:rtl;" into every line of code, but it works. I don’t know why it didn’t work on my first pass, but it’s working now. The CSS editor could solve this issue, and i’ll follow up with you about that on another thread.

But just to follow through with the TinyMCE option, should I just add a line like this to the function (copied bellow)?

direction:rtl;
    Omeka.wysiwyg = function (params) {
        // Default parameters
        initParams = {
            convert_urls: false,
            selector: "textarea",
            menubar: false,
            statusbar: false,
            toolbar_items_size: "small",
            toolbar: "bold italic underline | alignleft aligncenter alignright | bullist numlist | link formatselect code",
            plugins: "lists,link,code,paste,media,autoresize",
            autoresize_max_height: 500,
            entities: "160,nbsp,173,shy,8194,ensp,8195,emsp,8201,thinsp,8204,zwnj,8205,zwj,8206,lrm,8207,rlm",
            verify_html: false,
            add_unload_trigger: false,
        };

        tinymce.init($.extend(initParams, params));
    };

Thanks again!

What you would want to try is adding a line reading directionality: 'rtl' underneath the add_unload_trigger line.

Unfortunately, I didn’t see any change. I added the line, logged out and back into the site, but the punctuation issue is still there.

The “directionality” setting would only affect how the HTML edit boxes themselves look, and only when “Use HTML” is turned on. It won’t affect how things look after they’re saved. Does this match your scenario?

The basic issue here, I think, is that the browser can tell that a run of Arabic characters should be displayed right-to-left, but it doesn’t know what to do with the language-independent punctuation, so it reverts to left-to-right order for that.

Have you tried out @ebellempire’s suggestion of adding dir="rtl" to the html tag? That should be affecting text to flow right to left, not merely align things to the right. There are other containers on the page that could take that attribute that are more tightly scoped to the values themselves, if it’s just them that you want to affect and not everything else. Also, the direction CSS that you’re trying in other threads should work as well, but as you’ve seen, you can’t set it with the CSS Editor plugin currently.

Depending on what you actually end up needing or what works well for you, this is possibly something we can make work more easily, perhaps by providing a setting to go along with the language one that sets RTL direction.

I just tried adding the “directionality” setting again, and, as you can see in the photo, the HTML editor still naturally aligns LTR. Once I add style="direction:rtl; text-align:right;" or use the attribute dir="rtl" as I did in the photo here (I’ve had equal results with both), the problem is for the most part resolved (the text and punctuation display correctly on the webpage), unless a sentence ends with a number, like in the example in the photo. Arabic numbers actually run LTR. The last for characters to the bottom left should be the end of the sentence and the period should fall to the far left, but it just won’t let me. It keeps automatically pushing the period to the far right of the number (it’s the year 2023). I have to wrap the number in <span dir="rtl">####</span> and place the period on the correct side of the tag. It’s a clunky solution, but it works. Though I’m still open to suggestions that will make this less tedious.

I may have misunderstood @ebellempire 's initial advice. I tried this again (the right way this time), and it makes everything display correctly on the webpage, but not in the HTML editor. It makes working in the HTML editor a bit confusing, but the end results are what matters.

Thanks to you both!

This topic was automatically closed 360 days after the last reply. New replies are no longer allowed.