Commons:Bugs

From Wikimedia Commons, the free media repository

Jump to: navigation, search
It's not a bug... it's a beetle!!
It's not a bug... it's a beetle!!

This is a record of bugs that significantly affect the performance or usability of the Commons. Bugs that are fixed should be removed from this list.

Note that voting for bugs does not improve the likelihood of the bug being solved, but you will receive email updates when someone comments on the bug or its status is changed.

"Advocating" for bugs is discouraged by the developers, but possible technical solutions and patches are extremely welcome.

Contents

[edit] Uploads

[edit] Images

  • bugzilla:44: Rename the "Image" namespace to "File". Contains discussion on the different purposes of using Media: or Image: to link a file (Media: is normally only used with sound files).
  • bugzilla:709: Cannot rename/move images and other media files. This is possibly one of the most wanted features. Only comment on this bug if you have a technical suggestion!
    • Maybe it could be possible to create a user-script that admin can use that would (1) saves the image and the image description page to computer or memory (2) uploads it with a new name (3) deletes the old one. / Fred Chess 11:52, 5 January 2007 (UTC)
  • bugzilla:1394: "File links" on the commons should list links from other Wikimedia wikis. Work-around: Duesentrieb's CheckUsage. While the English Wikipedia's toolserver database is still corrupt, Avatar's CheckUsage can be used for bulk-checking there.
  • bugzilla:2581: View image in several resolutions.
  • bugzilla:2606: Should be possible to delete an image description page without deleting the image.
  • bugzilla:3402: add a warning to metadata box. The bug is marked "resolved" due to the presence of MediaWiki:Metadata-help in metadata boxes. However it is currently not possible to remove metadata together for cases where it is completely wrong (typically in photos of photos - digitising very old photographs, giving a date of creation in the 2000s or something equally implausible).
  • bugzilla:3498: Image history is confusing. About the difference between the upload history (listed at the bottom of the image page) and the image page history (listed under the "history" tab like all regular pages).
  • bugzilla:4421: Image extension should not be part of the name.
  • bugzilla:6220: Creating special page to list missing files
  • bugzilla:6229: Make option to turn off metadata for certain images
  • bugzilla:6579: This will allow images to be protected while the image description page is still editable.

[edit] Image rendering problems

A surprisingly serene Bug.
A surprisingly serene Bug.

Problems with SVGs not rendering at all, or rendering incorrectly, are frequent. Here are some general tips to try:

  • If you use Adobe Illustrator editor, try opening your file in Inkscape and saving as a "plain SVG" before uploading.
  • Using rsvg-view will give you the same output as MediaWiki's rendering (in theory). This can be useful when Firefox etc render your image correctly but MediaWiki doesn't.
  • bugzilla:2888: Broken thumbnails being generated. This is especially a problem for PNGs and "progressive JPGs". Brion states: It's not the compressed size, it's the *uncompressed* size. X pixels times Y pixels times Z color depth == lots of memory. There is a 12.5mb "hard limit" for PNGs. If you have a very large file that doesn't show properly on its image page, in a gallery or category, but when you click through to the original it's fine, this could well be the bug. To force ImageMagick to redraw the thumbnail, Use ?action=purge on the image page. (If it's a Commons image, do that ON COMMONS.) You may have to do this several times. If you have a problem with SVG thumbnails that you created using Adobe Illustrator, this might be the problem. If the image is simply extremely large, uploading a "thumbnail" that rendered correctly is another way to solve this.
  • bugzilla:3083: GIFs, when resized (as thumbnail), turn into PNGs, but without changing MIME type and extension accordingly.
  • bugzilla:4688: Allowing tag Image to access SVG layers. This issue has infinite uses. We at pt: have an SVG map where we store everything, from rivers to municipalities. We could choose on the fly which ones to render.
  • bugzilla:4702: Parameterized SVGs. All the images are nearly identical except for the number printed on them. If converted to SVGs, the only difference from one image to another would be the content of a single text tag (assuming the appropriate font is embedded if necessary)... [These could] be supported by a scheme which allows users to supply parameters to SVGs using much the same syntax they use to supply them to templates.
  • bugzilla:5163: SVG Renderer. Errors in SVG rendering.
  • Bugzilla:5325: Broken rendering of arrows in SVG. Possible duplicate of the previous bug.
  • bugzilla:5402: Image URLs containing "/ad/" trigger some ad blocking filters. Although this is marked WONTFIX, it is worth listing here because it still causes problems. If you find a random image won't load no matter what you do, and all other images are fine, try to check the exact URL. If this is the problem, you need to adjust your ad blocking software. Use of this subdirectory is likely to be avoided in the future but existing affected images are not likely to be changed.
  • bugzilla:5463: SVGs rendered as "empty" images unless "action=purge"d
  • Bugzilla:5694: Greek character in .svg wrong rendered for replacement- .png
  • bugzilla:6672: EXIF orientation not used. Flickr and many common image editing software programs automatically orient images according to the metadata "Orientation". MediaWiki doesn't use this metadata to determine orientation.

[edit] Media (audio, video, documents)

[edit] Categories

  • bugzilla:167: Metadata (interwiki & category links) should be stored outside the article text. (see #In relation to other Wikimedia projects)
  • bugzilla:1211: Subcategory paging is not separate from article paging. This is a problem for very large categories (>200 members). Although you expect that all subcategories will list on the first page (if not all pages), the subcategories instead "spread out" over all the pages of the category. For example, Category:GFDL is an extremely large category. The CategoryTree shows that it has over 10 subcategories, yet only one appears on the first page. Work-arounds: Use the CatScan and CategoryTree tools.
  • bugzilla:1710: Ability to watch all articles in a category. "Watching" a category would mean you were alerted when items were added to or removed from the category, as well as when the category page itself was actually changed.
  • bugzilla:2725: View list of articles in subcategories all on one page. (Or images, say.)
  • bugzilla:3311: Automatic category redirects. Category redirect only redirected the category *itself*, but not the articles categorized in the category. If this was implemented, we would be able to have multilingual categories (at the moment we self-restrict to English only to try and avoid chaos): images placed in Category:Maus, Category:Mouse and Category:Mysz would all be available together.
  • bugzilla:3687: Media files in categories to go under their own heading. At the moment non-image media files are listed in galleries as if they were images. Since they have no image to display, they display generic symbols (see for example Category:English pronunciation). This is unuseful. This bug also has provision for having a separate "number of files in category" listing for media files, distinct from articles.
  • bugzilla:3834: Number of articles in subcategories known and showed on category page?
  • bugzilla:5346: make category redirects appear as different coloured links. For example, green. Then users would be alerted that something undesirable had happened in that category (for example, if you put an image in Category:Cars, there is no way to know without checking that it should actually be in Category:Automobiles). Temporary desirable work-around for bugzilla:3311.
  • bugzilla:6034: Special:Unusedcategories should not list category redirects
  • bugzilla:8261: Install DynamicPageList2 (DPL) for Commons. Workaround for bugzilla:1710.
  • bugzilla:8685: Support moving categories (relies on 3311, automatic category redirects)

[edit] Internationalisation

An example captcha for "smwm".
An example captcha for "smwm".
  • bugzilla:3554: Not all system messages are listed in Special:Allmessages
  • bugzilla:3665: PATCH: auto-detect interface language for anonymous users. User:Duesentrieb's proposed solution so that anonymous users can easily sign up in their language (according to their browser settings).
  • bugzilla:4998: Translation for all Mediawiki messages at Commons
  • bugzilla:5309: Localize captcha images. At the moment captcha imaegs use letters from the Roman alphabet. For people who do not speak a language that uses this kind of alphabet, captchas can be extremely confusing.
  • bugzilla:5638: show translated titles per user language, based on interlanguage links (patch included). User:Duesentrieb's partial internationalisation solution.
  • bugzilla:5925: Not all system messages are language-customizable in the Commons interface. This bug is FIXED for current setup. If you are a Wikimedia Commons admin and are unable to translate a certain interface string please check back with other Wikimedia Commons administrators and if they confirm it reopen it with a commentary containing precise information which MediaWiki-namespace page is affected.
  • bugzilla:8188: If you ever wondered why users don't get appropriate system messages although you thought that you did everything right...
  • bugzilla:8287: Enable multilingual extension in Commons. This extension just works (TM) would finally solve the i18n of our license, maintenane, whatever templates without any painfull and often not working Javascript hacks.

[edit] Galleries

[edit] Users

[edit] In relation to other Wikimedia projects

  • bugzilla:57: Single login on all wikimedia projects. The "universal login" would mean that signing up for one Wikimedia project (such as Wikipedia) would allow your account to work for all Wikimedia projects. At the moment, a Wikipedia user who wants to use the Commons has to sign up for a separate Commons account. Also under this specification would hopefully be a "universal talk page" idea, so that people would receive "new messages" notification when they received a new comment on any of their talk pages.
  • bugzilla:167: Metadata (interwiki & category links) should be stored outside the article text. Interwikis are used heavily on categories and gallery pages. Storing them outside the article text would mean that when an article is written in a new language, it only has to be added to one list, once, instead of dozens of lists dozens of times.
  • bugzilla:1394: "File links" on the commons should list links from other Wikimedia wikis. (see under #Images)
  • bugzilla:1552: Feature request: Upload to commons from Wikipedia, Wikibooks, etc.
  • bugzilla:2717: Allow explicit use of commons images when a local image has the same name. At the moment if there is a local image with the exact same name as a Commons image, the local image is always used and it is not possible to use the Commons image without renaming it (see bugzilla:709)
  • bugzilla:3283: Make upload history accompany image description from Commons. At the moment the upload history is only available by "clicking through" to the file on Commons; this makes many images with summaries like "self-made", "I release all rights", "PD-self" etc, essentially anonymous.
    • Possible alternative solution: Create a variable called {{ORIGINALUPLOADER}} or something like that, which can be inserted into the templates. / Fred Chess 15:14, 13 June 2006 (UTC) Fixed.
  • bugzilla:3712: Use more appropriate software for the Commons (other than MediaWiki)
  • bugzilla:5283: Moving media files to Commons ought to be much easier, automatic (workaround)
  • bugzilla:5995: Block local description edits for Commons images. Apparently some wikis translate image captions at their wiki's local "fake" copy, instead of putting the translation on the Commons page. Whether or not this is a desirable thing is a matter of opinion.
  • bugzilla:6909: Redlinked images shouldn't go to Special:Upload. Request for improved links between local project logs and Commons logs.

[edit] Miscellaneous

[edit] See also

  • Commons:Tools - user-created tools to help improve your Commons experience
  • Commons:Help desk - ask questions if something seems wrong, or could be improved
  • meta:InstantCommons - a proposal to allow non-Wikimedia wikis to easily access the Commons
  • meta:User:Duesentrieb/CommonsTicker - a tool that helps local projects monitor the critical changes (overwriting, deletion) to images from the Commons that their wiki uses
Retrieved from "http://commons.wikimedia.org/wiki/Commons:Bugs"
Personal tools