(In reply to comment #0)

... As I see it, there should be three icons: audio, video, and
document (PDF).
#bodyContent a.internal[href $=".ogg"],
.link-audio {

background: url("audio_icon.gif") center right no-repeat;
padding-right: 16px;

}
I'm not sure what the browser support for $= is since it's CSS3, but I assume
it's the same as ^=, which is already used.
I'd patch it myself, but I'm new to this and don't know if there are any places
other than monobook.css this needs to be addressed.

This would also address bug 1311.

yes: http://bugzilla.wikipedia.org/show_bug.cgi?id=1311
and: http://bugzilla.wikipedia.org/show_bug.cgi?id=1254

This works for my Netscape 7.1 (AFAIK), but it does not work correctly for all
browsers, the Internet Explorer is a touchy thing. I am also not an expert.

I think, all bugs 1245, 1311 and this 1578 should be linked and treated
together, as they are similar.

Tom

flamurai wrote:

This bug contains bug 1311. I agree that they're all similar and should be
addressed in a similar way (mainly CSS, not through the PHP page rendering
engine), but I think this bug is more urgent than bug 1245 because it is a major
UI flaw having the external link icon display for things that aren't external links.

I don't think browser compatibility is a huge deal considering we're already
using CSS3 to display the external link icon. This isn't a make-or-break
feature, and there is no major UI flaw if the external link icon isn't
displaying at all.

I'll try to create some icons in the style of the monobook external link icon.

flamurai wrote:

I meant bug 1254... sorry about that.

flamurai wrote:

Thinking ahead, there's a minor issue with doing this in CSS: Both Ogg Vorbis
and Ogg Theora files use the ogg extension. There is no way to distinguish
between video and audio files just from the filename. Off the top of my head, I
can't think of a good icon that would work for both video and audio files.

However, for now I think it works to use an audio icon for ogg files and a
document icon for pdf files.

flamurai wrote:

Screenshot of proposed media links with icons

Attached:

flamurai wrote:

audio icon

attachment audio.png ignored as obsolete

flamurai wrote:

document icon

attachment document.png ignored as obsolete

flamurai wrote:

video icon

attachment video.png ignored as obsolete

flamurai wrote:

Patch to /skins/monobook/main.css

This patch adds two rules to main.css applying an audio icon to internal links
to ogg files and a document icon to internal links to pdf files. There is no
rule for video files since there is not yet an officially supported video
format for the Wikimedia sites.

attachment mediaicons.patch ignored as obsolete

flamurai wrote:

improved document icon (not in screenshot)

Attached:

flamurai wrote:

Patch to skins/monobook/main.css

Shrank padding of audio link by a pixel. (The rest of the icons have solid left
edges while this doesn't, so it appears to be farther away from the text even
though it really isn't.)

attachment mediaicons.patch ignored as obsolete

avarab wrote:

flamurai said:
"Thinking ahead, there's a minor issue with doing this in CSS: Both Ogg Vorbis"
"and Ogg Theora files use the ogg extension. There is no way to distinguish"
"between video and audio files just from the filename."

.ogm has been gaining ground as an extension for video files in the Ogg wrapper.

zigger wrote:

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

zigger wrote:

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

ui2t5v002 wrote:

I made a similar proposal here:

http://en.wikipedia.org/wiki/Template_talk:Audio#Feature_request

http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#Audio_links

This would be really helpful.

ui2t5v002 wrote:

I'd like to add this to the site css for an audio link class:

.audiolink a{

background:

url("http://upload.wikimedia.org/wikipedia/commons/f/f7/Loudspeaker.png") center
left no-repeat !important;

padding-left: 16px !important;
padding-right: 0 !important;

}

though if something similar is being done elsewhere, I don't want the
implementations to conflict. Please comment:

http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#A_solution

Also, as an aside, for those who use Firefox and want an icon next to media
files, you can get the Target Alert extension. It's nice. :-)

http://www.bolinfest.com/targetalert/

ui2t5v002 wrote:

The PDFlink, DOClink, and RTFlink templates perform the same functionality as
this bug. It has been suggested that we use CSS and templates to create icons
for *all* file types, in lieu of this bug being fixed. Should we go ahead with
this? Will this bug ever be fixed?

It would be more efficient and "proper" to actually fix the bug in Mediawiki,
but if that's never going to happen, we'll just do it with templates.

http://en.wikipedia.org/wiki/Template_talk:PDFlink#Other_link_templates

ayg wrote:

IE7 now supports the appropriate CSS selectors to add icons to the end based on
filetype. This seems like a good idea, I'll see about adding this.

ui2t5v002 wrote:

(In reply to comment #18)

IE7 now supports the appropriate CSS selectors to add icons to the end based on
filetype. This seems like a good idea, I'll see about adding this.

As I said, I've already done this for PDF links. Adding other file types would
be trivial, but doesn't solve the bug because it doesn't work on all browsers.

http://en.wikipedia.org/wiki/Template_talk:PDFlink#Changing_the_icon_and_using_it_for_.2Aall.2A_PDF_links

http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_2#Similar_for_PDF_files.3F

http://en.wikipedia.org/wiki/Template_talk:DOClink

To really fix the bug, Mediawiki needs to add a CSS class to each link depending
on its type (class="external text" should become either class="external PDFlink
text" or class="PDFexternal text" or something like that, depending on
implementation), and then the icon displayed will be determined from the
site-wide CSS.

For now, we are using templates to add the CSS class manually. We are going to
expand the templates to cover all file types if Mediawiki is not going to be
fixed any time soon.

ui2t5v002 wrote:

Go to http://en.wikipedia.org/wiki/MediaWiki:Common.css and search for "Change
the external link icon to an Adobe icon for all PDF files" to see the current
implementation.

You should already be seeing PDF icons for PDF external links in IE7 if it
supports the selectors.

ayg wrote:

Every major browser, to my knowledge, now supports the [href$=".xxx"] selector
in its latest versions. I don't think a class needs to be added when pretty
soon most people will be able to use the CSS rule; the code would be immediately
obsolescent, and it's no big deal if some people don't see the pretty icons. So
no, I at least have no intention to "fix" MediaWiki in the way you want, but I
do plan to fix this bug via CSS selectors such as the one you added to Wikipedia.

It remains necessary to find GPL-compatible icons for all the filetypes we want
to support, of course. Shouldn't be too hard for generic "document", "picture",
"sound", "video", but beyond that it could get tricky.

(In reply to comment #20)

You should already be seeing PDF icons for PDF external links in IE7 if it
supports the selectors.

I am.

ui2t5v002 wrote:

(In reply to comment #21)

So
no, I at least have no intention to "fix" MediaWiki in the way you want, but I
do plan to fix this bug via CSS selectors such as the one you added to Wikipedia.

Ok. We'll do it with CSS and templates, then.

It remains necessary to find GPL-compatible icons for all the filetypes we want
to support, of course. Shouldn't be too hard for generic "document", "picture",
"sound", "video", but beyond that it could get tricky.

Flamurai uploaded icons to this bug report that match the icons included with
Monobook. I'm sure he'd create any others we needed.

Also, Michael180 created this set of icons specifically for Mediawiki:

http://commons.wikimedia.org/wiki/Category:Nuvola-inspired_File_Icons_for_MediaWiki

That page also mentions modifying ImagePage.php, which I hadn't noticed before.
What's that about?

ayg wrote:

Hm, wait, this is for internal links? Do we want these icons for internal,
external, or both? Maybe some modified version should be used for external
links, incorporating the arrow we have now? I think it's best for internal and
external to display differently, but incorporating this data in links of both
kinds is a good idea. flamurai, would you be interested in making new icons to
incorporate "external sound, external video, external document" ideas?

(In reply to comment #22)

Flamurai uploaded icons to this bug report that match the icons included with
Monobook. I'm sure he'd create any others we needed.

Those are excellent, yes. Thank you for pointing them out.

Also, Michael180 created this set of icons specifically for Mediawiki:

http://commons.wikimedia.org/wiki/Category:Nuvola-inspired_File_Icons_for_MediaWiki

That page also mentions modifying ImagePage.php, which I hadn't noticed before.
What's that about?

That's a different issue. Those images are intended to be used to display on a
media page where the file can't be thumbnailed. See current behavior at, e.g.,
[[commons:Image:StephansdomAnnotated.pdf]] for ImagePage display. They're way
too big to scale well to the size needed for external link icons.

ui2t5v002 wrote:

(In reply to comment #23)

Hm, wait, this is for internal links? Do we want these icons for internal,
external, or both?

External. There's no way to link to PDFs or DOC files internally.

Those are excellent, yes. Thank you for pointing them out.

They don't differentiate file type like the PDF icon we are currently using,
though. People except PDF icons to have some red in them.

That's a different issue. Those images are intended to be used to display on a
media page where the file can't be thumbnailed.

I see that now. The PDF icon actually looks pretty good scaled down, but the
others not so much.

robchur wrote:

There's no way to link to PDFs or DOC files internally.

[[Media:Wiki this, wiki that.pdf]]

ui2t5v002 wrote:

(In reply to comment #25)

There's no way to link to PDFs or DOC files internally.

[[Media:Wiki this, wiki that.pdf]]

Hmmm.. But we don't allow PDFs to be uploaded. There are a few left over from
when we did, but that's a very small issue, and they aren't going to be linked
to from articles. No internal links have icons, but you want to change that if
the internal link leads to images or sounds? We already have templates for
displaying internal audio links with loudspeaker icons and internal video links
with film strip icons. With CSS changes applied to internal links, clickable
images would have a little image icon next to them, too. I was thinking
entirely of external links. Like flamurai said "it is a major UI flaw having
the external link icon display for things that aren't external links".

robchur wrote:

Where "we" is Wikimedia, yes. But this is filed against MediaWiki in general,
and so it would be nice to fulfill it for all MediaWiki implementations, no? Any
road, I wasn't stating that I thought this should be applied to internal links,
I was correcting your apparent misconception as to the linking process.

ui2t5v002 wrote:

(In reply to comment #27)

Where "we" is Wikimedia, yes. But this is filed against MediaWiki in general,
and so it would be nice to fulfill it for all MediaWiki implementations, no?

Of course.

Any
road, I wasn't stating that I thought this should be applied to internal links,
I was correcting your apparent misconception as to the linking process.

Ok. I guess the original comment was about internal links, while all of my
comments have been exclusively about external links. So different people are
talking about different things. This is how I'm imagining it *should* work for
Wikipedia:

• Internal links should be icon-less like they always have been, and indicators

should be provided by templates like {{listen}}, {{multi-listen_start}},
{{audio}}, {{video}}, {{multi-video_start}, etc.

• External links should have the icons they currently have for mailto: news: and

the like, but http: links should only have the current external link if they go
to an html/xhtml/etc page. If they go to a PDF, DOC file, directly to an image,
sound file, or video, then the regular external link icon should be replaced
with a file type icon. Ideally, this would be done inside Mediawiki by adding a
CSS class to recognized file extensions, but adding the icon with an advanced
CSS selector and optionally with templates is almost as good.

If we want Mediawiki to support icons for both internal and external, that's
fine and all; this is just what I'm imagining for Wikipedia.

ayg wrote:

Icons added via CSS in r17593 for ogg, mid, midi, mp3, wav, wma (audio); ogm,
avi, mpeg, mpg (video); pdf (document). Still not fully fixed:

• There should be separate icons for PDFs and other documents (like DOCs, ODFs,

etc.), or else the current one should be used for both (opinions?)

• There should be an icon for image files
• There should maybe be a separate icon for interactive things like Flash
• Probably more file formats should be supported

ayg wrote:

(and r17594)

ui2t5v002 wrote:

(In reply to comment #29)

Icons added via CSS in r17593 for ogg, mid, midi, mp3, wav, wma (audio); ogm,
avi, mpeg, mpg (video); pdf (document).

Those two lines don't cover every type of URL, though. For the PDF links, we
had all these selectors:

/* Change the external link icon to an Adobe icon for all PDF files */
/* (in browsers that support these CSS selectors, like Mozilla and Opera) */
#bodyContent a[href$=".pdf"].external,
#bodyContent a[href*=".pdf?"].external,
#bodyContent a[href*=".pdf#"].external,
#bodyContent a[href$=".PDF"].external,
#bodyContent a[href*=".PDF?"].external,
#bodyContent a[href*=".PDF#"].external {

background:

url(http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Icons-mini-file_acrobat.gif/15px-Icons-mini-file_acrobat.gif)
center right no-repeat;

padding-right: 16px;

}

/* Change the external link icon to an Adobe icon anywhere the PDFlink class */
/* is used (notably Template:PDFlink). This works in IE, unlike the above. */
span.PDFlink a {

background:

url(http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Icons-mini-file_acrobat.gif/15px-Icons-mini-file_acrobat.gif)
center right no-repeat !important;

padding-right: 17px !important;

}

See
http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_2#Similar_for_PDF_files.3F

• There should be separate icons for PDFs and other documents (like DOCs, ODFs,

etc.), or else the current one should be used for both (opinions?)

Each file type needs its own icon. That's the whole point.

ayg wrote:

(In reply to comment #31)

Those two lines don't cover every type of URL, though. For the PDF links, we
had all these selectors:

I've implemented those for PDFs. While anchors are used for PDFs, they aren't
for any other filetype I know of besides HTML, and query strings aren't usually
used for any non-dynamic content, so their presence for even PDFs is
questionable. Yes, technically you could add meaningless anchors or query
strings to the end of these things (and MediaWiki actually does add meaningless
query strings to style/script includes for cache control), but you could also
link to a PDF file with ".pDf" if you wanted to.

Each file type needs its own icon. That's the whole point.

Well, each general category does. I largely agree that PDF and document-y files
should have distinct icons because they're noticeably different in terms of user
experience, but PNG vs. JPG is a distinction most viewers will neither know nor
care about.

ayg wrote:

Unassigning from me, it's graphical work that needs to be done at this point.

ayg wrote:

Removing patch keyword, no patch is available for what needs to be done now (more icons).

(In reply to comment #28)

• External links should have the icons they currently have for mailto: news: and

the like, but http: links should only have the current external link if they go
to an html/xhtml/etc page. If they go to a PDF, DOC file, directly to an image,
sound file, or video, then the regular external link icon should be replaced
with a file type icon.

I don't know if you're aware, but this already happens for some extensions; see http://www.mediawiki.org/wiki/Help:Links#External_links

Ugh, sorry, I missed comment #29 -- disregard my remark above.
How un-wiki of Bugzilla that we can't edit or delete our own comments (at least before someone replies to them, it could be possible).

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

sumanah wrote:

Removing patch keyword per comment 34. If flamurai's patch is now obsolete, flamurai, go ahead and edit its details to mark it obsolete.

Comment on attachment 311
Patch to skins/monobook/main.css

Patch is obsolete, code exists in Monobooks main.css

Comment on attachment 306
audio icon

Image is in SVN

Comment on attachment 308
video icon

Image is in SVN

What is still remaining on this?

Going through old bugs...

I'm going to Be Bold and 'wontfix' this; the little link icons are awful and notoriously tricky to get right (case issues, parameters on URLs, URLs that look like files but are description pages, etc).

If people want pretty link formatting for specific purposes, consider using a template or explicit style marker for making links in the style you want.

(In reply to comment #43)

I'm going to Be Bold and 'wontfix' this; the little link icons are awful and
notoriously tricky to get right (case issues, parameters on URLs, URLs that
look like files but are description pages, etc).

In that case, shouldn't current extension-dependent custom icons be removed too, for the same reasons + consistency?
https://www.mediawiki.org/wiki/Help:Links#External_link_icons