Commons:Village pump/Archive/29

From Wikimedia Commons, the free media repository

Jump to: navigation, search
Village pump (Archives)

2004: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 2005: 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 2006: 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 2007: 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 2008: 52 | 53 | 54 |

This is an archive. Do NOT post here.
If you want to restart an old topic, copy the entire topic to the Village pump and add your post like you would normally.

Contents


April 14, 2006

Image not showing in the file page

Could anyone please advise why my uploaded Image:TW-Art059.2.gif has no image readily visible at the file page? I have reloaded but the problem still persists. It can cause problem when linking from another Wiki Site, such as Wikipedia.--Jusjih 05:02, 14 April 2006 (UTC)

I can see it just fine. Are you sure it's not a problem with your browser?--Orgullomoore 06:21, 14 April 2006 (UTC)
Which browser do you use? I usually use Mozilla FireFox and it does not show up, though it does show up with Internet Explorer.--Jusjih 13:54, 15 April 2006 (UTC)
I can see it fine using Firefox. pfctdayelise (translate?) 15:03, 15 April 2006 (UTC)
I just went back to the image file and found its URL to be [1] and my pop-up blocker thought it an advertisement (ad) to block. I just wonder why assigned /a/ad. After adjusting my pop-up blocker, it is okay to me now. Thanks for your replies.--Jusjih 16:09, 15 April 2006 (UTC)

Perhaps MediaWiki should be changed so it doesn't use /ad/ in image URLs ... User:dbenbenn 01:23, 18 April 2006 (UTC)

See bug 5402. —Ilmari Karonen 11:07, 22 April 2006 (UTC)
Which got resolved as invalid 13 minutes later. It's always such a joy interacting with the developers, trying to improve MediaWiki. And they wonder why there's a shortage of people contributing code! User:dbenbenn 15:37, 23 April 2006 (UTC)
Hmph. Oh well, I commented on it anyway. Since this is a stupid random problem that we happen to know the cause of, I really think we should fix it. I doubt it would be that hard. (At least to stop it occurring for all future uploads, if not the existing ones.) pfctdayelise (translate?) 15:50, 23 April 2006 (UTC)
Just so people don't miss this comment from brion: "Please note that sooner or later we *will* change how uploads are arranged in the filesystem and what their URLs look like." - The devs are not ignoring the problem, they are simply refusing to put in a kludge to fix it, and waiting to fix it until it can fixed neatly. I understand the frustration, but it's misplaced in this case. Also, try writing up a patch - even if it doesn't get in here, it will be useful to other Mediawiki installations that do wish to workaround the problem. JesseW 06:03, 13 May 2006 (UTC)
At first thanks a lot for your feedback JesseW. Regarding your remark we should provide patches and improvements for MediaWiki. Guess what at least some of us already do. ;-) Take a look around at Wikimedia Commons and you will notice some things that are different from other wikis (and we hope that our currently external .js add ons that only look as they would be part of the interface and our css interface hacks will be integrated in the one or other way into MediaWiki). So we do make a lot coding in order to improve the software but we can't do everything at our very own. We honestly are willing to share our feedback, time and coding skills and we also do this but it is really frustrating if you wrote a detailed bug report or even a patch (Ok it was not me that wrote this patch ;) and get a WONTFIX with a "No way" comment or at worst without explanation and no real constructive critics like "Hey I know that's a problem for you, but see as well related problem foobar.. So we need to find a way how to make it a little bit different." I don't care if people get a silent WONTFIX on poorly written bug reports or on just pointless whishlist entries like "I want MediaWiki looking after my children when I am away." I am really happy that I got this [2] bug solved so quickly. But that's the first of my bugs where it was worth the time writing that bug report. And I did spend on any of my bugs a lot of time making it as clear as possible and even trying to find out what's going on there in order to make it for devs as easy as possible. And of course there are easy to fix but yet important bugs that nobody else but the devs can solve like that one: [3]. This minor bug (yes it is newly created but has several far older bugs related to it, I wrote a new one as the general conditions in Commons on that matter have changed since quite a lot) has caused a lot of anger towards us Wikimedia Commons admins from Wikipedians and has at least taken from me a lot of time hanging around on IRC with zero result. I think for such an issue a short "Hello would you mind fixing this" on IRC would safe us all a lot of time (it is the same amount of work as if someone makes a note to me on IRC saying "Hey I have a vandal on that image please protect it"). So I really hope that we can differenciate on both sides. Wikimedia Commons admins are generally very reasonable when they make bug reports unlike other random persons. We try to differentiate as well. There are devs that care a lot about other but are just overworked by the amount of work but there are others just feeling proud that they are dev (you know what I want't say). Arnomane 10:53, 13 May 2006 (UTC)

April 15, 2006

Googling Images revisited

As has been often lamented here, Google image search pretty much ignores Commons images. I have itemized some of my observations on current status.

  • text associated contextually with an image is not found. EG search Свастика site:commons.wikimedia.org, you will see hits in text mode on the text in the Image: pages, but no hits none in google Images mode.
  • "Alt text". Google's engine does look at HTML "Alt Text"- the stuff that is displayed if you turn off display images, or if you hover the mouse over the image. You can get this with a thumbed image with a caption. But it's no dice on Commons- Search for "This is a logo" site:commons.wikimedia.org and you will see the hit on the help page for images in text mode, but no hit in images mode. External sites, no problem- Search "red eye condition is an obvious problem" and you will get a hit on the microsoft site where they used this alt-text for a tutorial example.
  • External references. Here is where I see some hits. Search on كفر جمال site:wikimedia.org yields one picture on commons, but only because it appears to be referenced on ar.wikipedia.org. Still- many of the inbound references are broken, and the number of them is a tiny fraction of what is on Commons. In fact- I see very very few good links from Commons itself- usually the hits are from wikipedia.org that I suspect have been wildcarded to match wikimedia.org.
So how does it come up with the text? It does appear to use the name of the file under certain circustances: Eg. Search "Close up yellow rose" site:wikimedia.org (with show large images only) and image search will hit on hebrew wikipedia.org that references a file of that name that exists in commons. I dunno if they have a mirror copy in that wikipedia, but there is no alt text with that phrase (its all hebrew), so it is coming from the file name, or the title of the page associated with it (also the file name).
Ok so to isolate out mirror copies of files so we know we are just talking about a commons file, I know for sure I uploaded an image onto commons not wikipedia that is used in an article. Search " "frontal depiction of the version of the sculpture " site:wikipedia.org and you will find that alt-text using Google text search, but flip into image mode and no image. Great. So search for the file name? No dice- not on wikipedia, not on wikimedia. Great. Here is a high res free image of a statue few people will see because it is way off in St. Petersburg, but it is also just as inaccessible from google.

But google is crawling it- it sees the text, sees the reference to the image...(Canova thing I think was end of feb.), but it is pretty spotty about what pictures it is picking up.

It's really a pretty bad situation. If I knew what information to include with the images to get Google to index us, I'd be happy to stick it in, but so far none of the multilingual texts I have been transcluding are going to do a dang thing as far as increasing visibility from Google is concerned. Even direct links from Wikipedia that ARE getting crawled doesn't help.

It's pretty mystifying. It would be nice to have a central page where this data can be exchanged- if there isn't one already. These scattered notes here and there in the pump archives is no way to address this important issue.

As far as I'm concerned, most of our huge mass of great images is virtually invisible to the web. That's gotta change.

-Mak 00:01, 15 April 2006 (UTC)


As far as I understand this, google does not look at image description pages, because the URL looks like the URL of an image (i.e. it has a .jpg or .png "file extension"). It apperently does not trust the MIME type returned for the page, or doesn't even try to load the page to look at the MIME type. This makes sense since some webservers may mis-report the MIME-type, an the google spider would spend some time to try to analyze several megabyte of binary garbage. Side note: google apperently does analyze pages with the .svg extension (and perhaps some others, like .ogg?).

IMHO, google should maintain a whitelist of sites that can be trusted with the mime type, and where pages having an image-type extension should be analyzed. I hope Wikimedia is big enough now for google to at least give it a thought... -- Duesentrieb(?!) 00:12, 15 April 2006 (UTC)

Google search does look at image description pages, as of about a month ago. Google's second result for "petersen graph site:commons.wikimedia.org" is Image:Petersen graph.svg. But Google image search doesn't yet know about image description pages (compare [4], which only finds a Wikipedia mirror). This might have to do with the fact that the actual image on a description page doesn't have the "title" field set. See bugzilla:5416. User:dbenbenn 00:37, 15 April 2006 (UTC)
Personally i think we should find a way to avoid using file extentions when identifying files anyway. They just mean that if a new version uses a different format it can't be uploaded under the same name meaning we either lose history or end up with multiple image pages.
As for that example you gave of google indexing a description page that one has a svg extention not gif jpeg or png. Plugwash 00:40, 15 April 2006 (UTC)
As I said, this appears to work for .svg, but not for .jpg, .png, etc-- Duesentrieb(?!) 01:13, 15 April 2006 (UTC)
Can/should we ask the Foundation to make some kind of submission to Google for us? I also find it extremely frustrating, not only is our excellent content effectively hidden, but it also hinders our work in trying to clean up the Commons (since very likely Google search is better than MediaWiki search). pfctdayelise (translate?) 02:30, 15 April 2006 (UTC)
or doesn't even try to load the page to look at the MIME type...-- Duesentrieb

I think your first thought is correct. It's not just google- it's any spider. Look at it from their perspective- it is a massive IO bound operation. We aren't talking microseconds here. New IO means your crawl cycle is extended by weeks or months. MSN search does the same- search.msn.com on "painting site:wikimedia.com" and you will get zero hits in image mode. Ok fine- in text mode you will see a hit that links to Marie Antoinette. Great- nice gallery but look at what the spider sees:

<a href="/wiki/Image:MA-Lebrun.jpg" title="Image:MA-Lebrun.jpg"><img src="http://upload.wikimedia.org/wikipedia/commons/thumb/0/00/MA-Lebrun.jpg/89px-MA-Lebrun.jpg" width="89" height="120" alt="" /></a>

What data is there to suggest that this is anything but a jpg? They have no idea what it will cost to do an IO on that site (heck- it might be a MySQL backend serving up pseudo pages for all they know), and you haven't given them any evidence to assume that it is anything but what it appears to be. So what are we expecting them to be, mind readers? No- whitelisting is bogus if what you want is for them to check mimes on everything on your site. Assume these guys are going to be aggressive minimizing IO- give them a benefit and data they can work with to implement, and we'll see the searches coming in alright.


BTW- if you want to motivate dominant companies, one useful technique is to talk to whoever the competition is first. In this case, just let it slip to google that MSN has seen your proposal and is interested in supporting you. That will put fire in their belly. Just tell them the number of images Commons since the Google program manager drone answering buckets of emails every day probably doesn't have a clue. The PM better know after the first three sentences why they will be an f'ing corporate hero for championing the idea in your email... Anyway, the win on richly annotated images is worth a little dev time on their part, especially since they have so much capitalization they are running out of things to spend money on.

Just my opinion- I'm going back to deal with that teensy hyperbole about "richly annotated". *ahem*. There seem to be one or two images here or there with no cats or references. -Mak 18:48, 15 April 2006 (UTC)


I do suggest we ask the foundation to send and official request to Google, Yahoo and maybe even MSN. We should make it clear that we are talking about more than one million media files (all wiki projects together), which are usually of rather good quality and have rich context info (at least compared to other places you find images).

As to the technical part: i'm not sure how this can be done without some special-case rules for mediawiki sites... but perhaps thei'd even do that, considering the amount of files effected. Alternatively, maybe a special attribute or something could be used in the link to hint them towards the image page. -- Duesentrieb(?!) 18:55, 15 April 2006 (UTC)

I have now asked in #wikimedia and Sj did get in contact with a person from Google. So the right people are now aware and will look into the matter the next days. Arnomane 20:45, 15 April 2006 (UTC)
I asked an old friend, Dave Alpert, to pass on the request. No word back yet... I'll let you know when I hear from him. +sj + 06:41, 21 April 2006 (UTC)

That's great. I think if a real google search developer becomes aware of it, they will be super motivated. It really is pretty laughable how egregiously bad these search failures are.

... hint them towards the image page. -- Duesentrieb(?!)

Right. And as importantly, we want them to follow the cookie crumb trail back to the high res version, which may be two indirections- a jump from a thumb to an image page version which itself is not the full file because noone's display needs an image 2000 pixels across. It won't do much good if google suddenly starts reporting tons of images, but as far as the undiscerning public is concerned they are all 120x90 (gallery size thumb versions) -Mak 07:25, 16 April 2006 (UTC)

It sure would be nice if google whitelisted us and told us where to stick likely search keywords. Trying to work with their existing proximity scheme will lead to some pretty ugly text nearby images. And ultimately it won't be effective because you will have to have a separate page for each language for each image, since all the associated text for each term is too large. For example, for a hypothetical picture with Khrushchev and Zhukov, simply enumerating all the transliterated variants of their names will mean that some terms will not be found because the number of variants is larger than the word proximity window for associated terms. You can test this by doing an image search for some terms, then look at the text nearby for additional terms. It looks like somewhere around a half dozen terms away they search will fail. OK. For some proper names there aren't that many variants eg. Paris is Paris in nearly all latin script languages. But what of common nouns? You want to search for picture of animal A with animal B, then what are we going to have to do to get the hits in other languages- create a Gallery article in every language with an instance of the picture with a lion with a water buffalo with the translated caption? Because that's what you'll have to do if there is no relief from the proximity restriction and ignoring metadata keyword fields for the image. Just my 2 cents. -Mak 01:18, 27 April 2006 (UTC)

I have talked to brion about this, and he has written an email to google. Let's hope the best.

Note: please don't archive this too soon, google people will (hopefully) be looking for this thread. -- Duesentrieb(?!) 00:22, 30 April 2006 (UTC)

Strongly recommend we request they whitelist recognize <meta> tagged keywords for our site. Our case is that we are multilingual, and it is not physically possible to collocate text strings from the 20 major world languages next to the same image. Interested parties might be interested in considering a proposed example image Image:USS West Virginia;014824.jpg. Ideally, at some future date Commons will have 20 captions for this image specifically tailored for it. The problem is, only the language with the caption at the top will get a search hit.
Secondly, it is not realistic to expect that our half million images will have captions from the 20 major languages written for them anytime soon. However, it is practical to generate text for inclusion in meta tags. This West Virginia page illustrates the kind of text that could be provided in meta tags, these text strings are drawn from the first sentences of the wikipedia articles for the two main features of this image- That it is of the Pearl harbor event, and that the ship is the USS West Virginia.
Consider the alternatives. We could find the image in a gallery article Pearl Harbor, then pick up the strings associated with the title of the interwiki article linked to the gallery article. That would get you hits on Pearl harbor in several languages, but not the USS West Virginia feature. Also, the number of target words is small- google user would not get hits on Hawaii and other associated words that are found in summary sentences but not in article titles... OK so say google's spider gets super fancy and tries to walk each interwiki link. The problem on this variation is that first sentences of wiki articles aren't ideal. Often they include dates and omit pertinent information useful for search targets. It is better than humans determine the text. Commons editors can and will refine this associated text when they see its relevance to google image search.
As a final alternate proposal, google could propose instead of meta tag recognition that google would enlarge the amount of text gatherred nearby an image from the current 8 to 10 words up to 300 words on Image: pages. Well, that kind of blows too, because just imagine what the article USS West Virginia will look like with all 20 languages for all three features (USS Tennessee is the thrid feature- its the other ship burning.) The visual clutter can be reduced somewhat if we used techniques for hiding the alternate languages at display time using for example dbenbenn's monobook thing, but some editors have the POV that this text is generic spam and shouldn't appear on the image page in any case. I don't agree with their POV, but just the same, I think there are significant numbers of Commoners with this view, and so I think the greatest support would be found for the Meta approach.
Regards, -Mak 02:52, 30 April 2006 (UTC)
Yes, it would be good if all of the (hopefully meaninfull) text on the description page is indexed and associated with the full scale image. In additioon (or as an alternative) to meta-tags, rel-attributes in the links could be used to guide the spider. -- Duesentrieb(?!) 11:09, 30 April 2006 (UTC)
Right. Possibly there will be discussions about what exactly goes in Meta fields, but it is an separate issue and can be dealt with if and when we get this support. Good luck. I repeat my suggestion you go after Yahoo, MSN- everyone and their cousin on this. I happen to favor Google, but I'd jump to any other searcher if it would do Commons searches properly. -Mak 17:27, 1 May 2006 (UTC)
Good point. +sj + 01:34, 2 May 2006 (UTC)

I assume Google Sitemaps have already been considered and rejected. Just in case, I'm mentioning them. JesseW 06:09, 13 May 2006 (UTC)

April 18, 2006

Automatic translation for page titles

I have written a patch for MediaWiki that would show a "translated" page title in the user's language - see bugzilla:5638. The translation would be based on the interlanguage link on that page, and would be displayed at the top of the page and when the page is listed in a category. This would work for category titles too, of corse. I hope that this will help to resolve the problem that the category structure is currently english only. As an example, a user with teh interface set to german would see the title of Equus caballus as Equus caballus [Hauspferd].

The code is there, now I need your support to get it into MediaWiki and enabled for Commons. So, if you do not think that this is a completely stupid idea, please voice your support here and/or vote for the bug on bugzilla. Any comments are welcome too, of corse. -- Duesentrieb(?!) 13:28, 18 April 2006 (UTC)

Must be a good thing. / Fred Chess 14:00, 18 April 2006 (UTC)
Anything that helps with the language problem (although of course the interlanguage lks will have to be good to make it work). JackyR 14:09, 18 April 2006 (UTC)
In fact, I do hope that it also has the effect of making people more aware to missing or bad interlanguage links :) -- Duesentrieb(?!) 14:30, 18 April 2006 (UTC)
Thank you Thank you. This is a very nice step towards making Commons a truly global Commons, a more welcoming environment- especially for those who stumble upon Commons through search engines and haven't a clue about wikipedia or commons is. There are huge numbers of google users who have very little experience with latin forms of words they use in their native language- eg. if you search for Red Panda pictures using Chinese, you may not have a clue that we even refer to it as a Panda, since it has a unique name in chinese. If they wanted a picture of a red panda so they knew what it looked like and all they are confronted with is latin text, well, we have not helped. Is stuffing the ballot box permitted? (Just kidding.) -Mak 03:27, 19 April 2006 (UTC)
Go ahead and vote for it - if nothing else, you will get email updates when comments are added or the status is changed. Voting is reported to not influence bug fixing though. pfctdayelise (translate?) 07:57, 19 April 2006 (UTC)
The problem is - this patch does nothing for anonymous users. It would be possible to detect their language from their browser settings (I have even submitted a patch for that a while back - bugzilla:3665), but that would kill the cache - so, it can't really be done :(
Maybe it would be possible to offer a language selectior to anons... that would also effect the cache, but only for those who actually use that box... hmm... -- Duesentrieb(?!) 18:29, 19 April 2006 (UTC)
Perhaps in the MediaWiki:Anonnotice or whateever it's called, we could put a translation of "Why not log in?" Having 50 messages of that on every page would probably be sufficiently annoying that most people would log in. pfctdayelise (translate?) 23:35, 19 April 2006 (UTC)

Another side effect is that if a significant number of visitors is logged in our chaching infrastructure doesn't work as well... So somehow the devs hope that most people never log in ;-) If we would have not the necessity login in for anon users in order to customize the language caching would still work at least a little bit, as let us say with German interface anon user 1 gets exactly the same page as anon user 2, while for logged in users it is different because of the different nick names (yes the nick names on every page are the big problem beside user customized interfaces). Just my two cent on that matter why I think a solution with a language cookie (that maybe needs to get set manually once in a drop down list in the upper right as on so many other web pages in the net) for anon users would be the best solution in the long run. Arnomane 00:35, 20 April 2006 (UTC)

Yes, a language cookie from a dropdown list would be nice - the more i think about it, the more i like it :) But please let's not confuse these two issues - while they would work hand in hand, they need to be implemented and considered separately. -- Duesentrieb(?!) 00:46, 20 April 2006 (UTC)

Ok... in case someone is still paying attention: the patch can now be tested live at the semi-official mediawiki test site: http://test.leuksman.com/ - so, play with it if you like. There are not many interwiki links there right now i guess... here is one category where you can see the effect: [5] (the language is forced to german by this link). -- Duesentrieb(?!) 00:33, 16 May 2006 (UTC)

Nice work; it works wonderfully. What is a reasonable date by which this patch could be installed on the Commons? —UED77 01:10, 16 May 2006 (UTC)
I don't know, ask brion :) In theory, days - the code is there. Some people playing with it on the test site would help i guess, so we can sort out any issues before it goes live. -- Duesentrieb(?!) 01:17, 16 May 2006 (UTC)

April 23, 2006

favicon

The favicon is broken in Safari. It displays as blank space. Dread Lord CyberSkull ✎☠ 04:04, 23 April 2006 (UTC)

I think it may be an issue with the file. I downloaded it and when I opened it in preview all I got was a transparent 16×16 image. I checked in GraphicConverter, the image data is there but the mask seems to be entirely transparent. Dread Lord CyberSkull ✎☠ 07:39, 11 May 2006 (UTC)

April 26, 2006

Photo credit accuracy

Jimmy by Kyra
Jimmy by Kyra

Did Kyra Wales actually take this image, or is it a joke? -- Zanimum 20:46, 26 April 2006 (UTC)

Why should it be a joke? Jimbo is aware of that image. It is part of the Wikimedia press kit. And if you're really interested in the background story of that phenomenal young fotographer (and want to contribute a small nice more detailed description) just say hello to Jimbo on IRC he doesn't bite. ;-) Arnomane 21:19, 26 April 2006 (UTC)
I wonder if Jimbo's daughter has fully understood GFDL :) That is, technically, it's probably a copyvio since Kyra hasn't agreed on the GFDL criteria (a 3,5 year old person can't possibly understand it). /Grillo 15:54, 1 May 2006 (UTC)
Yes, but her parents can agree on her behalf. ;) --Anathema 17:56, 8 May 2006 (UTC)

April 27, 2006

Bug with SVG display ?

Hello,

I created a SVG picture Image:Ellingham-Richardson.svg; it seems the symbol police is misinterpreted, the Δ looks like a "D" when the image is "transformed" like besides, but is looks correct when the "true" image is seen (i.e. when you click on it from the image page, see here).

See what I mean ?

Where should I make a bug report ?

Cdang 08:14, 27 April 2006 (UTC)

Sounds liek a bug with the character set the renderer is using - compare bugzilla:5694, and maybe report your problem there. -- Duesentrieb(?!) 09:53, 27 April 2006 (UTC)
Seems to be the same kind. I added a comment there. Thanks.
Cdang 10:43, 27 April 2006 (UTC)
Looking at the svg with a text editor, you are using the character D with the Windows Symbol font. When the font defined in an svg is not available, the renderer falls back to the default font. The D would be better replaced with the Unicode Δ character (see Windows character map), using the same font as with the other text. By the way, some of the text wants to be shown in "Bitstream Vera Sans", which doesn't sound too common either. If you really want to keep the special fonts, they are better converted into glyphs or paths. --para 11:00, 27 April 2006 (UTC)
OK, I'll change that. Concerning the odd font, it's the default in Inkscape, that's why. I'll change it also.
Thanks
Cdang 15:20, 27 April 2006 (UTC)

OK, now I've changed the D in symbol by the unicode character Δ, and it does not appear at all...

Cdang 07:20, 3 May 2006 (UTC)

April 28, 2006

Periodically updated graphs

If this question has been asked before, my apologies. On the Dutch Wikipedia, I'm looking after the page on Trade balance (to be found at nl:Handelsbalans). As an illustration, I have added the trade balance figures for the US and the Eurozone over the past year or so, in two simple but rather dull tables. I am thinking of replacing these tables with two graphs. My first question is: am I correct that PNG is the preferred file format for such an image? My second question is this. This graph would be updated monthly (using figures from the US goverment c.q. Eurostat). Over the years -assuming I'm going to stay around;)- this would lead to a fairly large number of files, growing by 24 per year. Is this okay or would it be preferable to stick to just two graphs? If so, do the present files have to be deleted first or can they be overwritten? Best regards, MartinD 05:12, 28 April 2006 (UTC)

If possible I would think that svg would be preferable to png for graphs. Images can be overwritten - just upload it with the same name. If you want to be able to display two versions then you would need to upload a separate image, but from what I understand of your project I don't think this is likely. Thryduulf 10:29, 28 April 2006 (UTC)
Go ahead and upload - you can consider overwriting the old version like Thryduulf suggested, or upload under a new name every time - 24 images per year is not a "large number". We had bots putting dozents of images (weather maps and stock graphs) per day on the commons - that was a problem. -- Duesentrieb(?!) 10:38, 28 April 2006 (UTC)
Thanks to both of you gentlemen. I'll have to find out if I can create SVG graphs. (Actually, just downloaded OpenOffice.org, which, if I'm correctly informed, would be able to make PNG files of graphs. No doubt I'll find some way of turning them into SVG.) Since I would be making updated versions of the same graph I wouldn't need to keep the old version. Best regards, MartinD 11:44, 28 April 2006 (UTC)
Turning pixel graphics (PNG) into vector graphics (SVG) does not work well (it's like reconstructing text from a bitmap), the reverse (rendering SVG as PNG) is easy. OpenOffice supports SVG output, I think, but there are better tools for creating SVG, like InkScape, for example. -- Duesentrieb(?!) 11:53, 28 April 2006 (UTC)
Thank you, I'll keep that in mind! MartinD 13:54, 28 April 2006 (UTC)
Update, in case anyone is wondering where the graphs are: the're still on my pc. Can't get them done they way I want it, no matter what I try. Wonderful things, computers! (Colourful language inserted here) MartinD 14:11, 9 May 2006 (UTC)

April 29, 2006

maps of the Roman Empire - can anyone help?

I don´t know if this is the correct place, but here it goes: I am mainly an user of the english-Wiki and sometimes I look "here" for good maps about the Roman Empire and I noticed that here in Wiki-commons there is both the article "Maps of the Roman Empire" and the sub-category "Maps of the Roman Empire" which do NOT corespond each other. Wouldn´t it be easier to have one or the other?, how can I merge the two? Flamarande 14:03, 29 April 2006 (UTC)

In theory article should contain selected images from category (best of the best), category - all images. --EugeneZelenko 15:06, 29 April 2006 (UTC)
Well I can only say that its a complete and utter mess in all the categories about the ancient romans, everything is completly disorganized amid an utter caos and confusion. Flamarande 15:28, 29 April 2006 (UTC)
Well, you're welcome to jump in and help us improve it. Create a model category scheme (compare to what en.wp does for ideas), get comments, implement it. We always need more volunteers here. pfctdayelise (translate?) 15:36, 29 April 2006 (UTC)
I am sorting the images in all the categories involving ancient Rome. Flamarande 15:45, 29 April 2006 (UTC)
Sorry for this "dumb" question, but I am a bit confused, if I want to sort the images (paintings, statues, etc) about a person what should I do? Should I create a new article (in case there isn´t any) or create a new category (in case there isn´t any)? I am asking this because Vercingetorix doesn´t have an article but he has a category where some pictures of him are organized. Flamarande 16:07, 29 April 2006 (UTC)
Stay with the category, then. Generally, if you are not sure, use what's already there. -- Duesentrieb(?!) 18:32, 29 April 2006 (UTC)

Categories for images with text in a certain language ?

Should all category names be in English, or could there be a category like Elektronenkonfigurations-Diagramme (Electron shell diagrams). I created the diagrams in German, but I don't know where to put them. I'm afraid Category:Electron shell diagrams might overflow when diagrams in other languages are added. --Pumbaa 18:09, 29 April 2006 (UTC)

Please use english for categories - replicating the category structure in all languages would be hell to maintain and would only make the mess worse. I'm working on an internationalization scheme for categories, see Commons:Village_pump#Automatic_translation_for_page_titles.
IF you fear that translated diagrams would flood the category, start making gallery pages, on for each diagram, or similar diagrams grouped together, in all languages. You can also make translated redirects to the gallery pages (but not to categories). -- Duesentrieb(?!) 18:31, 29 April 2006 (UTC)
Hm, in my opinion, it makes sense to create extra categories for images that are translated versions of another (and a German title for images with German text only is only logical). Why should English and German diagrams be stuffed in one big category? Somebody who is searching for this diagrams will need them for an English or for an German article, but he doesn't need them both. So make extra categories or create catscanable categories 'Image with German text' and 'Image with English text'. --::Slomox:: >< 17:02, 2 May 2006 (UTC)
Why not create an article and group them on the article???? Pleeeease do that. pfctdayelise (translate?) 04:01, 3 May 2006 (UTC)
Yes- please segment using galleries. Categories are not pigeonholes to sweep excess images into so that things are eminently tidy and eminently forgotten. -Mak 04:32, 3 May 2006 (UTC)

May 1, 2006

Main page tweaks

I am planning on moving the lang template to the bottom of the page, as well as merging the welcome and the six quicklinks boxes again. If you're an admin and you find it broken or just plain ugly, please revert. Other than that, please discuss the new scheme. Mainly, my intention is to present the most content possible without scrolling, and hoping that if users don't understand the language, they'll start scrolling down to see if the language changes or links appear. —UED77 18:52, 1 May 2006 (UTC)

I moved the language links to the top again, because the page is the main entry-point for users of all languages. So they should find immediately the content in the language appropiate for them. --::Slomox:: >< 16:08, 2 May 2006 (UTC)
the page is the main entry-point for users of all languages. This could be cured by providing a truly multilingual page, similar to http://www.wikipedia.org for URL http://www.commons.wikimedia.org . That page would mostly contain links to the different language versions of the main page, plus the logo, the picture of the day and the search form.
In order that German speakers no longer need to access the English main page, you may add "Menüs links und oben auf Deutsch schalten" links at the top of every German page, as I did with the French page. For example, have a look at this changeTeofilo 16:43, 2 May 2006 (UTC)
commons.wikimedia.org is the real entry point, because that's where our logo links to and that's where other WM projects will get to by typing the interwiki link [[commons:]]. I know it's kinda ugly, but I think probably the language links should be at the top. pfctdayelise (translate?) 03:56, 3 May 2006 (UTC)
Pfctdayelise, do you agree or disagree with the fact that http://www.wikipedia.org is not http://en.wikipedia.org/wiki/Main_page ? I do personally agree and therefore wish we had the same disctinction between an English main page and a multilingual main page here on Commons too. Teofilo 13:03, 3 May 2006 (UTC)
But the point is that there's only one Commons and there's dozens of Wikipedias. If a Farsi speaker comes to a "portal" and clicks on their language, and gets a one paragraph translation with no further links in Farsi, that's really misleading. And IMO the vast majority of our traffic is coming directly from other WM projects, not just random internet people like the Wikipedias. pfctdayelise (translate?) 09:38, 4 May 2006 (UTC)
I have removed the "Menüs links und oben auf Deutsch schalten" as it is plain ugly and just pointless as the switch is going back if you click on a further page. Please let us wait until a MediaWiki feature exists that anonymous users can permanently switch their interface language. These links with the uselang variable are only useful at the login mask. I really dislike Commons becoming a choose-language-on-every-page-but-don't-expect-usability-project instead of a media repository. That's what I always try to explain: Please let us create as much as possible multilingual content but please do not criple the whole system with ugly political correctness. Arnomane 09:18, 3 May 2006 (UTC)
pointless as the switch is going back if you click on a further page.--> As I explained, this is only one example. Of course that link has to be provided on every German page ! And please spare us your rethoric use of "usability" as a euphemism for your own egocentric needs. Usability is multilingualism. Multilingualism is usability. Teofilo 13:03, 3 May 2006 (UTC)

I have also hidden a lot of translation links at the main page. For sure they are just a further mouse click away they aren't "destroyed". :p So now only updated main pages are visible as it is simply a sign of unprofessionalism having lots of pseudo translations recommended equally to good ones (and it is also hard searching your language in a large crowd of links that just point to rubbish). Feel free to flame. I did anounce it long ago. ;-) Arnomane 11:44, 3 May 2006 (UTC)

I have reverted, of course. Commons is a wiki and a work in progress. If you do not like a page, you have to improve it not "hide" it (which has the same result as a deletion for uninformed readers) Teofilo 12:45, 3 May 2006 (UTC)
Well maybe I can't speak spanish, maybe I can't speak indonesian? Maybe I did inform you even in person about that some months ago? ;-) Maybe the pages aren't really hidden but just one further mouse click away? If someone is interested in his language he can update the pages. Simple as that. No flame wars needed just some lazy people that stop being lazy and care about their mother language. But a large link graveyard with just rubbish pseudo translations between really good ones on top is everything but true diversity of languages and does harm the translated pages severely. So there are two possibilities: Either the language menue moves at the bottom with all links embedded or we keep it on top and only upt to date translations are directly visible at the main page. Arnomane 17:09, 3 May 2006 (UTC)
I really like how you removed the ones that were updated long ago. However, I've changed my mind, and now think that it should stay on top, as I would rather have it there than have a language-independent portal. I agree we should focus on content right from the start. —UED77 17:55, 3 May 2006 (UTC)
I just made it invisible via a CSS style declared in MediaWiki:Common.css, see [6]. If I set the visible variable to anything but nothing (like eg "yes") the "hiddenStructure$text" doesn't exist and thatfor the previously "removed" entries are again visible, what I did in Main Page/All languages (see page code). However I don't like that much the current approach. It would be better having it expandable to all languages (also the "outdated") directly at the page but this requires again JavaScript which I think is not that ideal at the Main Page. By the way I really like your integration of the languages into the welcome box. I just asking myself why I didn't come to this nice solution. ;-) Arnomane 20:16, 3 May 2006 (UTC)
You could move the now English only Main Page to Main Page/en or whatever and under Main Page create a new multilingual version. --::Slomox:: >< 15:36, 3 May 2006 (UTC)
For what purpose? I don't think that a language gateway like http://www.wikipedia.org would be helpful for Commons as we want to present our content directly to newbies. Arnomane 17:12, 3 May 2006 (UTC)
Yes, this is exactly what I was thinking. Teofilo 19:01, 3 May 2006 (UTC)

May 2, 2006

Commons-actions damage Wikipedia

Ok, now that I have your attention, I'd like to discuss an issue with the deletion policy. On my home wiki, a user has been (and still is) busy for days uploading maps of Italian cities and villages. But, he's doing that on my home wiki, and not on Commons. So when I suggested him to upload to Commons, and asked why he didn't do that in the first place, he responded that he normally does that, but that he had lost trust in Commons, because he had repeatedly experienced that stuff he uploaded was deleted without any notification or explanation at all.

I find this very disturbing, because in my opinion, it is not acceptable 'not notifying' people about a deletion request. I would like to have this matter resolved, so the loss of trust can be avoided in the future, so I can convince users to upload their images to Commons again, without having to be scared that their effort is going to be deleted.

(And for the damage: 1. Other wiki's can't use the images now. 2. Someone (presumably multiple persons independently from each other) will start transferring these image to Commons at some time, off course changing the names, which I presume will lead to chaos and disorder.) --Tuvic 19:54, 2 May 2006 (UTC)

First, let me say thanks for bringing this issue to our attention here, Tuvic. We certainly don't want to damage Wikipedia, but we can't fix problems if people don't tell us.
Looking at Westermarck's upload log, I see two images he uploaded that were deleted. Image:AarlenLocatie.png and Image:BastenakenVlag.gif were both deleted because they never had any source information given. This is an example of the Commons working as it should—no Wikimedia site, not the Commons, and not the Dutch Wikipedia, is allowed to keep copyvio images. User:dbenbenn 20:54, 2 May 2006 (UTC)
I also see that some of Westermarck's other uploads don't have any source indicated. For example, Westermarck tagged Image:ArdennesFlag.gif as GFDL, without saying who made the file. User:dbenbenn 20:58, 2 May 2006 (UTC)
Similarly, Westermarck tagged Image:HauteGaronneFlag.gif as GFDL, but apparently simply stole the image from [7]. User:dbenbenn 21:00, 2 May 2006 (UTC)
I have had plenty to do with Westermarck's uploads. I'm still not satisfied with the sources and I also notice that Westermarck continues to upload images without any source. Thuresson 14:37, 6 May 2006 (UTC)
Notification of the uploader is commons policy. Notification is done on the commons. For copyvios, it's usually considered to be enough if the user has been warned about giving accurate and complete source and license info once.
Also, I'm planning a tool that will automatically post changes to images on commons (like changes in tagging, deletion requests, replacement, etc) to all wikis using it. This is not done yet, but I hope it will be up and running soon.
All that being said: people should complain here if they feel they are treated badly - otherwise, we can't do anything aboutit. In the case of Westermarck, however, I don't think there is any reason for complaint. -- Duesentrieb(?!) 21:04, 2 May 2006 (UTC)
My 2c - it seems to me that this user has not quite understood the requirements of the Commons. For example Image:LuikVlag.gif is tagged as GFDL, but stated as "public domain". And still no source is given either way. Now the Commons:First steps guide has recently undergone huge improvements, so it would be very helpful if a nl-speaker could translate these pages for their fellow wp-users. pfctdayelise (translate?) 02:47, 3 May 2006 (UTC)
Ok, I'll forward this message. If I understand this correctly, tagging and sourcing here is very strict, and should be done with extreme care and attention by the uploader, so if that is done (and the license is ok), there's no problem, is this correct?
Next: it's very hard to explain why people lose trust (no 'h') in Commons, but I guess it still has to do something with the issues in the past. So it would be good when you people made notifications or announcements to other Wikipedia's Village pumps about major deletions, of new exciting tools or so, so people would feel you're involved, and not just some outsiders sitting on a large image stack.
The tool that's going to be developed: that's a great idea, and I' already waiting with excitement for it.
About the translation: I've got the message ;-) --Tuvic 09:59, 3 May 2006 (UTC)
Hmmm, i understand very well the feelings of the user tuvic spoka about. When a user uploads usually images correctly, it is very well possible that he makes sometimes a mistake. That he forgets to put certain information in, a source, an author, some license, it's all human. Isn't it then weird that it will be deleted however the user appears to have good faith? I always hear assume good faith, but in commons it looks at least the other way around. If you don't proof every image again that you are correct, you will be warned once, your images where you forgot something will be deleted. Please remember we are humans, and humans have the nasty property to make mistakes. We do things wrong. So I would like to ask you commoners to assume good faith as well, and if someone has not completely filled in the form, put it on a deletionlist, and notice it to the uploader. If nothing has changed in about two weeks, you can delete anyway. I find some other solution. I know you have a lot of work to do, and I know my so-called solution will probably have a lot of disadvantages, but i just hope you will try to find some way to stay in contact with people. To help them if they slip away. If they forget something... Effeietsanders 11:11, 3 May 2006 (UTC)
Sure, everyone makes mistakes. But there are people who simply keep uploading all their stuff without appropriate info license info (or, worse, with wrong license info), even after they have been warned repeatedly - I don't think a notification for every single image is neccessary in such a case. It is up to the admin to check a user's uploads to see if he/she knows what to do and simply forgot something, or if the user does not understand or care about copyright oer commons policy. The "Gallery" tab on the top of the user pages can be sued to do that easily. Generally, current practice is as follows:
  • Clear copright violations are deleted on sight. The user should be informed about this, so he/she does not keep uploading copyvios. It's up to the admin to decide if the uploader has to be told about it again or if further uploads are simply deleted.
  • Images missing license and/or sorce info are tagged accordingly, and the user is informed (for each image or for a group of images). IF no appropriate info is given in 7 days (and the uploader doesnot seem to be working on that), the can be deleted without further ado.
  • If the copyright status is unclear or disputable, or the image seems unfit for the commons for some otehr reason, it is tagged and liste on Commons:Deletion requests, and the user is informed. In such a case it should be made sure that the image is orphaned in all wikis before deletion. In some cases teh image could even be copied to a "local" wiki, where it is acceptable - this is, however, normally in the responsibility of the uploader.
  • Notification is generally done on the commons only - putting a notice on the uploaders wiki (and possible all wikis that use the image) is nice, but it's not possible in general for two reasons: it takes time, and we already have a big lag in dealing with deletions and other problems. Secondly, it's very hard to deal with a wiki in a foreigh language. I can kope with Dutch well enough, but I'm not going to mess with Hebrew, Russian or Japanese wikis. The tool I described above (dubebd CommonsTicker) will hopefully resolve this to some extend. Also, it's often hard to even find out what the "home wiki" of a user is.
Regards -- Duesentrieb(?!) 11:38, 3 May 2006 (UTC)

@Effeietsanders and @Tuvic: Wikimedia Commons significantly lacks people that care about proper licensing from the beginning on. Many people upload images here and regard Wikimedia Commons not as a project but "just an image dump" and forget about their pictures and never look back until "suddenly" it did disapear. We do notify people a lot inside Commons but we can't help those people if they don't look at their user talk pages. So we do proof a lot of good will (also considering how long it usually takes until an image gets deleted here in Commons). Manual notifications in local projects simply take way to much of our time and of course it is really difficult doing so in every local project you can't speak the language of (Ever tried to write in a right to left language wiki? You won't believe how hard it is.) we are simply not able doing it manually (see Duesentriebs comment what he is working on, this will solve the issue half automated). And of course there were even complains by people that we did use "evil english" in their local project and we have to write in let us say French :p to them... So I hope that the majority of nl.wikipedians (and several other projects too) just acknowledge that we do care a lot about images but that there are many things that need improvement, that our software needs badly certain features (hey there are for sure coders in nl.wikipedia, aren't there?), that they can't sit back and hope that small brownies make everything for them with their images and that these small brownies never do anything wrong. It only works if all people work together. Arnomane 11:38, 3 May 2006 (UTC)

P..S: There is one issue were I urgently need help from nl.wikipedians. See Commons talk:Licensing#Review_of_license_templates; it is about a lot of images (and it took me much of my energy stopping that person doing everything unilaterally without giving other people a chance considering the whole thing). Arnomane 11:38, 3 May 2006 (UTC)

May 3, 2006

don't really know how to do this but....

this image Image:Phillipines.gif is spelled wrong. it should be 'Philippines.gif'....i'm used to wikipedia where i could just move the article, don't know how to do it here. could someone please fix this and change the corresponding 4 articles or so with the old spelling over on en.wikipedia.org? most appreciated, JoeSmack 03:11, 3 May 2006 (UTC)

Unfortunately, images can't be moved. The only way to fix the misspelling would be to reupload the image with the new title. User:dbenbenn 03:34, 3 May 2006 (UTC)
That's also true on wikipedia, by the way: MediaWiki does not allow images to be moved for technical reasons. -- Duesentrieb(?!) 16:02, 3 May 2006 (UTC)

Category:Moved from PL - unsorted

Simple question: Do we really need such a category ? If images were moved fromm pl wiki why put them in category? At best use pl interwiki. If we start to introduce this then every other wiki will sooner or later complain why their images are not in a category and we start to get images with 20+ cats like moved from xxx wiki. --Denniss 23:29, 3 May 2006 (UTC)

Yes, please delete and unlink, unless someone is definitely going through them soon. Images insuch a category "appear" to be categorized, but can not be found in any meaningful way. It would be better to have them uncategorized, so they would show up as thus in the tools designed to find orphans.
So, unlink and delete, and talk to the users of that category - mainly User:Julo, it seems. -- Duesentrieb(?!) 00:16, 4 May 2006 (UTC)
I think there was a discussion here a while ago where this category was suggested. The idea was that PL users or others could go through the category to help sort these. Duesentrieb, what if we delete the category but don't unlink it? Can your tools show an image that's only in red-categories as uncategorized? User:dbenbenn 03:14, 4 May 2006 (UTC)
Exactly, the idea was that users from PL can easily find the moved images and categorise them. The 'moved from PL' category is not meant to stick to the images forever: it is always to be replaced by other appropriate category. It's just a working space: sometimes the knowledge of Polish and of the context is required to categorise the images properly.
If it really goes against some rules or practices here, I'll remove the category with the bot. However, let's wait a day or two: there is at least one user who is interested in sorting some of these images, let's not make it more difficult for him. I'll remove the category after he's done.
I understand then that the right practice is to leave the images uncategorised?
tsca @ 10:06, 4 May 2006 (UTC)
@dbenbenn: no. a category "exists" in the database when it is used. If the categorie has a "header text" is not important for that - and additionaly check for that would be possible, but would make things more complex and slower.
Okay. I understand that. But it does expose a flaw in your tool: if an image is only in red-categories, it's no better than being in no category at all. For example, Image:First ladies.jpg is in 2 copyright categories, but all the other categories are red links. User:dbenbenn 04:15, 5 May 2006 (UTC)
@tsca: Well, there seem to be a lot of images that have been hanging around in that category for months. That way, it's basically a "black hole" that swallows images... no one is going to find them there, but they do not show up as orphans either. A workable compromise (admittedly tailored for my tools) would be to make a list of images from PL-WP that are pending categorization - that list must be outside the main namespace - I would suggest the User: oder Commons: namespace (maybe a WikiProject?). That way, they can be found by people interested to categorized them, but would still show up as "orphans" by the definition I use for my tools. There should also be some instructions about categorization, names of people involved in the project, and maybe a link to CommonSense there. I.e. it should be converted from a dumping ground into the working list of an active project
So, what do you think? -- Duesentrieb(?!) 10:16, 4 May 2006 (UTC)

We've discussed it on irc, the category will be removed and the images will be available in a gallery at Commons:Bar/Do posortowania. tsca @ 10:36, 4 May 2006 (UTC)

May 4, 2006

en.wp considering automatic upload to Commons

The interproject communication is just fantastic. :P I forwarded part of the correspondence to the commons-l mailing list, which any interested party is welcome to join. Wikien-l is discussing it here: http://mail.wikimedia.org/pipermail/wikien-l/2006-May/thread.html

Essentially I welcome the proposal, with the following caveats:

  • a global "you have new messages" system would be welcome (assuming we have a universal login) to stop people's outrage at not being notified before their images are deleted
  • some extra hands from en.wp (and any other project that does this) would be more than welcome as well - especially for non-English projects to act as a language "contact point" for other admins
  • some requirement or at least hints on categories should be considered almost mandatory.

--pfctdayelise (translate?) 10:02, 4 May 2006 (UTC)

Reading the discussion on wikien, it seems they are mostly opposed to it because they don't think we could handle the extra bad traffic. Probably they are right (since we can't really handle the current bad traffic ;)). But then they can't handle the current bad traffic either. So eh. MarkGallagher makes the excellent point that the consequences of a bad upload being missed are worse here than in en.wp, because here you might have to unlink a copyvio from dozens of projects (or even three is enough to be a pain), whereas if it's uploaded to en.wp it's much more "contained". pfctdayelise (translate?) 10:12, 4 May 2006 (UTC)
Hm... maybe we should have a system of "upload patrolling"? edit patrolling did not work too well (at least on teh de:wp), but I belive it could work for uploads. What do you think? -- Duesentrieb(?!) 10:20, 4 May 2006 (UTC)
Do you mean actually enabling the Mediawiki patrol system, or an informal "RC patrol" type group? At any rate, I don't think there are enough regular dedicated eyes on the sight for either system to fully work. pfctdayelise (translate?) 10:23, 4 May 2006 (UTC)
What I mean is a modified version of the Mediawiki patrol system, just for uploads. I hope it can increase the number of eyes on the issue. Also, I think we should advertize to use my Gallery tool instead of the Newimages page for monitoring uploads - it shows tagging and image use inline, without teh need to load the description page to check. It also highlites (some) problem cases automatically. Here is a link:
annotated gallery of recent uploads
Note that it's set to only show uploads until 12 hours ago, to give people time to edit the description page and/or link the image after upload. Both (the gallery and the patrol flags) work best in association with a loose project-style association of people doing the patrolling, of corse. -- Duesentrieb(?!) 11:01, 4 May 2006 (UTC)
Two things: one, when there's serious lag, you should instruct people to go back to Special:Newimages. Two, the useful thing of the Mediawiki patrol is that you can mark off edits as have been 'checked', which stops people duplicating each other's work unnecessarily. It also makes it clearer what has slipped through. Can your system indicate this somehow? pfctdayelise (translate?) 11:38, 4 May 2006 (UTC)
Could be added (both: a hint when lagged and flagging). Also, I would prefer a counter to a simple flags... four eyes see more than two... -- Duesentrieb(?!) 11:52, 4 May 2006 (UTC)
Thinking about it, the flagging should be done inside mediawiki - I could provide an interface for it thouhg. Also, it would be even better to be able to see who has reviewed an image. -- Duesentrieb(?!) 12:42, 4 May 2006 (UTC)

Pages moves

Just to leave a little note in here: Pages moves are restricted for newbies on Commons from now on – as it is already the case on several other Wikimedia projects. After currect move vandalism especially regarding user pages and some blocked users (see log), I've asked Tim for such a restriction today. Greetings --:Bdk: 13:33, 4 May 2006 (UTC)

How old does their account have to be? Is it 4 days, the same as image re-uploads? pfctdayelise (translate?) 16:29, 4 May 2006 (UTC)
yes -- Duesentrieb(?!) 17:18, 4 May 2006 (UTC)
What error message will new users trying to move pages get? MediaWiki:Movenologintext or MediaWiki:Fileexists-forbidden or something else? We need like MediaWiki:Accounttoonew. pfctdayelise (translate?) 17:57, 4 May 2006 (UTC)
Point in question... the vandal has a habit of creating usernames and using them several days later... Perhaps we should require some activity prior to page moves too? Not sure if that's feasable. Cary "Bastique" Bass parler voir 18:03, 4 May 2006 (UTC)
My understanding is that restrictions like this are only intended to stop low-level vandals. People intent on vandalism will find a way around whatever restrictions we make. pfctdayelise (translate?) 05:39, 7 May 2006 (UTC)

Files with bad OGG encoding

Here is a list of files that have the ogg extension, but have not been recognized as vorbis or theora encoded.

Some are probably Xvid/DivX videos, or MP3 audio, or they are not ogg at all (the mime type check is weak for ogg) - or they are simply broken. Please have a look at those files, talk to the uploader, re-encode, list for deletion, as you see fit. IMHO, we should only have ogg files on commons that use truely free encodings (i.e. not mpeg, avi, etc). -- Duesentrieb(?!) 17:18, 4 May 2006 (UTC)

Mispelled Category

All the items in Category:Geneology should be moved to Category:Genealogy. Cary "Bastique" Bass parler voir 19:23, 4 May 2006 (UTC)

I made it a {{category redirect}}. Now User:Orgullobot should automatically transfer all the images to the correct spelling. User:dbenbenn 19:37, 4 May 2006 (UTC)

May 5, 2006

New look of search page

I was just wondering how to improve the search mask and as there was a better one available at Commons:Searching that obviously not very much people do regularly use (as it is simply not prominently linked in the interface) I was thinking why not merging it with Special:Search and thus improving our search mask for all users and reducing duplications at the same time. So I just merged it into MediaWiki:Searchresulttext (strange name for a string displayed above the search bar by the way ;). In case you haven't set your interface to english just click at this link in order to see it in action [8]. What do you think? If you other admins like it just adapt the usual /lang-code sub page so that you have the same in your language (but be carfully doing so you can easily mix up the whole interface if you forgot to close one div ;-). Arnomane 01:11, 5 May 2006 (UTC)

Does andybody know a good external image search engine that does index our image pages currently, because I want to add one into MediaWiki:Searchresulttext (because Wikimedia Commons google image sarch still doesn't work I have removed it). Arnomane 08:44, 5 May 2006 (UTC)

Yes, the one I wrote :) Please try out MediaSearch. The interface is still clunky, and the search is not yet using the Commons:Tag categories, but it already works pretty well and I would like to get some feedback. Note, however that it does not index the description text: search is done primarily by category, and can be filtered by file size, resolution, license status, media type, etc. So, please try it out! -- Duesentrieb(?!) 08:53, 5 May 2006 (UTC)
Ah cool that it progresses so nicely. I hesitated to link yours without your prior approval. ;-) Arnomane 09:04, 5 May 2006 (UTC)
I too would prefer if some people here would first try it out and give some feedback. The earch queries are also quite complex and can put considerable load on the toolserver. I will probably have to optimize then first, and maybe even throttle the query page, so it does not kill the tool server. -- Duesentrieb(?!)
Hm I have linked it now. So please inmediatly remove it in