@twbs/team Content strategy concerns here, before going further: how/where should we show and test RTL?

As a simple basis, I just duplicated our firt example, "Album" using a new examples-rtl.html layout and a condition to use bootstrap.rtl.min.css if the layout is used.

So, two questions:

1. should I keep going with those duplicated examples?
2. what about testing our components? How do we ensure future changes does not harm RTL version?
   1. do we provide some kind of sandbox or kitchen sink with every components in RTL?
   2. do we try to display RTL version alongside our current docs (with, say, something like an iframe with srcdoc—which could be handled via a shortcode)
   3. maybe need an entire new section for our docs?

"Duplicated" examples looks fine IMHO, since they also allow to translate content (which would be very valuable). But when it comes to component, I have no strong opinion ATM.

FYI, Boosted used a very ugly script to automatically duplicate examples and a sort of Kitchen Sink named "Boostwatch"—also available in RTL. None of those seems fine to me.

Regarding content strategy, I think we need at 2-3 pieces:

• Docs page (perhaps under Getting Started or Customize) to document how we build our RTL dist files. This should include how to build with these files (which is likely a small modification from the Customize docs).

• I don't think we need to do all our examples, but up to three sounds reasonable if we think it makes sense. One at the minimum.

• For testing components, I think this is where we need to create a kitchen sink of sorts—all our components and their most common (or least common lol) variations in one page. This then could be duplicated and shown with RTL enabled.

  This kitchen sink page has for sure been requested and is something I know the community would appreciate. Putting the right love into it could be something folks could rally around for customizing Bootstrap for their own needs, and extending it as needed.

  I think this page could live as an example, or as a top level page like Migration (docs/5.0/cheatsheet/).

I tried to automate the Cheasheet page by parsing our components' markdown files, finding examples via a regex (ala scss-docs shortcode) and displaying them. It somehow works, but seems like a dead end to me since our examples are done in multiple ways (including datas, loops, etc.), and some of them require either a few JavaScript or custom styles to work well, which I doubt being able to get easily.

So I'll go for a dedicated example, hand-managed for now: if anyone has any idea to improve this, feel free to mention or PR against this branch :)

Edit: For now, I manually wrap up component examples, trying to be both exhaustive and concise. I'm still missing Content, Forms and Cards.

This is so encouraging to see! <3

Note to myself:

• there's probably a way to use frontmatter for RTL layouts, instead of duplicate layout

Hello, I've extensive experience working with RTL and I've been using logical properties and values in production for almost four years with fallbacks. I wrote a couple of guides for RTL one of them is published on CSS Tricks and I would love to help. Any suggestions where can I start looking?

Hi @ahmadalfy, very glad to have some help!

At the moment, you may help by checking the five example templates I converted to RTL:

• Album
• Checkout
• Dashboard
• Blog
• Carousel

For now, I only ran out CSS through RTLCSS, and translated roughly their content to arabic (with tools).

So I guess there can be things to improve on a CSS side (already noticed the carousel arrows) and the arabic content can probably be improved.

There's not much more for now, I'm working on a full test page using every components: I think your experience will be extremely valuable when it's here, to find common issues and help fixing them.

Also, we'll need to document working with RTL, so feel free to share any ressource you wrote or any suggestion that may help people using Bootstrap to work with RTL: there're tons of things missing on this PR current roadmap, I guess.

Speaking about fallback for logical properties, does this mean physical properties? Or do you have another stratégie?

Hi @ffoodd

Will definitely check and share feedback if I have any. I can help with the documentation part for sure. Regarding the resources I wrote this article recently (Building Multi-Directional Layouts) about logical properties and values and how PostCSS plugins can help you use them now. I wrote another piece 6 years ago that still stands firm as well (Let's talk about RTL).

There is another excellent guide written by Ahmad Shadeed RTLStyling.com. It covers a lot more topics and can be considered a complete resource for anyone who wants to work with RTL languages.

Regarding your question about logical properties and values; yes, the fallback is done using physical properties. It's automatically translated using this PostCSS plugin.

Please feel free to ping me anytime you need anything.

Hello there... I'm Tawfeeq Amro working with biggest Arabic website in World (www.mawdoo3.com), and I hope I can help you in Arabic proofreading, Arabic translation, technicality and more.

Hi,
I am a graphic designer (working for TV ) and web developer in my part-time, I could help you with Arabic translations and terminology since I was working on some projects online to improve the presence of the Arabic language on the web

@ffoodd one of the problem that I found in your example in this url
https://deploy-preview-30980--twbs-bootstrap.netlify.app/docs/5.0/examples/carousel-rtl/

the arrows should point to outside not inside .. like this < ---- >

@ffoodd one of the problem that I found in your example in this url
https://deploy-preview-30980--twbs-bootstrap.netlify.app/docs/5.0/examples/carousel-rtl/

the arrows should point to outside not inside .. like this < ---- >

This problem can be fixed by reflecting arrows transform: scale(-1);

or changing arrows positions (Better browser support):

.rtl .carousel-control-prev { left:0; }

.rtl .carousel-control-next { right:0; }

or changing arrows positions (Better browser support):
thanks @Tawfeekamr

yep the second solution is better I think

or changing arrows positions (Better browser support):
thanks @Tawfeekamr

yep the second solution is better I think

That's actually a worse solution. This way you are moving the back button to the far left; which in Arabic should be on the right. What should be done is either using transform like @Tawfeekamr offered or to switch the pseudo content value of bootstrap font in Arabic.

Great! Will take care of it, thanks 🙂
@Johann-S did you check modal's behaviour? There're plenty padding related things and I'm not sure what's needed for RTL. I fixed a single case but there might be more, I'm not confident at all with this component ATM.

@ffoodd yep I checked as much as possible use case and it works fine to me 👌

@Johann-S Need help :') I added the left placement test for tooltips, but it keeps failing with Karma.

When logging tooltipShown.classList in the test, it's using .bs-tooltip-end on the shown event (but is correct on the the inserted event) and I don't understand what's happening. This is litteraly working so I'm not sure of what's going on with this test 🤔

@ffoodd I think you went to far, you tried to test updateAttachment on show unit tests.

updateAttachment is a separate method you can test it separately.

The class changed because if Popper.js detect not enough spaces it change the tooltip position

Ok I think I'm done here, still need to review all the things but it's definetely better. I'll try to check deeply tomorrow!

@Johann-S I updated my test to target updateAttachment() and stop on what's inserted, since it's what's relevant here.

@XhmikosR I did my best to clean up patches, let me know if something is still wrong.

@ahmadalfy @devmium @Tawfeekamr @kamel3d @badrshs This is ready and only requires review, should land in v5-beta1. If you have any time to review and contribute after the merge, I'd be glad to have some feedback on this long-lasting work :)

beta1

Dear @ffoodd ... I can follow this link to make a review?

https://deploy-preview-30980--twbs-bootstrap.netlify.app/docs/5.0/examples/carousel-rtl/

Also, There are translation issues, I can report them here?

Hi @Tawfeekamr,

The best place to check is RTL cheatsheet.

You may report any issue here or open a dedicated issue if it's easier for you 🙂

Thanks for your help!

Hi @Tawfeekamr,

The best place to check is RTL cheatsheet.

You may report any issue here or open a dedicated issue if it's easier for you 🙂

Thanks for your help!

Okay, no problem...

1.Never say "معاق" for "Disabled" inputs, the best translation from my opinion is "معطل".

google take the translation in the wrong way:
Disabled: (of a person) having a physical or mental condition that limits movements, senses, or activities.

2. Carousel slider must move from right to left in RTL (I mean the auto move from slide to another).

3. Carousel means "دائري" in google translate, this translation does not make any sense! the correct one to get the meaning of Carousel/slider is "شرائح عرض" or "شرائح عرض متحركة".
   Again "دائري" means in Arabic "Circular" if you mean that meaning, keep it! but if you mean slider I think "شرائح عرض" closer to the Arabic developer.

We can save some of these outstanding todos for Beta 2. I just pushed some changes to clean up the examples for now. I'd like to add a few things to the list if it makes sense:

• Move cheatsheet from examples to main docs
• Allow main docs to be passed a direction in the front matter and have that automatically toggle LTR to RTL CSS inclusion
• The above items should resolve most of this, but... De-dupe the RTL CSS once moved
• Convert page content to Markdown

@mdo Setting the dir in our docs is very easy (did it for examples) however that means we'll need to convert our docs CSS to RTL too. And since we (probably) won't translate our navigations et all, it means our RTL cheatsheet would be in arabic in an english page?

So either we don't use dir on the whole page and simply set dir and lang on main content (and ToC), or we drop the arabic translation and only use dir on the main content… which would be quite deceptive.

I started with the cheatsheet in our docs and struggled with more questions (comment), and following @devmium reply (comment) I decided to go for an example.

As mentionned in my linked comment, I almost managed to create a shortcode that parsed our markdown content to get and instantiate every occurrencies of our example shortcode, so it can be automated pretty easily ‑ but without any kind of translation. However that's another concern, I guess.

Or we add the cheatsheet in the main docs, but leave the RTL counterpart in examples. Would still require manual maintenance though.

@ffoodd
In this url, please take a look at this:

I guess we should flip this chevrons like this:

Which can be done with transform: rotate(180deg):

Also the transform-origin can be increased to .6em to have more space between chevron and text.

@FaridAghili please make a new issue, this PR is long enough as is.