Commons:Bugs

From Wikimedia Commons, the free media repository

Jump to: navigation, search
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 only slightly improves 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, by posting comments on Bugzilla that effectively just say "I also want this fixed" or "This is really very important", is discouraged by the developers. It e-mails everyone watching the bug (possibly dozens of people or more) and comments can't be deleted, so lots of advocacy means it's hard to find useful info on the bug report (like "what has to be done for this to get fixed"). Possible technical solutions and patches are extremely welcome on Bugzilla.

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). Fixed.
  • 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)
      • Fixed since 2009-09-21 TheDJ (talk) 23:05, 21 September 2009 (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.

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: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: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.
    • Duplicate: bugzilla:8685: Support moving categories (relies on 3311, automatic category redirects)
  • 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:8261: Install DynamicPageList2 (DPL) for Commons. Workaround for bugzilla:1710.

[edit] Internationalisation

An example captcha for "smwm".
  • 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:5309: Localize captcha images. At the moment captcha images 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

  • bugzilla:5383: Slideshow option to complement gallery function for images
  • bugzilla:2700: Pre-save transform skips extensions using wikitext (gallery, references, pipe trick, subst, signatures)
    • Duplicate: bugzilla:13120: Signatures don't work inside galleries anymore after parser upgrade. (affects COM:QIC)

[edit] Users

[edit] In relation to other Wikimedia projects

  • 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: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:14117: Links to files included in pages in other projects by a redirect name are rendered as links to the actual names of the files at Commons. That makes file redirects less useful for internationalization.

[edit] Miscellaneous

  • Bugzilla:8738: Improve media (image) search display. Proposal for a Special:Imagesearch.
  • bugzilla:8854: Install ImportFreeImages (Flickr) extension on Commons
  • Survey : 
    Warning: unlink(/srv/org/wikimedia/survey/tmp/template_temp_090626181630.html) [function.unlink]: Permission denied in /srv/org/wikimedia/survey/common.php on line 6221

[edit] See also

Sister-projects:

Retrieved from "http://commons.wikimedia.org/wiki/Commons:Bugs"