Last modified: 2011-01-25 01:15:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2044, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 44 - Rename the "Image" namespace to "File"
Rename the "Image" namespace to "File"
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement with 19 votes (vote)
: ---
Assigned To: Brion Vibber
http://sourceforge.net/tracker/index....
:
: 2890 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-14 10:57 UTC by Antoine "hashar" Musso (WMF)
Modified: 2011-01-25 01:15 UTC (History)
30 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to MessagesEn.php to add make image namespace into File namespace, and add Image as alias (601 bytes, patch)
2008-08-15 16:49 UTC, Jon Harald Søby
Details
Updated patch, includes testcases and canonical name change (29.91 KB, patch)
2008-10-06 18:22 UTC, Brion Vibber
Details
Patch I will apply shortly (32.92 KB, application/octet-stream)
2008-11-17 21:21 UTC, Siebrand Mazeland
Details

Description Antoine "hashar" Musso (WMF) 2004-08-14 10:57:29 UTC
FEATURE REQUEST MOVED FROM SOURCEFORGE

Date Submitted:
2002-06-29 07:02

 It seems a bit messy to have all files grouped in the image:namespace.
I think it would it be desirable to have sound files in a sound:namespace and
all other files in a
file:namespace. But then if only one namespace is needed due to the fact that
all these pages for these
files are to be treated in a similar manor, then I vote for something neutral
like "file" for the namespace
name. 


Date: 2002-06-29 22:56
Sender: lcrocker
Logged In: YES 
user_id=3076

There are several issues: one, there's two different ways to
include them in links: [[image:filename]] produces an HTML
img tag, while [[media:filename]] produces an external link
(which can be used for sounds, movies, and anything else). 
There may have to be others if we need to have special HTML
for them--Java applets, for example.

"Image:" is also the name of the namespace for the
description pages.  I definitely /don't/ want to create a
dozen namespaces for no reason--one for all of them is
plenty.  It could be "File" or "Media"
though.

But on the other hand, I want to emphasize that the purpose
of file uploads is to upload illustrations for the
encyclopedia.  If you just call it "file upload", then
people upload all sorts of useless crap.  I expect 90% of
uploads to be images.  I don't think it's too much of a
stretch to use that term loosely for other downloads.


Date: 2002-07-21 13:17
Sender: vibber
Logged In: YES 
user_id=446709

IMHO, the Image: namespace and kin (eg Media:) ought to
merely be linking magic -- and I should point out that it's
*wonderful* linking magic, and thank you Lee for
implementing it! -- but nothing more. Using that exact same
namespace for the description page raises the serious issue
of _how do you link to the description page[1] without
putting a giant picture in the article you're linking from_?

[1] Most likely from a user: or talk: page where one is
discussing files that have been uploaded by a user or in
relation to an article.

Yes, you *can* put in the full URL, but that's not the wiki
way. Having the file descriptions in, say, "File:"
or 'File
description:" or "Media description:" (or even
"Image
description:" ... or heck, "Image talk:") would,
I think,
make things a little clearer potentially.
Comment 1 Guttorm Flatabø 2004-09-09 20:13:36 UTC
You can link to images now, by putting a clon (:) in front of the link, so that
part of the bug is solved.

The other part is configurable from the Language.php file, right? In the
norwegian translation I'm working on now, I have configured the "image"
namespace to "File". I think this should be the default in english too, but to
use it in the Wikimedia projects, some kind of hack would have to be made to
avoid braking all the [[image:something]] links and so on.
Comment 2 Michael Zajac 2005-04-12 22:51:10 UTC
See also Bug 1880: "Interface for uploaded audio media".
Comment 3 Ævar Arnfjörð Bjarmason 2005-04-14 16:25:07 UTC
How about using File: for all files, and have methods for accessing said files,
for example 

* [[Image: to show it as an image
* [[Media: (or a better name?) to link directly do the file.
* [[Sound: (redundant, since people should just use media, but you get the idea...)
Comment 4 Rowan Collins [IMSoP] 2005-04-15 19:40:11 UTC
(In reply to comment #3)
> * [[Sound: (redundant, since people should just use media, but you get the
idea...)

Actually, I don't think this *would* be redundant. In the same way that, for
images, we use [[Image:...]] to display - and even manipulate - the image,
[[Sound:...]] (and [[Video:...]]) should provide a way of "displaying" audio
(and video) - either through some sort of plugin embedding, or at least through
a standardised template pointing at help, etc. 

See also bug 1880, [[meta:Multimedia]], and my suggestion, similar to yours, in
a recent wikitech-l post:
http://mail.wikimedia.org/pipermail/wikitech-l/2005-March/028494.html
Comment 5 Guttorm Flatabø 2005-04-17 14:10:45 UTC
(In reply to comment #4)
> Actually, I don't think this *would* be redundant. In the same way that, for
> images, we use [[Image:...]] to display - and even manipulate - the image,
> [[Sound:...]] (and [[Video:...]]) should provide a way of "displaying" audio
> (and video) - either through some sort of plugin embedding, or at least through
> a standardised template pointing at help, etc. 

Why use different "namespaces" for different media? I agree that there should be
ways to display other media than images, but do we need a differnet keyword for
each media type. I'd rather see [[Image:...]] changed to [[Show:...]],
[[Display:...]] or something, and [[Media:...]] to [[Filelink:...]],
[[Link:...]] or something like that. Then you'd use [[Show:...]] or
[[Display:...]] to display and possibly add multimedia controls to all kinds of
media, and [[Filelink:...]] when you wanted a direct link to the file. Perhaps
there should also be a third kind of linking to the decription page.

I suppose the feasability of this depends on how good MediaWiki can become at
recognizing types of media.
Comment 6 Marius 2005-07-08 02:16:26 UTC
Creating different namespaces for sound / etc. doesn't make much sense... It
would be similarly unnecessary as the .info domain. I agree that the 'Image'
namespace should be renamed to 'File' or something else neutral. It will be some
messy work but it will finally end the confusion for all the wiki newcomers. For
seperating different files like sound / video / images / documents / ... a file
separation tool could be implemented. This would probably do a better job than
creating new namespaces.
Comment 7 Brion Vibber 2005-07-18 16:31:19 UTC
*** Bug 2890 has been marked as a duplicate of this bug. ***
Comment 8 Duncan Harris 2005-09-30 22:53:20 UTC
In the German Wikipedia you can use either [[Bild:foo.jpg]] or [[image:foo.jpg]] to 
produce the same effect.  Could the namespace be renamed and keep a link between 
[[image:foo.jpg]] to [[File:foo.jpg]]?
Comment 9 Rowan Collins [IMSoP] 2005-10-01 12:49:53 UTC
(In reply to comment #8)
> In the German Wikipedia you can use either [[Bild:foo.jpg]] or
[[image:foo.jpg]] to 
> produce the same effect.  Could the namespace be renamed and keep a link between 
> [[image:foo.jpg]] to [[File:foo.jpg]]?

Currently, the software allows each namespace to have exactly 2 names: a
"canonical" name, which is the same on all installs (e.g. "Image:") and a
"local" name, which depends on the content language, and potentially other
configuration options (e.g. "Bild:").

As part of "wikidata", Erik has written some experimental code for defining
namespaces in the database, which includes the ability for each to have any
number of aliases. If that code makes it into the main software, "Image:" could
be made an alias of a namespace canonically known as "File:".

Meanwhile, I quite like the logic of having "[[Show:", "[[Filelink:", and
"[[File:" as replacements for "[[Image:", "[[Media:", and "[[:Image:". (Assuming
that we could make the current syntax work correctly through aliases)
Comment 10 Ævar Arnfjörð Bjarmason 2005-12-03 02:04:07 UTC
This bug has been fixed in the wikidata branch.
Comment 11 Brion Vibber 2006-01-12 22:40:26 UTC
Since that hasn't been applied to HEAD quite yet, reopening.
Comment 12 alerante 2006-02-16 01:34:09 UTC
(In reply to comment #9)
> As part of "wikidata", Erik has written some experimental code for defining
> namespaces in the database, which includes the ability for each to have any
> number of aliases. If that code makes it into the main software, "Image:" could
> be made an alias of a namespace canonically known as "File:".

This would also be useful for shortcuts ([[WP:WP]]), aliasing "WP:" to "Wikipedia:".
Comment 13 Brion Vibber 2006-02-16 02:01:26 UTC
I've got the namespace manager merged into the current code in a local tree;
when I'm done tweaking it up I'll commit it into CVS HEAD.
Comment 14 Ilyanep 2006-02-16 02:20:18 UTC
Cool cool. Let us know when that happens I'd like to test it out on the wiki I've got running on 
my localhost server.

All hail Brion and Jimbo as the true wikigods, and the other devs as demigods.
Comment 15 lɛʁi לערי ריינהארט 2006-02-16 10:45:26 UTC
(In reply to comment #13)
> I've got the namespace manager merged into the current code in a local tree;
> when I'm done tweaking it up I'll commit it into CVS HEAD.

This would be great and should not be abused (in order not to breake interwiki
links or block page / title space).
It probably would make the syntax for 'function getNsIndex' simpler or obsolte
it; see
http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/languages/LanguageYi.php?rev=1.8&view=auto

Please do not forget to drop some notes / an url about the syntax and please
provide a way to detect / see the alias list (just somthing as
{{ns:alias:project}} / {{ns:alias:4}}). Thanks in advance!

best regards reinhardt [[user:gangleri]]
Comment 16 Rob Church 2006-02-16 11:10:48 UTC
Why do you have to chuck a load of irrelevant nonsense into yet another bug
report? Please, just shut up unless you know what you're talking about or have a
bloody good reason to comment.
Comment 17 Brion Vibber 2006-05-31 18:47:34 UTC
*** Bug 6152 has been marked as a duplicate of this bug. ***
Comment 18 Jamie Hari 2007-06-22 00:38:29 UTC
Since Brion said back in Feb 2006 he would be moving this to HEAD, I assume this has probably been done and we can close this bug?
Comment 19 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-22 01:30:58 UTC
The namespace manager died like a year ago, so no.  I think we have unlimited aliases available for namespaces now, however, in which case this would be trivial to implement in trunk if we wanted to.
Comment 20 Robert Leverington 2007-12-23 14:09:43 UTC
It seams a bit silly for the user to have to decide whether they want to embed their media as a sound, image, video etc. Given that it is possible to identify this from its' extension or mime-type a simple [[File:...]] include system (similar to the current [[Image:...]] but with a name that makes more sense in today's context) would suffice IMO. Linking could still be done via [[Media...]] and [[:File...]].

Therefore from what I can tell the best solution would be to simply rename the Image: namespace to File: and leave an alias pointing Image: to File: for backwards compatibility (there are probably other things that will need fixing given the aliases on localised wikis). Perhaps current [[Image:]] references might also need converting. Am I correct in this assumption here or can someone see any flaws in my solution idea?
Comment 21 SJ 2008-01-30 05:58:43 UTC
Minute, I'm with you.  Some pretty wiki-savvy people recently wanted to know how to link to non-images, assuming image: and media: were just for special types of files, which made me sad.   
Comment 22 Jon Harald Søby 2008-08-15 16:49:35 UTC
Created attachment 5178 [details]
Patch to MessagesEn.php to add make image namespace into File namespace, and add Image as alias

This is a suggested patch (but is it really this simple?). I don’t know if it will be compatible with current sites using the image namespace or anything, but think it will work for new installations. But I have not tested it.

Also, if implemented, a lot of other messages would need to be changed as well, plus a shitload (=millions) of wiki pages, though the latter would not at all be urgent.
Comment 23 Steve Sanbeg 2008-08-15 19:04:27 UTC
That patch doesn't look like correct PHP syntax.

The canonical Namespaces are defined in Namespace.php, the file you changed is the default localisation for English.

I don't think you can have multiple localizations per language like that, but it should be possible to have a localized name for English, like most of the other languages have.
Comment 24 Daniel Friesen 2008-08-15 20:36:48 UTC
Firstly, yes, that syntax there is horribly invalid. It'll do nothing but break existing Image links.

Secondly, IMHO making Image: an alias to File: is a bad route to take. Rather you would rename the Image: namespace to File: and create a new Image: pesudo-namespace (Like Special: and Media:) meant for embedding a file in image format. Also Image_talk would be aliased to File_talk: for backwards compat.
Comment 25 Voyagerfan5761 / dgw 2008-08-16 04:01:00 UTC
I agree with Daniel Friesen's suggestions in the second paragraph of #24. I'm a bit skeptical of creating a special pseudo-namespace just for embedding files that happen to be images, but I suppose if all we'll have is the generic name "File", it's the solution that would most easily maintain backwards compatibility.

However, how would existing links to Image: pages work? Redirected to the File: namespace, I presume. Also, would linking to a file using File:name.ext embed the file or just (the behavior I would suggest) generate a link?
Comment 26 Chad H. 2008-08-19 01:49:27 UTC
Comment on attachment 5178 [details]
Patch to MessagesEn.php to add make image namespace into File namespace, and add Image as alias

Making patch as obsolete.
Comment 27 Benjamin Garn 2008-09-05 14:15:04 UTC
Picking up the idea of minute, i would suggest to interpret the mime type of files. As far as i can see it, we have three ways a file can be included.
1. embed the file
2. link the file
3. link the page for the file

So, why not for add a parameter for [[File: ... ]]?
It can be for example like this: [[File:MyFile.Ext|embed]], [[File:MyFile.Ext|link]] ...
In case of embedding you just analyse the mime/type. And for the customizing you can add a hook.

According to Voyager i suggest linking the file should be the default.

For backwards compatibility in the remaining [[Image: ]] elements you need of course embed as default for these.

Are there more opinions?
Comment 28 Thomas Goldammer 2008-09-05 14:29:02 UTC
(In reply to comment #27)
> 
> According to Voyager i suggest linking the file should be the default.
> 

No, embedding must always be default, because that's how files are used in the articles. Linking can just be done by [[:File:Nameofthefencyfile.ext|Text of the link]] as it is now. BR, Th.
Comment 29 Brion Vibber 2008-10-06 18:22:23 UTC
Created attachment 5394 [details]
Updated patch, includes testcases and canonical name change

Made against r41626, this patch:

* Updates Namespace.php canonical namespace names
* Updates MessagesEn.php namespace names and aliases
* Updates parser test cases with new 'File:' URLs
* Adds a parser test case using File: in an inline link

Unless there's a major issue, I'm planning to commit this in a week. Want to give warning first, for more testing and for bot and user script authors to find out if they need to fix their stuff!
Comment 30 Brion Vibber 2008-10-06 21:11:32 UTC
As currently written, this leaves {{ns:image}} broken.

{{ns:image}} and {{ns:file}} should both return the canonical name, probably. (Do we not have canonical aliases?)
Comment 31 Roan Kattouw 2008-10-07 12:58:28 UTC
(In reply to comment #30)
> As currently written, this leaves {{ns:image}} broken.
> 
> {{ns:image}} and {{ns:file}} should both return the canonical name, probably.
> (Do we not have canonical aliases?)
> 

Yes, Project and Project talk are canonical aliases for $wgSiteName and $wgSiteName talk.
Comment 32 Lupo 2008-10-07 19:01:56 UTC
(In reply to comment 29)

> Unless there's a major issue, I'm planning to commit this in a week.

Humble question: isn't a week's notice too short? I thought scripts were cached for 30 days on the client side? Even if a script is fixed now, users may still have old unfixed versions in their caches that may break when the switch occurs already in a week. Or did I misunderstand something?
Comment 33 Brion Vibber 2008-10-07 19:04:16 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > As currently written, this leaves {{ns:image}} broken.
> > 
> > {{ns:image}} and {{ns:file}} should both return the canonical name, probably.
> > (Do we not have canonical aliases?)
> > 
> 
> Yes, Project and Project talk are canonical aliases for $wgSiteName and
> $wgSiteName talk.

Those are the canonical *names*.
Comment 34 Roan Kattouw 2008-10-07 19:47:37 UTC
(In reply to comment #33)
> (In reply to comment #31)
> > (In reply to comment #30)
> > > As currently written, this leaves {{ns:image}} broken.
> > > 
> > > {{ns:image}} and {{ns:file}} should both return the canonical name, probably.
> > > (Do we not have canonical aliases?)
> > > 
> > 
> > Yes, Project and Project talk are canonical aliases for $wgSiteName and
> > $wgSiteName talk.
> 
> Those are the canonical *names*.
> 

Well since there are two names for one namespace, *one* of them has got to be an alias, right?
Comment 35 Ilmari Karonen 2008-10-09 00:58:17 UTC
r41876 makes {{ns:}} accept namespace aliases, so that {{ns:image}} will continue to work as long as "Image" is listed as an alias for "File".
Comment 36 Happy-melon 2008-10-27 16:15:27 UTC
Scary proposition though it is, wouldn't it be more neat-and-tidy to update "NS_IMAGE" to "NS_FILE" throughout the source code? Otherwise we're still internally perpetuating the poor choice of name, and introducing yet another silly idiosyncracy to trip over...
Comment 37 Brion Vibber 2008-10-27 16:20:43 UTC
(In reply to comment #36)
> Scary proposition though it is, wouldn't it be more neat-and-tidy to update
> "NS_IMAGE" to "NS_FILE" throughout the source code? Otherwise we're still
> internally perpetuating the poor choice of name, and introducing yet another
> silly idiosyncracy to trip over...

Could be done, but that's a separate issue from the externally-visible name change.
Comment 38 Ilmari Karonen 2008-10-27 19:28:33 UTC
(In reply to comment #36)

Sure.  We probably want to retain the NS_IMAGE constant for quite a while for the sake of compatibility, but there's no reason we shouldn't switch the core code to use NS_FILE as soon as the canonical name change is in.  Shouldn't take much more than a quick search and replace.
Comment 39 Matthias Becker 2008-10-29 20:00:51 UTC
Do we really want to manifestate the mish mash of image files and other files in one names space for eternity? That intention doensn't seem very clever to me, e.g. for reasons of accessibility.
Comment 40 Happy-melon 2008-10-29 20:09:08 UTC
Short answer: "yes".  It's never been a case of "image files and other files": since almost day one we've had video and sound and various other media in this namespace which we use for storing all such media; by unfortunate coincidence we mistakenly called it the 'Image' namespace.  There is no feasible way to separate media into separate namespaces by type (yes we could create a Sound: namespace, and a Video: namespace, and a Pdf: namespace, and a Flash: namespace and a Graph: namespace and a hundred other namespaces, but we could never reliably code for everything that might be uploaded to be handled by an extension).  So we shouldn't bother; we should continue, as we have for years, to keep all media together in one namespace.  And given that, it would be ludicrous to keep calling it the "Image:" namespace. Because that would perpetuate the myth that it's only supposed to be for images, and that the situation on most wikis is an undesirable mis mash... :D
Comment 41 Matthias Becker 2008-10-29 20:49:58 UTC
Well but images can't be used (as in seen) by not-viewing users as audios, videos (through players), textfiles oder PDFs (through screenreaders) can be used ... images are for blind people more or less useless therefore those fundamentally different types of files should be in seperate namespaces and the mish mash should be cleaned during some time up and not resolved by renaming the drawer in which they were thrown in and leave it forever a mish mash. ;-) 
Comment 42 Happy-melon 2008-10-29 21:05:54 UTC
But for deaf people, it's the audio streams that are completely useless, and vidoes marginally so... or for users with cripplingly low bandwidth, small files like PDFs and text documents are "fundamentally" different to larger media files, etc etc etc.  Which media types are "fundamentally different" from the rest depends on who you are and how you're looking at the situation.  Accessibility is not an issue that can be facilitated at this low a level; you achieve much better results by type-filtering at higher levels (eg special pages, category listings, etc).  Using namespaces to differentiate between filetypes is not hitting a nut with a sledgehammer so much as hitting a nut with a cluster bomb... :D
Comment 43 Matthias Becker 2008-10-30 07:36:31 UTC
Exactly my argument. For deaf people audios are useless but they can use images. For using audio and video files Java is needed, images can be seen without Java. So why put the images together with the rest? I believe that maybe 90 percent of the files which are at this moment in "Image:" are indeed images. So why move 90 percent of the files into another namespace? (For sorting out the 10 percent which aren't images you don't need a cluster bomb isn't needed but some intelligent "device".) 
Comment 44 Melancholie 2008-11-05 06:10:42 UTC
Just an idea that might make transition easier:

First make alias "File:" (so that it already does work) ...
... later switch default from "Image:" << to >> "File:"
Comment 45 Siebrand Mazeland 2008-11-14 11:56:20 UTC
Patch is outdated for parserTests.txt, and it looks like "Image" isn't changed to "File" as often as the parser test changes anticipate...
Comment 46 Siebrand Mazeland 2008-11-17 21:21:02 UTC
Created attachment 5532 [details]
Patch I will apply shortly

Updated patch to attachment 5394 [details]. I have 14 failing parser tests before applying the test, and the same 14 fail after. Uploading the patch just in case my commit gets reverted.
Comment 47 Siebrand Mazeland 2008-11-17 21:27:35 UTC
Renamed in r43639.
Comment 48 Ilmari Karonen 2008-11-27 20:03:57 UTC
It seems r43639 breaks [[Image:...]] (and also {{ns:Image}}) for languages other than English.  Either "Image" and "Image_talk" should be added to the global $wgNamespaceAliases (in Setup.php?), or Namespace::getCanonicalIndex() should be kluged to recognize then.
Comment 49 Ilmari Karonen 2008-11-27 21:07:27 UTC
Fixed in r44001.
Comment 50 Ilmari Karonen 2008-11-27 22:40:14 UTC
r44004 defines the new constants NS_FILE and NS_FILE_TALK, to match the new canonical names.  The old constants (NS_IMAGE and NS_IMAGE_TALK) are of course kept for compatibility.
Comment 51 Ilmari Karonen 2008-12-02 18:07:35 UTC
r44121 replaces (almost) all uses of NS_IMAGE and NS_IMAGE_TALK with NS_FILE and NS_FILE_TALK respectively within MediaWiki core.  Note that extensions intending to maintain compatibility with pre-v1.14 MediaWiki should either continue to use the old names or add the following compatibility code to their main .php file:

// The names NS_FILE and NS_FILE_TALK are new in MediaWiki v1.14
if( !defined('NS_FILE') || !defined('NS_FILE_TALK') ) {
	define('NS_FILE', NS_IMAGE);
	define('NS_FILE_TALK', NS_IMAGE_TALK);
}
Comment 52 Micke Nordin 2008-12-16 21:38:07 UTC
It seems that you could previously link to a description page of a .pdf-file on commons doing [[image:filename.pdf]], that dosent work anymore and you have to use [[media:filename.pdf]] or [[:file:filename.pdf]]/[[:image::filename.pdf]] to do the same thing now, so there are probably a couple of bad links to .pdf-files on the various wikis now.

You can see the problem on the bottom of this page:

http://sv.wikipedia.org/w/index.php?title=Wikipedia:Skriv-p%C3%A5-Wikipedia-veckan&oldid=8120457

/Micke
Comment 53 Brion Vibber 2008-12-17 00:21:12 UTC
Seems to be a problem specific to linking to Commons-hosted files, and appears to be resolved by recent updates to code -- should be fine after code deployment shortly.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links