Last modified: 2011-01-25 01:15:40 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.
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.
See also Bug 1880: "Interface for uploaded audio media".
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...)
(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
(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.
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.
*** Bug 2890 has been marked as a duplicate of this bug. ***
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]]?
(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)
This bug has been fixed in the wikidata branch.
Since that hasn't been applied to HEAD quite yet, reopening.
(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:".
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.
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.
(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]]
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.
*** Bug 6152 has been marked as a duplicate of this bug. ***
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?
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.
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?
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.
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.
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.
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.
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 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.
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?
(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.
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!
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?)
(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.
(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?
(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*.
(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?
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".
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...
(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.
(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.
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.
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
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. ;-)
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
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".)
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:"
Patch is outdated for parserTests.txt, and it looks like "Image" isn't changed to "File" as often as the parser test changes anticipate...
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.
Renamed in r43639.
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.
Fixed in r44001.
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.
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); }
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
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.
