Adding direction to the client- participation

[xeeg]

Adding option to indicate the direction 'rtl' or 'ltr to client-participation through specifying s.dir in the language-specific strings file. It defaults to 'ltr'.

related issue: #513

[colinmegill]

Yay! Thanks @xeeg this is a long standing issue and I know will help users around the world. I'll try to review this weekend.

[colinmegill]

Bookmarking that I'm using the following guides:

• https://firefox-source-docs.mozilla.org/code-quality/coding-style/rtl_guidelines.html
• https://hacks.mozilla.org/2015/09/building-rtl-aware-web-apps-and-websites-part-1/

[xeeg]

Thanks for the references Colin! both links have great checklists to go through!

Putting the rtl on the root html was causing some of those issues (mirroring and missaligning the logo and footer) so I put it on the inner div for the comments section. I'll go through the css and check for other issues.

In the meantime, is putting the indicator for rtl in the strings file as opposed to config an acceptable approach?

[colinmegill]

is putting the indicator for rtl in the strings file as opposed to config an acceptable approach?

The strings file is going to be loaded dynamically depending on the browser language. This means that if the browser language is Farsi, it will load the Farsi strings file and add 'rtl'. Is it likely that if the browser language is Farsi (or Hebrew) that the person is showing up to a conversation with a topic and description which is also written in that language? Perhaps it's pretty likely, and relying on that is a good heuristic.

I think the other options are allowing the moderator to set the language in config, as you suggest, which requires database work for this PR, or to dynamically test the language of each line and render it accordingly, which adds third party translation (which we already have integrated!) but large number of network calls related to rendering.

Edge case: Hebrew browser lang visits French conversation

I think this is our best option for this PR, even if we consider it a first step. If someone with a browser language set to Hebrew joins a conversation with a topic and description in French, the French topic and description will appear RTL and that's not ideal, while the instructions and help text will appear in Hebrew, correctly, in RTL.

Edge case: Hebrew translation of French comment

There are important edge cases for bilingual scenarios that should become an issue before merging this PR:

• create an issue for addressing rtl issues in automatic translations in the voting interface

[colinmegill]

A potentially useful new browser api: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/i18n/detectLanguage

i18n.detectLanguage()
Detects the language of the provided text using the [Compact Language Detector](https://github.com/CLD2Owners/cld2) (CLD).

This is an asynchronous function that returns a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise).

[xeeg]

Thanks for raising the issue of user inputs and the idea of detecting the language dynamically.

I think the website/admin language needs to support direction independently from the user text inputs (admins and participants). The original commit sets the language for the app and will cover the first case. For the second case most modern apps seem to set the direction at input time. It will be helpful for users to see the text as it will be displayed after it's submitted.

Turns out, by setting the direction to "auto", the browser can detect the correct direction, even for bidirectional text including a mix of rtl and ltr languages.
See: https://www.w3.org/International/questions/qa-bidi-unicode-controls

I still haven't been able to get it to figure out how to do it for the textarea. In worst case scenario we could use this function to detect whether the text is in RTL or LTR from the unicode data for text input: https://stackoverflow.com/questions/12006095/javascript-how-to-check-if-character-is-rtl/14824756#14824756

[xeeg]

(This is not complete yet, there's still a mysterious styling issue with margins on the vote section showing rtl text when browser is in english I need to fix)

[xeeg]

Screenshots of the client participation views in RTL mode:

Website RTL, content LTR

Description & Subscribing to notifications:

Voting:

Website RTL, content RTL
Description & Subscribing to notifications:

Submitting new statements & Voting:

Website LTR, content RTL

Website LTR, content LTR

[metasoarous]

Hi @xeeg. Thanks again for this PR!

I wasn't able to push to your fork so I created a site-direction branch on our fork that:

• resolves conflicts with the edge branch
• switches from dir to direction in the strings config files for clarity
• adds this attribute to the Farsi and Hebrew strings files (I don't know of any other RTL langs we support currently)

I gave it a spin to make sure my dir -> direction switch works, and realized that while everything seems fine on Chrome (R), the conversation prompt does not display properly on Firefox (L):

I think this still seems like an improvement over what is in production currently, so I'm happy to go ahead and merge this, unless you'd rather look into Firefox support first.

Thanks again!

[xeeg]

Thank you so much for the updates Chris.

What you see in firefox is totally acceptable and is an improvement. But using this same branch I can't reproduce the issue and It looks fine to me. However I noticed a bug in chrome, where the float style of the "comments remaining" is not working. Apparently chrome doesn't support this particular inline-end and inline-start. Using the property for margins seems to be supported. https://caniuse.com/mdn-css_properties_float_flow_relative_values

I fixed it locally but now I don't have permissions to push to the edge/site-direction :-)

[xeeg]

Here's the fix:

whilo@4eb5d1b

[xeeg]

I merged this branch with your changes and tested and it seems fine!