Last modified: 2012-09-27 01:10:57 UTC
In the vector skin in the Hebrew Wikipedia, the following order of the personal links should be: <li id="pt-userpage"... <li id="pt-mytalk"... <li id="pt-preferences"... <li id="pt-watchlist"... <li id="pt-mycontris"... <li id="pt-logout"... <li id="pt-optin-leave"... <li id="pt-optin-feedback"... Thanks
It looks like you're complaining about the fact that the personal links order is mirrored in RTL mode. From what I've heard from Trevor, this is intentional and is the only way to get it to work properly in some older browsers (IE6?).
I'm complaining because the order in monobook skin (according to the HTML source code) is correct and different from the order in the vector skin. I used to use IE6 with monobook skin but I never encountered a display problem with above links. I can't see why it should cause a problem in another skin. Nevertheless, if it causes a problem in IE6, it should be fixed locally -- changing (or messing up) the order for everyone isn't a solution.
The order in Monobook is wrong, it's not flipped because you can't do that in CSS in all browsers (float right float left). Vector actually does it right. What's the actual problem?
I disagree. The correct order is the one in monobook, which has been the order for over 5 years. That's the problem; please change the order, it is the community's desire.
(In reply to comment #4) > I disagree. The correct order is the one in monobook, which has been the order > for over 5 years. That's the problem; please change the order, it is the > community's desire. I assume it's also the community's desire for the links to actually be displayed correctly in all browsers? How is the order in the *HTML* even relevant?
Roan, I don't understand why it is a problem to flip the links. All browsers show the same order in monobook. Are you claiming that in vector it's not possible to choose the order as in monobook? Re order of HTML - I don't know what effects the order (I saw the source code was different so I thought that might be the problem). If CSS needs to be fixed, change the CSS so it will work like in monobook. BTW, in he.wikipedia were forced to move "new" pt-optin-try link using JS. Perhaps you can fix monobook too and move the pt-optin-try link to the end. Roan, IMO changing the inner order of the links won't create display problems in all browsers if there are no display problems right now. All we are doing is replacing a one link with another. BTW, there alreay is a display problem in IE8 with the links, but I figured it was a different problem (I intended to open a seperate bug for it after the order was fixed so that we can deal with one bug at a time). see: http://img688.imageshack.us/img688/8701/10944228.jpg
What we're basically saying is that the order in Monobook is "wrong" because it's not a mirror of the LTR version, so people reading RTL would read the logout link first and the userpage link last. This order is "backwards" for several reasons (logout link is the first one, user page comes after talk page), so in Vector we flipped the links around so people reading RTL actually read the user page link first (on the right side) and the logout link last (on the left side), just like people reading LTR see the user page link first (on the left side) and the logout link last (on the right side). For this reason, we believe that the Vector order is the more "correct" one. I can see how it'd be confusing coming from Monobook, though. If the hewiki community wants to use another order, they can rearrange the links with JS. (In reply to comment #6) > BTW, in he.wikipedia were forced to move "new" pt-optin-try link using JS. > Perhaps you can fix monobook too and move the pt-optin-try link to the end. > The Try Beta link was *intended* to appear at the beginning of p-personal, before the user page link. That's also where it is on LTR wikis: on the left side. On hewiki in Vector, you'll notice that it's on the right side, because that's where the personal tools list begins in RTL. In Monobook it would appear on the left side if it weren't for your local JS moving it to the right. It seems to me that this backs up the argument that it makes sense for p-personal to be flipped in RTL.
(In reply to comment #7) > I can see how it'd be confusing coming from Monobook, though. If the hewiki > community wants to use another order, they can rearrange the links with JS. I disagree. I opened the request because I wanted the change to be encoded into the he.wikipedia source, and not be done using js. From the community's POV, this "fix" isn't a fix, but a problem. Thus, I don't see why a problem should be reated only for it to be fixed using JS on user-side. > The Try Beta link was *intended* to appear at the beginning of p-personal, > before the user page link. That's also where it is on LTR wikis: on the left > side. On hewiki in Vector, you'll notice that it's on the right side, because > that's where the personal tools list begins in RTL. In Monobook it would appear > on the left side if it weren't for your local JS moving it to the right. It > seems to me that this backs up the argument that it makes sense for p-personal > to be flipped in RTL. I disagree. The Try Beta link was inserted without asking the community where they'd like it to be, thus it was fixed using JS. This was not the correct way to handle it, but the easy way. The correct way would have been to fix the source code so that the Try Beta link would appear when the community wishes it to be. The theory that Hebrew speakers read left aligned text in RTL direction needs to be checked. I will present the question to the community and see what the Hebrew speakers think (I read English too, so my opinion isn't worth anything).
(In reply to comment #8) > (In reply to comment #7) > > I can see how it'd be confusing coming from Monobook, though. If the hewiki > > community wants to use another order, they can rearrange the links with JS. > > I disagree. I opened the request because I wanted the change to be encoded into > the he.wikipedia source, and not be done using js. From the community's POV, > this "fix" isn't a fix, but a problem. Thus, I don't see why a problem should > be reated only for it to be fixed using JS on user-side. > Note that this behavior is not specific to hewiki, but to all RTL wikis. We're not going to rearrange the HTML for one project, that's what site-specific JS is for. OTOH, if speakers of most of the large RTL languages agree that Monobook's behavior is better, we can reconsider.
see above
