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.

michael wrote:

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

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

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

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.

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.

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

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

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)

avarab wrote:

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.

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.

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

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.

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

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?

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.

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?

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

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.

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.

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?

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.

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?

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.

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

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

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

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

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.

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

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

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

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

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

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

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

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

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.