Page MenuHomePhabricator

Add direction marks to stop some annoying problems
Closed, ResolvedPublic

Description

Author: adinadav

Description:
When displaying a latin article name AND a latin user name, the editor's
username apears to the right of the article name (between namspace and article
name), breaking normal reading order and making the username unclickable.
a simple rtl mark after the article name should solve this.


Version: unspecified
Severity: trivial

Details

Reference
bz5724

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:13 PM
bzimport set Reference to bz5724.
bzimport added a subscriber: Unknown Object (MLST).

rotemliss wrote:

I suggest to add a RTL/LTR mark (depending on the site direction, see the use of
the arrows in the double redirects special page) in such places. RLM is between
the following A and B: A‏B; LRM is between the following A and B: A‎B. You can
also use the entities ‏ and ‎.

A patch may come soon. Please fix it also in REL1_6.

gangleri wrote:

Hallo!

Please see also
http://www.anubite.co.uk/mediawiki/head-rtl/index.php/Mw16:Special_pages/%21list
http://www.anubite.co.uk/mediawiki/head-rtl/index.php/template:Listspecial
http://epov.org/wd-gemet/index.php?title=Template:listspecial&action=edit

The method is quite stable regarding the position of list items with variable /
unpredictable LTR / RTL / bidi content in lists

a) Please start with the lines with ‎|rlm;
b) In order to place unknown (translated / untranslated) MediaWiki messages in a
certain list place you can / should embed them in
<span dir="ltr|rtl" >message or field</span>&lrm;&rlm;
c) Please define the directionality of character sequences which have bidi
neutral directionality as space, "(", "|", ")", "[", "]" etc. with a ending
&lrm;|&rlm;
d) so far I have seen only timestamps using LTR numbers but thing about
requirements from Bug 5679: Timestamps not rendering in Bangla numerals in bn-wiki

Good luck!

best regards reinhardt [[user:gangleri]]

rotemliss wrote:

Patch (trunk)

It's a very small patch, but it works on Recentchanges, Watchlist and
Recentchangeslinked. Please check it in.

attachment patch ignored as obsolete

rotemliss wrote:

The patch is based on a work of r14011 which was done only in trunk, so there
won't be a patch for REL1_6.

gangleri wrote:

(In reply to comment #4)

The patch is based on a work of r14011 which was done only in trunk, so there
won't be a patch for REL1_6.

Thanks Rotem Liss!
Unfortunately r14011 does not cover all cases. See
Bug 5807: Improper list alignment with Unicode Character 'ARABIC DAMMA' (U+064F)

rotemliss wrote:

(In reply to comment #5)

(In reply to comment #4)

The patch is based on a work of r14011 which was done only in trunk, so there
won't be a patch for REL1_6.

Thanks Rotem Liss!
Unfortunately r14011 does not cover all cases. See
Bug 5807: Improper list alignment with Unicode Character 'ARABIC DAMMA' (U+064F)

I think it's not related.

rotemliss wrote:

Please check in the patch, for this bug is very annoying in the RTL projects,
but its fix is very small and cannot cause problems.

gangleri wrote:

(In reply to comment #7)

Please check in the patch, for this bug is very annoying in the RTL projects,
but its fix is very small and cannot cause problems.

Niklas works at Recentchanges.php .
I proposed the changes from
http://nike.users.idler.fi/dev/index.php?title=user:Gangleri/BiDi/sandbox&diff=20065&oldid=20061
to fix
http://nike.users.idler.fi/dev/index.php?title=Toiminnot:Recentchanges&uselang=fa
http://nike.users.idler.fi/dev/index.php?title=Toiminnot:Recentchanges&uselang=he
http://nike.users.idler.fi/dev/index.php?title=Toiminnot:Recentchanges&uselang=de

Hope to get this fixed and that more patches will come soon:
http://nike.users.idler.fi/betawiki/Luokka:Patch/BiDi
and later also other pages as
http://nike.users.idler.fi/dev/index.php?title=%D7%90&action=history&uselang=he

best regards reinhardt [[user:gangleri]]

rotemliss wrote:

Patch v2 (trunk)

I've created a new, improved patch, which adds two more direction marks in the
right places. The three direction marks are added at the following places (the
explanations assume you use an RTL wiki, but they also apply to LTR wikis if
you read "RTL" instead of "LTR"):

  1. Before the edit summary, to prevent confusion when both the user name and

the edit summary start is LTR.

  1. Before and after the user name in the signatures, to prevent confusion when

both the end of sentence and the user name are LTR, or when both the user name
and the date/time are LTR.

  1. After the user name in the changes list (recentchanges, recentchangeslinked,

watchlist, etc.), to prevent the very popular and very, very annoying confusion
when both the user name and the page name are LTR, and the smaller confusion
when both the user name and the date/time are LTR.
These three fixes stop the annoying problems – especially the third one –
and make no harm as far as I've checked.

attachment patch ignored as obsolete

rotemliss wrote:

Patch v3 (trunk)

This patch also does the following things:

  • Documents the function Language::getDirMark, which was not documented.
  • Replaces the entities with real marks in Language::getDirMark, to prevent

problems when the HTML is not parsed (edit summaries), or when editing the page
with signatures (a hidden character isn't annoying to see like an entity).

  • Adds a mark between the edit summary and the log action text in the recent

changes (in the last patch it wasn't possible, because the entities, which were
not parsed, were used).

Please check this patch in, because the problems are very annoying.

attachment patch ignored as obsolete

rotemliss wrote:

Patch if Bug 6100 is not fixed

This patch also adds the direction mark:

  • Between the image file name and the info about it, because the image

extension is most likely in English, and so is the number of kilobytes in the
info, and it will confuse the text direction and make the link to the image
unclickable in Gecko browsers.

  • Between the user name and the log entry in the log page, as in the move page,

a user in English moves a page in English may confuse the direction.
Please check this patch in, the bug is very annoying but the patch is small.

attachment patch ignored as obsolete

rotemliss wrote:

*** Bug 3016 has been marked as a duplicate of this bug. ***

pablo wrote:

I think Lang should be used instead of LangCont

rotemliss wrote:

(In reply to comment #13)

I think Lang should be used instead of LangCont

I don't think so, as the page direction is not changed when the language is
changed (just another bug, because the whole page direction should be changed,
although the content itself should be in the content direction).

pablo wrote:

I mean for the dirmar, it should be wgLang->DirMark(), as the prupose of those
is to fix the ordering of the elements of the line for the *user language*.

In the patch for bug #6100 I put much more dirmark (from Lang, not ContLang) in
all the lists, logs, etc. between the different elements, so they show in the
proper ordering according to user language directionality.
Additionally, article links get enclosed in <span dir=ltr|rtl> </span> in the
case when wiki direction is different from user language direction (that way,
the article name are displayed correctly in those list, logs, etc)

I agree that in getUserSig() ContLang should be used, but in all other cases, it
should be Lang instead.

Try testing viewing an RTL wiki with a uselang in LTR; or the other way, and you
will see that the dirmarks should indeed be in the user language directionality
not in the wiki directionality.

rotemliss wrote:

(In reply to comment #15)

I mean for the dirmar, it should be wgLang->DirMark(), as the prupose of those
is to fix the ordering of the elements of the line for the *user language*.

In the patch for bug #6100 I put much more dirmark (from Lang, not ContLang) in
all the lists, logs, etc. between the different elements, so they show in the
proper ordering according to user language directionality.
Additionally, article links get enclosed in <span dir=ltr|rtl> </span> in the
case when wiki direction is different from user language direction (that way,
the article name are displayed correctly in those list, logs, etc)

I agree that in getUserSig() ContLang should be used, but in all other cases, it
should be Lang instead.

Try testing viewing an RTL wiki with a uselang in LTR; or the other way, and you
will see that the dirmarks should indeed be in the user language directionality
not in the wiki directionality.

If I use a Hebrew wiki, and watch in the English language, the whole page
remains *RTL*, and the parts of the text I want to avoid confusion with remain
RTL. Of course other parts of the interface are confused, but I don't try to
avoid it this patch. If a user with an English name edits a page with an English
name in a Hebrew wiki, they are confused, and I want to use RLM to avoid it;
however, if I change the user language to English (by "uselang", or by the
preferences), the page direction is not changed, and the user name and page are
still confused. Then I use the English direction mark – LRM – but it doesn't
solve the problem. I have to use $wgContLang since the page direction is set by
$wgContLang; and although there are some confusions if I use, for example,
http://he.wikipedia.org/w/index.php?title=Special:Recentchanges&uselang=en
they are not related to this bug, but are another bug should be fixed.

rotemliss wrote:

Patch if Bug 6100 is fixed

Now that we change the page direction by the user language, we should use
$wgLang. Using it.

Please commit this fix – it is very needed and makes no harm.

attachment patch ignored as obsolete

rotemliss wrote:

Comment on attachment 1793
Patch if Bug 6100 is not fixed

If Bug 6100 is not fixed, check in this patch.

rotemliss wrote:

Comment on attachment 1866
Patch if Bug 6100 is fixed

If Bug 6100 is fixed, commit this patch instead.

rotemliss wrote:

Patch (trunk)

Just commit that one, it fixes all the problems.

Attached:

rotemliss wrote:

Fixed everything, except for the signature issue.