Rename the "Image" namespace to "File"
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: enhancement
URL: http://sourceforge.net/tracker/index.php?func=detail&aid=575284&group_id=34373&atid=411195

bzimport set Reference to bz44.
hashar created this task.Via LegacyAug 14 2004, 10:57 AM
bzimport added a comment.Via ConduitSep 9 2004, 8:13 PM

leercontainer-bugzilla wrote:

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.

bzimport added a comment.Via ConduitApr 12 2005, 10:51 PM

michael wrote:

See also Bug 1880: "Interface for uploaded audio media".

bzimport added a comment.Via ConduitApr 14 2005, 4:25 PM

avarab wrote:

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...)
bzimport added a comment.Via ConduitApr 15 2005, 7:40 PM

rowan.collins wrote:

(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

bzimport added a comment.Via ConduitApr 17 2005, 2:10 PM

leercontainer-bugzilla wrote:

(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.

bzimport added a comment.Via ConduitJul 8 2005, 2:16 AM

marius.treitz wrote:

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.

brion added a comment.Via ConduitJul 18 2005, 4:31 PM
  • Bug 2890 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitSep 30 2005, 10:53 PM

dunc_harris wrote:

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]]?

bzimport added a comment.Via ConduitOct 1 2005, 12:49 PM

rowan.collins wrote:

(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)

bzimport added a comment.Via ConduitDec 3 2005, 2:04 AM

avarab wrote:

This bug has been fixed in the wikidata branch.

brion added a comment.Via ConduitJan 12 2006, 10:40 PM

Since that hasn't been applied to HEAD quite yet, reopening.

bzimport added a comment.Via ConduitFeb 16 2006, 1:34 AM

nospam+wikimedia wrote:

(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:".

brion added a comment.Via ConduitFeb 16 2006, 2:01 AM

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.

bzimport added a comment.Via ConduitFeb 16 2006, 2:20 AM

ilyanep wrote:

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.

bzimport added a comment.Via ConduitFeb 16 2006, 10:45 AM

gangleri wrote:

(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]]

bzimport added a comment.Via ConduitFeb 16 2006, 11:10 AM

robchur wrote:

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.

brion added a comment.Via ConduitMay 31 2006, 6:47 PM
  • Bug 6152 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJun 22 2007, 12:38 AM

webmaster wrote:

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?

bzimport added a comment.Via ConduitJun 22 2007, 1:30 AM

ayg wrote:

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.

bzimport added a comment.Via ConduitDec 23 2007, 2:09 PM

robert wrote:

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?

bzimport added a comment.Via ConduitJan 30 2008, 5:58 AM

sjekjr wrote:

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.

jhsoby added a comment.Via ConduitAug 15 2008, 4:49 PM

Created attachment 5178
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.

attachment Bug_44.txt ignored as obsolete

bzimport added a comment.Via ConduitAug 15 2008, 7:04 PM

ssanbeg wrote:

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.

DanielFriesen added a comment.Via ConduitAug 15 2008, 8:36 PM

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.

bzimport added a comment.Via ConduitAug 16 2008, 4:01 AM

MediaWiki wrote:

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?

demon added a comment.Via ConduitAug 19 2008, 1:49 AM

Comment on attachment 5178
Patch to MessagesEn.php to add make image namespace into File namespace, and add Image as alias

Making patch as obsolete.

bzimport added a comment.Via ConduitSep 5 2008, 2:15 PM

b.garn wrote:

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?

bzimport added a comment.Via ConduitSep 5 2008, 2:29 PM

thogol wrote:

(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.

brion added a comment.Via ConduitOct 6 2008, 6:22 PM

Created attachment 5394
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!

attachment bug44-rename.diff ignored as obsolete

brion added a comment.Via ConduitOct 6 2008, 9:11 PM

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?)

Catrope added a comment.Via ConduitOct 7 2008, 12:58 PM

(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.

Lupo added a comment.Via ConduitOct 7 2008, 7:01 PM

(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?

brion added a comment.Via ConduitOct 7 2008, 7:04 PM

(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*.

Catrope added a comment.Via ConduitOct 7 2008, 7:47 PM

(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?

Ilmari_Karonen added a comment.Via ConduitOct 9 2008, 12:58 AM

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".

bzimport added a comment.Via ConduitOct 27 2008, 4:15 PM

happy_melon wrote:

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...

brion added a comment.Via ConduitOct 27 2008, 4:20 PM

(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.

Ilmari_Karonen added a comment.Via ConduitOct 27 2008, 7:28 PM

(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.

bzimport added a comment.Via ConduitOct 29 2008, 8:00 PM

matthiasbecker1967 wrote:

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.

bzimport added a comment.Via ConduitOct 29 2008, 8:09 PM

happy_melon wrote:

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

bzimport added a comment.Via ConduitOct 29 2008, 8:49 PM

matthiasbecker1967 wrote:

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. ;-)

bzimport added a comment.Via ConduitOct 29 2008, 9:05 PM

happy_melon wrote:

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

bzimport added a comment.Via ConduitOct 30 2008, 7:36 AM

matthiasbecker1967 wrote:

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".)

bzimport added a comment.Via ConduitNov 5 2008, 6:10 AM

Wiki.Melancholie wrote:

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:"

siebrand added a comment.Via ConduitNov 14 2008, 11:56 AM

Patch is outdated for parserTests.txt, and it looks like "Image" isn't changed to "File" as often as the parser test changes anticipate...

siebrand added a comment.Via ConduitNov 17 2008, 9:21 PM

Created attachment 5532
Patch I will apply shortly

Updated patch to attachment 5394. 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.

Attached: File-namespace.patch

siebrand added a comment.Via ConduitNov 17 2008, 9:27 PM

Renamed in r43639.

Ilmari_Karonen added a comment.Via ConduitNov 27 2008, 8:03 PM

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.

Ilmari_Karonen added a comment.Via ConduitNov 27 2008, 9:07 PM

Fixed in r44001.

Ilmari_Karonen added a comment.Via ConduitNov 27 2008, 10:40 PM

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.

Ilmari_Karonen added a comment.Via ConduitDec 2 2008, 6:07 PM

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);
}

bzimport added a comment.Via ConduitDec 16 2008, 9:38 PM

mickewiki wrote:

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

brion added a comment.Via ConduitDec 17 2008, 12:21 AM

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.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.