Looks fine in Safari 1.2.4. Could you specify exactly which browsers (and versions) on which operating
systems (and verisons) you've tested? (Presumably IE is not affected if you say it doesn't even display the
image.) Can you confirm whether it's only media links with Farsi names, or also external links in general?

Consider filing a separate bug for the presence of the icon.

rowan.collins wrote:

I can confirm that the external link icon appears over the text in the given
page in both Mozilla 1.7b and Firefox 0.10.1 under Windows 2000. And it does
indeed not appear at all under IE 5.0.

jnc wrote:

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

zigger wrote:

More browser reports with monobook (under Windows 2000):

• Firefox 1.0 displays the problem
• IE 6.0 does not display the link icon

zigger wrote:

Screenshot of problem from Firefox 1.0

Attached:

lars wrote:

I'm using the monobook skin for Wikipedia and have an ancient Mozilla 1.6
browser, where I see this problem. I tried to understand how the "arrow" works,
and it seems to be related to the part of the CSS file /skins/monobook/main.css
that says:

#bodyContent a[href ^="http://"],
#bodyContent a[href ^="gopher://"] {

background: url(external.png) center right no-repeat;
padding-right: 13px;

}

and that perhaps the "right" should be "left" if this is Hebrew, Arabic, or
Farsi. And the "external.png" should then also be available in a version
pointing to the nortwest rather than northeast.

Perhaps the quickest fix is to replace external.png with a blank image on
he.wikipedia.org and ar.wikipedia.org.

I don't know, I'm just guessing.

This is a RTL issue so.

This is fixed, the rule above is only referencing a.external and gopher now.

gangleri wrote:

REOPENing as requested by Gabriel a while ago on IRC

The "Press call" link at
http://wikimediafoundation.org/wiki/%D7%AA%D7%A8%D7%95%D7%9E%D7%94_%D7%9C%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94
is still rendering wrong / overlapping with Hebrew text.

[[wikimedia:תרומה לויקיפדיה]]

best regards reinhardt [[user:gangleri]]

This is fixed in RTL wikis, but not in RTL sections within LTR wikis. This will
need some markup help to make the different direction explicit, something along
the lines of

/* this can be used in the content area to switch off
special external link styling */
#bodyContent .plainlinks a,
#bodyContent span[dir="rtl"],
#bodyContent * span[dir="rtl"] {
background: none !important;
padding: 0 !important;
}

should work. There are other properties that might be desirable depending on the
language, so a match on lang would probably make even more sense (<span
lang="en-Gb" dir="ltr">), especially for Chinese and other scripts, but the
principle is the same.

Changing the summary to more general, since all icons added via CSS on background behave the same.

Version -> unspecified since it is general problem.

Recent tests:
Firefox 2.0.0.18 - problems persist.
Opera 9.62 - problems persist.

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

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

ahmad.m.sherif wrote:

proposed patch

I made a patch which may help displaying external links icons (and the new rss-feed icons). It was tested under

• IE 6.0.2900.2180 - Windows XP SP2
• IE 7.0.5730.11 - Windows XP SP2
• Opera 7.54u2 - Windows XP SP2
• Opera 8.54 - Windows XP SP2
• Opera 9.63 - Ubuntu 8.10
• Firefox 3.0.5 - Ubuntu 8.10, Windows XP SP2
• Safari 3.2.1 - Windows XP SP2
• Konqueror 4.1.3 - Ubuntu 8.10

Because FF2 has a problem with padding when the document is rtl, so it has to be disabled. The patch supposes that there are two extra css files (FF2Fixes.css and Opera9Fixes.css) and one extra icon (external-rtl.png), the last one is a mirror image of external.png.

FF2Fixes.css:

.rtl .external, a.feedlink {
padding: 0 !important;
background: none !important;
}

Opera9Fixes.css:

.rtl #bodyContent a.external {

background-image: url(external-rtl.png);
padding-right: 0;
padding-left: 13px;

}

.rtl a.feedlink {

background-position: right;
padding-right: 0;
padding-left: 16px;

}

Attached:

(In reply to comment #14)

Because FF2 has a problem with padding when the document is rtl, so it has to
be disabled.

Isn't there any work around for that? (Like forcing a special "display" or so)

ahmad.m.sherif wrote:

(In reply to comment #15)

Isn't there any work around for that? (Like forcing a special "display" or so)

I've tried using display and position properties before, but when the padding problem is solved, some other problems appears in the formatting of the text.

ahmad.m.sherif wrote:

The patch also has been tested under Google Chrome ‪1.0.154.48‬.

mohamed.m.k wrote:

I applied the patch in 47615.

ahmad.m.sherif wrote:

Patch for Opera9

Comment #14 contains wrong css code for Opera 9. This patch fixes it.

attachment opera.patch ignored as obsolete

ahmad.m.sherif wrote:

Replaces spaces with tabs

Since the first patch uses spaces instead of tabs, this patch uses tabs to keep up with the rest of the code. It also contains the previous fix of Opera 9.

Attached:

mohamed.m.k wrote:

applied in revision 47648. not marked as fixed until it is OK by brion|tim.

r47615 leaves odd space to the left of interwiki links (on LTR languages) that have CSS-added icons, for example [[irc:irc.freenode.net]], as interwiki links do not contain the "external" class so the ".ltr #bodyContent a.external" correction does not apply.

ahmad.m.sherif wrote:

(In reply to comment #22)

r47615 leaves odd space to the left of interwiki links (on LTR languages) that
have CSS-added icons, for example [[irc:irc.freenode.net]], as interwiki links
do not contain the "external" class so the ".ltr #bodyContent a.external"
correction does not apply.

This was reported previously in bug 18207 and there is a patch proposed there but no one reviewed/committed it.

ahmad.m.sherif wrote:

I believe it's fixed now.

sia wrote:

in mediawiki 1.15.1:
the mail_icon.gif by mailto:link not displayed, only external-rtl.png instead!?

This bug was reopened, but the reopening is not related to the problem and should probably have been filed as a separate bug. If you still experience this bug, please open a new ticket.