Issue confirmed.

I suggest reverse the url segments for rtl-languages. I may make a PR.

do you know where can I find the url segments?

@Hackwar
What do you think?

Sorry, but I don't understand the issue fully. Are you saying that you want the URL to be inversed or that it is falsely inversed?

The url need to be rtl "http://example.com/menu1/submenu1/article1"
it is now like this "http://example.com/article1/submenu1/menu1" in rtl language .

I can't find anything in the core code that would inverse the URL. I would guess that that is some special code in the language pack that adds its own routing rule and produces this.

@Hackwar
I don't think so. RTL is at stake here, no special code in language packs.

I can confirm this issue ONLY when the url is unicode. When the alias etc is written in latin character set then there is no problem when using an RTL language (even if use unicode is selected) but as soon as the alias is unicode eg hebrew or arabic characters then the url is reversed as stated by @islam2hamy

I've looked through the code and can't find a place where this is done.

Well its happening somewhere ;) and its not if its RTL but if it is RTL +
unicode alias

On 25 April 2016 at 14:20, Hannes Papenberg notifications@github.com
wrote:

I've looked through the code and can't find a place where this is done.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8931 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I believe you. The code is most likely in a place where it doesn't belong and was written with the best intentions. I'm just saying that I can't find it, at least not in the core routing code.

I am thinking maybe there is no code for this at all and its a default behavior of browsers. However , to fix that, we should add some lines of codes.

I think its not the browser but the inherit nature of the unicode characters that are setting everything to RTL
We are expecting it to be domain.com/category/article where they are three distinct parts but PERHAPS we are sending category/article as a single "word" so the entire block is being set to RTL and not as individual blocks

ok , i see .

so , any good news ?

i think it is all about the category / article "id" , if it can be in the end of category / article in the RTL url , it may work !

components/com_content/router.php

http://example.com/products/32-fruit/1-apple -----> http://example.com/products/fruit-32/apple-1

That would not work. It has to be id-alias

if i print an article we will see that , the url at the top off the page look like this

"article1/submenu1/menu1/http://example.com"

the site domain name appear before the article link detail

is this illustrate anything ? or it is from the PDF!

HI THERE
I am in documentation team translation to Arabic language.
the same issue occurred when translation some documents in other languages that use RTL.

problem cause:
It is common for content in Arabic, Parisian, and other languages that use right-to-left scripts to include numerals or include text from other scripts. Both of these typically flow left-to-right within the overall right-to-left context.

it is important to realize that, basically, the problems all occur when content in one direction includes an inline phrase in the opposite direction. We will call these opposite-direction phrases. An opposite-direction phrase may be a single directional run (such as a word), or may be a set of directional runs with an embedded change in base direction.

Common examples of such phrases include quotations, titles of books, articles or plays, formatted numbers (e.g. phone numbers and MAC addresses), street and email addresses, and various names, such as brand names, acronyms, part numbers, site names, place names, file names (and paths), etc.

The problem is worse in applications that drop text into a page, say from a database. The application often does not know a-priori whether such text is (or perhaps contains) an opposite-direction phrase, and has to estimate its direction at run-time by checking the Unicode ranges of its characters. HTML5 introduces a feature for doing so in the browser.

Whenever an opposite-direction phrase occurs, things can go wrong. That is, something will go wrong if the text includes, without any special "wrapping", an inline opposite-direction phrase that:

begins or ends with neutral characters,
begins with a number,
is followed by a number,
is followed by another, but logically separate, opposite-direction phrase,
contains one or more nested phrases whose base direction is opposite to that of the phrase.

that is the issue you can find the full description and how to solve in the following link in W3C
https://www.w3.org/International/articles/inline-bidi-markup/

hope that will solve the problem to fix lot of things that you mentioned and others in joomla! for unicodes.

thanks all

Hi and thanks for your explanation. Unfortunately although it's a related
issue of bidi it's going to need a different solution as we are taking
about URLs here so can't apply a direction tag.

yes but maybe this link describe the problem more
https://www.w3.org/International/wiki/IRIStatus#Unicode_Bidirectional_Algorithm_Failure
for URLs

yes - perfect - thats exactly it - THANKYOU

On 7 August 2016 at 01:06, Hussien Al Bosyri notifications@github.com
wrote:

yes but maybe this link describe the problem more
https://www.w3.org/International/wiki/IRIStatus#Unicode_Bidirectional_
Algorithm_Failure

for URLs

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/8931
https://issues.joomla.org/tracker/joomla-cms/8931.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8931 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8dJfTRSaoTv5RBrWsunQ7ysi4FV-ks5qdSGRgaJpZM4HHIHm
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Hi

I am closing this as a known issue. It is not a Joomla issue but an internet browser / operating system issue and there is nothing we can do about it (check other systems and you will see the same thing).

It may look odd to some people but its the expected behaviour when you mix an LTR domain with an RTL url.