Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Important discussion pages (index)
Gnome User Speech.svg


Welcome to the Village pump proposals section[edit]

This Wikimedia Commons page is used for making proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Commons:Village pump, which handles community-wide discussion of all kinds. Discussions here should be of wide interest; those which are more specific may be moved to the main Village Pump, with a note left here. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. For old discussions, see the Archive. Recent sections with no replies for 14 days may be archived.

  • If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing please do not comment here. It is a waste of your time. One of Wikimedia Commons' basic principles is: "Only free content is allowed." This is just a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  • Have you read the FAQ?
  • For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump.
  • For translation requests, please post at Commons:Requests for translation.
  • For photograph requests, please post at Commons:Picture requests.
Start a new discussion


Massive deletion requests[edit]

I've recently had a very unpleasant experience with the undeletion request process here, giving my opinion against the indiscriminate mass culling of images, as appears now to be a trend. Mass deletion requests should not be allowed because they do not allow individual images of be debated on their own merits, and many educational and in-scope images are being indiscriminately deleted. Better efforts are needed to properly categorize images, and mass deletion nominations to cull over-populated generic categories is resulting in the loss of many educational and in-scope images. Dolovis (talk) 03:28, 29 June 2014 (UTC)

Mass deletion requests are supported in our deletion policy, and that's not about to change, at least not until we start throttling uploads. We simply don't have enough volunteers to deal with batch uploads of copyright violations by sockpuppeteers one by one. And for many uploads, it makes absolutely no sense to pretend they exist in a vacuum without the context of other uploads by the same user. Consider Commons:Deletion requests/Files uploaded by Hoteles City. Obviously, the uploader can't be named Carlos Hahn, Salvador Mariña Coy and Oscar Zarate, which calls all of the uploader's authorship claims into question. But if, as you suggest, we refuse to look at the big picture, one claim is as likely as the next. LX (talk, contribs) 09:19, 29 June 2014 (UTC)

Show images in a category on Commons[edit]

It would be nice if you see all images in a category in one place by clicking a link saying Show Images in Category. You should be able to choose between images on all levels and images on top level only. Images should be shown 100 at a time with a link to the next 100 divided in subcategories. Soerfm (talk) 11:45, 30 June 2014 (UTC)

I'm not sure what exactly you have in mind, but it sounds a bit like bugzilla:43424. LX (talk, contribs) 12:24, 30 June 2014 (UTC)

Automatic redirects[edit]

On Wikipedia, you are automatically redirected to the right article if you hit on a redirect. Here, you are taken to the redirect page and have to hit the link which leads you to the intended page. Why not follow the example of WP? It's a much better system. --Jonund (talk) 09:41, 4 July 2014 (UTC)

In Commons the #REDIRECT[[foo]] magic word works exactly in the same way as in “Wikipedia” — while I guess that you mean the English Wikipedia for the latter, all wikis powered by Mediawiki, I believe, work the same way in this regard. -- Tuválkin 10:35, 4 July 2014 (UTC)
Perhaps Jonund followed ?redirect=no link and then wondered. Jonund, please provide us with an example. -- Rillke(q?) 14:03, 4 July 2014 (UTC)
More likely, Jonund visited a category tagged with {{Category redirect}}. There's a en:Template:Category redirect at the English Wikipedia as well (and corresponding templates on most other language editions as a workaround for bugzilla:3311), but I guess people are more likely to encounter categories here on Commons than on other projects. LX (talk, contribs) 16:25, 4 July 2014 (UTC)
Yes, the pages are tagged with {{Category redirect}}, for instance Category:Polar bears and Category:Pine. It's the case with almost all categories about animals and plants, because they are generally identified by their Latin names. --Jonund (talk) 18:32, 4 July 2014 (UTC)
So there is nothing we can do about the inconvenience with having to click on category redirects? --Jonund (talk) 17:05, 7 July 2014 (UTC)
Now that bots automatically move files tagged with category redirect, why should they not just be turned into #REDIRECTs (with {{category redirect}} as a hidden template) instead of the current notice? Thanks. Mike Peel (talk) 19:02, 7 July 2014 (UTC)

Support for OpenDocument file format upload[edit]

Upload of OpenDocument files has historically been disabled because of security concerns. Per the discussions in bugzilla:2089, it has been established that these have all been cleared.

as Nemo notes on Bugzilla, support for OpenDocument upload has been repeatedly discussed as over the years, eg in Commons_talk:File_types/Archive_1, and Commons:Project scope/Allowable file types already defines them as “theoretically permissible” (under the same provisions as PDFs and DjVus).

I therefore open this section to make clear the community consensus of allowing upload of OpenDocument (ODT, ODS, ODP, ODG) files.

Further steps would be:

Thanks, Jean-Fred (talk) 14:02, 6 July 2014 (UTC)

  • Pictogram voting question.svg Question Having quickly read through the long bugzilla ticket, before getting swept away in a tide of support, could we have an explanation added here as to how the WMF will implement an ODF validator for all ODF uploads before they are released into production (or preferably provide a link to a working test version) so that we can test if, say, exports from current versions of Microsoft Office are in a valid standard of ODF rather than some weird local variation of it? -- (talk) 14:14, 6 July 2014 (UTC)
The standard implementation of ODF is OpenOffice.org/LibreOffice still. We should encourage the use of free standards. MS has chosen to take a different path, as usual, so it cannot be a showstopper for us neither.--Aschmidt (talk) 16:49, 6 July 2014 (UTC)
I'm not quite sure what this means and the bugzilla discussion was inconclusive. Do you believe that our contributors will find uploads of their Microsoft ODF getting rejected or will the Commons wiki not be aware of the difference between open standard compliant files and non-compliant files? -- (talk) 18:34, 6 July 2014 (UTC)
@Bawolff: Do you know or should I test? -- Rillke(q?) 20:54, 6 July 2014 (UTC)
Dear Fæ, please do not confound ODF with Microsoft's w:en:Office Open XML. We speak about the former here. ODF is an exchange format, which Office Open XML is not.--Aschmidt (talk) 22:16, 6 July 2014 (UTC)
Sure, however these sorts of clarifications should be part of this proposal in plain English so that everyone knows what they are supporting. Presumably you are writing with knowledge of the specification that is to be applied to this new Commons ODF feature. Where is this detail defined so that I can read through it (for example a functional definition of how ODT, ODS, ODP and ODG formats will be displayed so that they are usable and meaningfully viewable on Commons)? -- (talk) 22:28, 6 July 2014 (UTC)
I do not know what exactly is in the pipeline from the technical point of view for Commons. I have only drawn the line between ODF and OOXML so as to make it clear that if the proposal is accepted this has nothing to do with Microsoft formats whatsoever. It is about an open standard that is quite acceptable.--Aschmidt (talk) 22:37, 6 July 2014 (UTC)
MS Word also supports writing odt but I doubt it is fully standard-compliant or they interpret standards in a way rendering tools won't. -- Rillke(q?) 11:33, 7 July 2014 (UTC)
Symbol oppose vote.svg Oppose I see too many open questions here to support the current proposal as worded. Some ODF documents would be great and are effectively an extension of other formats we support, while others would need constraints defining or be rejected altogether. The bugzilla ticket referenced specifies none of this functionality.
For example although I can imagine what ODP files would look like on Commons (like presentations uploaded in PDF), I have no idea how ODS files (spreadsheets) would be displayed, especially when including multiple work sheets. In fact I would rather we reject ODS as a format as they would be outside of the current definition of Commons scope. It would be better to supply an easy tool to convert ODS or Google Spreadsheets to uploadable wikitables rather than burying the data in haphazard formats and with possibly browser-crashing embedded functions and macros. -- (talk) 07:28, 7 July 2014 (UTC)
Ok. So first off, to be clear - enabling upload is not the same as enabling inline display. Currently we don't have support for enabling inline display, although should this pass, I would like to look into using webodf maybe. But, that would be more in the longer term, for now this just allows uploads. What's being proposed here would look like foundation:File:Key_Facts_wikimedia_generic_2011.odt. No display. Allows download, but nothing pretty. I assume the primary use for such a format would be for source files (much like how XCF is used here). As for what types we reject: We reject any odt file that is a valid Java applet. The only way to get one of those files is if you're doing something malicious. We will also reject dual format files (e.g. You can make files that are both an odt file and a pdf file. We will reject those). We also ensure that the file begins (starting at byte 30) with the magic numbers mimetypeapplication/vnd.oasis.opendocument.<valid odt subtype here>. (per [1]). We do not filter any macros. Whether or not a file is appropriate for the commons community (content wise) is a social issue, not a technical one, and up to you guys to enforce. As for which specific subtypes of open document to enable - that's configurable, and should probably be discussed here. For reference the different type of open document formats available are:
  • 'chart-template' (otc)
  • 'chart' (odc)
  • 'formula-template' (otf)
  • 'formula' (odf)
  • 'graphics-template' (otg)
  • 'graphics' (odg)
  • 'image-template' (oti)
  • 'image' (odi)
  • 'presentation-template' (otp)
  • 'presentation' (odp)
  • 'spreadsheet-template' (ots)
  • 'spreadsheet' (ods)
  • 'text-template' (ott)
  • 'text-master' (otm)
  • 'text-web' (oth)
  • 'text' (odt)
The proposal as worded above includes the non-template version of the graphics, text, presentation and spreadsheet format. Bawolff (talk) 17:17, 7 July 2014 (UTC)
Thanks Bawolff, that's very informative.
The clarifications above, that the files will not be view-able on Commons (and may never be), is a major headache for verification. These formats are going to be a nightmare to do any serious copyright validation. Expecting reviewers to locally download the files (which might have unknown macros that could cause your computer to crash or endlessly loop when displaying a file, as there is no restriction or checks on macros) to see what the file is about, leads us into all sorts of undesirable material, not just copyvios, but images and text "hidden" within files and material which is illegal for reasons beyond copyright and well beyond relatively harmless Rickrolling. Personally, I would be seriously worried about downloading files of this type with unknown macros, especially from anonymous accounts that I have no experience of working with. It's exactly the same as if some random Russian/Nigerian "businessman"/"prince"/"bank officer" sent you one attached to an unsolicited email, which I would send straight to the bin. -- (talk) 06:42, 8 July 2014 (UTC)
Having no preview images does indeed sound horrible from a reviewer's point of view. Webodf with its online editing capabilities looks like a bit of an overkill to me atm. There are some tools to create preview images from odf for Linux file managers: KDE ODF Thumbbailer, ooo-thumbnailer, Gloobus preview. Maybe one of that could be used as a starting point? --El Grafo (talk) 08:47, 8 July 2014 (UTC)
  • Symbol support vote.svg JFDI, we've been waiting too long. :-) --Nemo 14:20, 6 July 2014 (UTC)
  • Symbol support vote.svg Support Indeed.--Aschmidt (talk) 14:45, 6 July 2014 (UTC)
  • Symbol support vote.svg Support Very useful. Raymond 15:33, 6 July 2014 (UTC)
  • Symbol support vote.svg Support +sqlite Boshomi (talk) 18:26, 6 July 2014 (UTC)
  • Symbol support vote.svg Support --Wvk (talk) 20:03, 6 July 2014 (UTC)
  • Symbol support vote.svg Support if, and only if we get thumbnails of the full document. Otherwise upload patrollers cannot verify the upload easily and there is a warning to re-users that these files may contain unwanted code or software. -- Rillke(q?) 20:53, 6 July 2014 (UTC)
    To be clear, thumbnailing is not happening now. Eventually maybe, but we don't have support for that as of yet. Bawolff (talk) 17:23, 7 July 2014 (UTC)
    Then, uploading these types must be at least restricted to trusted users. Whether enforced by a filter, a bot deleting stuff or more appropriately through a configuration in MediaWiki. Or we have some reliable tool that thumbnails on a Labs server and integration through a gadget or both. If not enabled at all, I guess thumbnailing these types will never appear on Multimedia-Team's roadmap. -- Rillke(q?) 09:39, 8 July 2014 (UTC)
  • Symbol support vote.svg Support People ask me from time to time to send a document, to modify or translate it, and I want them to go right ahead instead of waiting for my reply. Ziko (talk) 21:16, 6 July 2014 (UTC)
  • Symbol support vote.svg Support and Rillke's suggestions sound good. :-) --Anselmikus (talk) 22:31, 6 July 2014 (UTC)
  • Symbol support vote.svg Support -- Marcus Cyron (talk) 07:06, 7 July 2014 (UTC)
  • Symbol support vote.svg Support --Badener (talk) 10:01, 7 July 2014 (UTC)
  • Symbol support vote.svg Support -- Michael F. Schönitzer 11:22, 7 July 2014 (UTC)
  • Symbol support vote.svg Support -- sk (talk) 12:27, 7 July 2014 (UTC)
  • Pictogram voting comment.svg Comment -- not necessarily opposed, but traditionally only files with a fixed visual, audio, or audiovisual realization have been allowed on Commons. Spreadsheet files are more like abstract data than they are like a conventional type of media file... AnonMoos (talk) 12:45, 7 July 2014 (UTC)
  • Symbol support vote.svg Support in general, but Symbol oppose vote.svg Oppose at the moment. Now that we've been waiting so long for the security issuse to be resolved, we shouldn't be hasty. We should take some time to think about what we want to allow and what not and develop new guidelines (think about Commons:SCOPE).
    • Spreadsheets/ods? There might be applications for that, but see comment by AnonMoos above.
    • Text/odt? We generally don't allow text-only files (with some exceptions, see Commons:SCOPE).
    • Presentations/odp? I fear we would mostly get stuff like File:Presentation-Halorespiration.pdf – essentially useless without the creator holding a talk.
    • Drawings/odg? Probably yes as an alterative to SVG, but does it actuelly work in practice (do we have a renderer)?
    • Databases/odb? Probably not … → not covered by this proposal anyway
    • Formulae/odf? They're created in an editor that basically just converts mouse clicks to a weired TeX-dialect. I guess an odf-to-real-TeX-converter might be more useful. → not covered by this proposal anyway
See also the comments by Fæ and Rillke above. I'd like to see a test implementation first. --El Grafo (talk) 13:31, 7 July 2014 (UTC)
  • Symbol support vote.svg Support --Jörgens.Mi Talk 14:11, 7 July 2014 (UTC)
  • Symbol support vote.svg Weak support Supporting in principle, but I do have concerns about scope, similar to those of AnonMoos. Michael Barera (talk) 16:24, 7 July 2014 (UTC)
  • Symbol support vote.svg Support If the security issues are a thing of the past, then why not enable their upload here? The display aspect can be sorted out at a future point in time (as an easy option: just auto-create PDF versions and display those instead). Thanks. Mike Peel (talk) 18:57, 7 July 2014 (UTC)
  • GA candidate.svg Weak support Thorough testing is needed and if we can't/don't have the functionality like pdf (seeing all of the document by turning pages, etc) it is pretty useless and not easily checked for scope and (c) status. I don't want to have to download all those files and open them locally. --Hedwig in Washington (mail?) 03:03, 8 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose, per El Grafo, Hedwig, and . No need to turn open any flood gates if all what is flowing in is murky water we cannot even properly fathom. Some of these file types may be a good addition to Commons once reliable tools for parsing and vieweing them are developed and tested. Before that no, thank you. With MobileUploads vomiting trash in well established formats we’re already too well ranked to become the greatest garbage heap in the web (better than Imgur and other such buckets cuz no ads!), no need for more. -- Tuválkin 07:58, 8 July 2014 (UTC)
  • Symbol support vote.svg Support --Horndasch (talk) 08:00, 8 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose for now per El Grafo and Tuvalkin (will change to support for some when there are tools for checking them). Green Giant (talk) 10:26, 8 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose, sounds far too dangerous at the moment (per comments above). Shouldn't this be a RFC … ?    FDMS  4    13:26, 8 July 2014 (UTC)
    Now. | FDMS 4 | 14:43, 8 July 2014 (UTC)
  • Pictogram voting comment.svg Comment I think this will add another flood of out of scope files. We have enough of them in PDF or image formats. For example, why do we need formulas when we have TeX? --EugeneZelenko (talk) 14:19, 8 July 2014 (UTC)
  • Symbol support vote.svg Support for presentation files (.odp), since I hate uploading presentation slides in PDF form - they are so hard to modify. Many times I wished I could upload a spreadsheet (.ods) or database (.odb) file here with some metadata of batch upload, so it can be preserved for future reference, so I would Symbol support vote.svg Support those. Text files (.odt) might be out of scope, as currently defined, so I would Symbol oppose vote.svg Oppose those, unless someone can give me an example where they can be useful. Graphic files (.odg) I assume are similar to SVG files. If we can make this format to be treated exacly as SVG than I would Symbol support vote.svg Support it. Formulas (.odf) I would oppose per EugeneZelenko. --Jarekt (talk) 15:01, 8 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose if no fast and easy on-site patroling/checking of the content of such files is available. --Túrelio (talk) 18:25, 8 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose per Túrelio --Steinsplitter (talk) 19:04, 8 July 2014 (UTC)
  • I agree exactly with the clearly thought-out position of @Jarekt:. I do think that ODT uploads should be enabled, and here is my example of where one would be useful: wikisource:Assessing the accuracy and quality of Wikipedia entries compared to popular online encyclopaedias -- I was given a Microsoft Word document, but the only thing I could upload was a PDF. I think converting to ODT and uploading would be helpful to some end users, much like the ODP use case Jarek points out. -Pete F (talk) 22:04, 8 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose unless we have a possibility to check the content online. Macros seem also a problem. As per Fae above. Yann (talk) 01:37, 9 July 2014 (UTC)
    • Pictogram voting comment.svg Comment I'd would start with one and see what happens. Probably charts or presentations. Why should we host templates and formulas when we have those covered with MOL and Tex? Images don't make much sense either, since OO handles the currently hosted file formats without any problem. Allowing macros here seems pretty dangerous since we can't try them all out and we need to make at least some effort to protect our users. Maybe(!) for WMF purposes only if it makes sense, with special rights attached. Well, rather not at all. --Hedwig in Washington (mail?) 03:32, 9 July 2014 (UTC)
  • Pictogram voting question.svg Question Does anyone have reliable information on what macros can do? If they aren't filtered out and might present a security risk, that is a big concern. I do think we should support these formats at some point (all of those that are proposed here have legitimate use cases within COM:SCOPE), but it may be that we need more development before we can do that without becoming a potential virus hosting site. I don't think we need to have a thumbnailer (although it would be good to have one), as there are right now also other accepted formats that are similarly or even more "difficult" to check for compliance with Commons policies, such as everything with audio in it. darkweasel94 11:08, 9 July 2014 (UTC)
  • Symbol support vote.svg Support --ChristianSW (talk) 20:34, 9 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose This is not a technical issue but rather a change in Commons` scope. I´d like to see a more detailed discussion about the intended or unwelcome new content and about consequences for reviewing or curating the uploads before supporting this. If you want to give it a try, you might consider restricting it to a new collaboration namespace that allows "joint work in progress" instead of being a repository for educational media. (Sorry for being so conservative, but I see a tendency to open the gates further and further without a corresponding increase in resources and tools for managing the content inflow. Someday this will result in being a dumpster and not a repository) --Rudolph Buch (talk) 13:06, 10 July 2014 (UTC)
    • This isn't a change in Commons scope. We are already hosting files that were originally ODG in SVG format, files that were originally ODP in PDF format, documents that, while I can't check on this machine, might have been originally ODT, in PDF format, and I'm sure spreadsheets also have their uses, if only to show (and make editable) the data sources for a diagram created with OpenDocument spreadsheet software. Hosting PDFs without their source forms isn't very much in the spirit of free culture, which is supposed to encourage modification, and similar considerations apply to SVGs (which are harder to edit than ODGs if the original was ODG). Our scope isn't changed at all by this, this is only a technical issue. darkweasel94 13:27, 10 July 2014 (UTC)
      Note—SVG is strictly validated. They are "passive", in that they cannot contain "macros" such as responses to mouseover instructions or have embedded URLs. From the proposal here, macros will not be validated or restricted for these formats and none can therefore be considered equivalent to SVG.
Note—Commons was never intended as a repository for tables of data, nor spreadsheet functions or macros. The official policy of Project scope would have to change, it makes a specific statement that it excludes:
-- (talk) 14:07, 10 July 2014 (UTC)
(edit conflict) COM:SCOPE, first sentence says "Wikimedia Commons is a media file repository making available public domain and freely-licensed educational media content (images, sound and video clips)". And while a PDF can be seen as a sequence of images, an interactive presentation or a spreadsheet with functions allowing user interaction leaves the restraints of static content. In my eyes, this is a widening of scope. --Rudolph Buch (talk) 14:14, 10 July 2014 (UTC)
Yes, (talk · contribs), I do agree with the security/privacy considerations you're raising. Your second point appears to apply only to ODS files, not to anything else. But even ODS files aren't computer programs, in general. In the current situation, if someone creates a chart with LibreOffice Calc, and uploads it as SVG, that person is the only person who can practically make changes to it. This is not in our spirit. darkweasel94 06:31, 11 July 2014 (UTC)
I would call user created macros that execute as part of a file "computer programs". In fact I have solved some quite tricky computing issues using macros as a quick and dirty one-off solution. My understanding is that ODF supports macros of several types and on all its file format variations, not just the spreadsheet one.
The SVG point is slightly tangential, so going small... SVG files are just text files, so anyone can use a text editor to see how they work, and edit them. The "vanilla" SVG that Commons is limited to, means our files are pretty straightforward, if at times a bit boring to examine. I have editing SVG files from Commons using a text editor and for small and quick fixes, especially where you do not know what the originating tools were that created it, directly editing the text can make sense and this is most likely to keep the file size down to a minimum, as most SVG editing tools tend to add a lot of library standard stuff or make format changes that do not necessarily help the layout for the human eye. -- (talk) 05:05, 13 July 2014 (UTC)
Yes, OpenDocument files can contain computer programs, as can SVGs; if they present a security issue, files with such computer programs should be rejected. But computer programs aren't the main use for OpenDocument files (just as they aren't for SVGs). Any file format can be potentially used for files that don't fall within COM:SCOPE, but OpenDocument (all the formats we're discussing here) has significant legitimate uses within COM:SCOPE.
I'm perfectly aware how SVG works. And now please imagine that for one of the files in Category:SVG pie charts you have more recent or otherwise better data and want to edit that diagram to reflect that data. You'd need to edit the SVG nodes themselves, and would probably get an imprecise and/or bad-looking result. If you had a source ODS file for one of them, you'd open that, change the data, save the new chart, upload it, and you're done. That's certainly far more in the wiki spirit. darkweasel94 07:53, 13 July 2014 (UTC)
Yes, SVGs can contain programs, however on Commons they cannot as these files are automatically rejected. If something similar were being offered for ODF support, this issue would vanish, however that is specifically excluded from this proposal. -- (talk) 08:00, 13 July 2014 (UTC)
So it appears that we're agreeing. :) darkweasel94 09:23, 13 July 2014 (UTC)
as a point of note: pdfs support macros [2] and are allowed here (i dont know the relative power though. Googling suggests pdf macros are sandboxed unless the doc is signed. I dont know what the security model of odf formats are). SVGs also support macros, however we filter those for various reasons. Im not sure svg files can be called human readable without stretching that term. Odf formats are also xml formats like svg, just a little more complex, and zipped. (Actually an odg file is svg + some extra bits.) Bawolff (talk) 07:28, 13 July 2014 (UTC)
Bawolff -- PDF and SVG allow scripting to add limited interactivity to basically static file formats, but this is not the same thing as "macros" in the usual sense of the word. PDF scripting is fairly useless except in the context of PDF "forms" (totally irrelevant on Commons). Commons does not allow Javascript scripting of SVG files (something easily detected and rejected), but does allow SMIL animation... AnonMoos (talk) 20:05, 13 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose Why would we want to upload text files, exactly? --Jakob (talk) 22:47, 10 July 2014 (UTC)
    • For Wikisource, for one. (Wikisource often documents e.g. laws. In Austria, acts of parliament (which are {{PD-AustrianGov}}) are available, inter alia, as Microsoft Word files which would be trivial to convert to ODT.) It would be easier to transcribe them to wiki format from there than from PDF files. Another use case would be documents like those in Category:Wikimedia Foundation documents. Additionally, ODT files are only one of four formats proposed here. ODG files would be very useful because they will often be the source format for SVGs. darkweasel94 06:31, 11 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose +1--Kopiersperre (talk) 23:03, 10 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose as long as we get no previews/thumbnails of the full document without downloading. Symbol support vote.svg Support with previews and appropriate safety (e.g. automatic remove of embedded scripts/macros, ...)--Wdwd (talk) 06:49, 11 July 2014 (UTC)
  • Symbol support vote.svg Support --Impériale (talk) 21:26, 11 July 2014 (UTC)

Possible compromise: allow PDF files with embedded OpenDocument[edit]

Yesterday evening I tried uploading PDF files I had created using the LibreOffice export dialog, with the option to embed an OpenDocument file for easier editing enabled. The software didn't allow me to do that. I think allowing that would have certain advantages:

  • It would already be possible to thumbnail such files as normal PDFs.
  • People who want to only view the file would be able to do so like a normal PDF without any security/privacy problems.

So far, no one has replied to my question what exactly macros can do, and this could still be a concern. What do others think of that idea? darkweasel94 06:31, 11 July 2014 (UTC)

Support for Chemical table files[edit]

Soon, provided that there are no objections, you will be able to upload this kind of file in real chemistry notation formats allowing re-mixing and a lot more.

Commoners! Do you think allowing uploading Chemical table files would be useful? Then say yes. Because as opposed to MediaViewer WMF employees think it needs support by the community to be enabled. Here is some background information:

Support for Chemical table files is being developed under the name MolHandler. This includes upload verifications, metadata extraction, rendering and eventually a web-based editor. Metadata could be molar mass, SMILES, reactant count, …

I am currently looking for features you would find helpful as well as your opinion of what is needed to deploy MolHandler to Wikimedia Commons and therefore created a test wiki at which you can create user accounts for free. A non-exhaustive list of features is available for raking by drag&drop. Or just write here what you at least want, what you would like to see soon and what is less important to you. Looking for your questions and comments. -- Rillke(q?) 10:39, 8 July 2014 (UTC)

  1. Symbol support vote.svg Support The first time I heard this, seems very useful. User: Perhelion14:02, 8 July 2014 (UTC)
  2. Symbol strong support vote.svg Strong support yes! we need this! :) --Steinsplitter (talk) 14:12, 8 July 2014 (UTC)
  3. Pictogram voting question.svg Question Wouldn't it be better to put that into the wikicode parser, into tags like <chem></chem>, similar to how it's now possible to do that for LaTeX and LilyPond code? Just wondering. darkweasel94 14:27, 8 July 2014 (UTC)
    1. I also thought about this but see bugzilla:16491#c3 and the following comments. Given that we might want to support more formats as well as downloading, doing meta-data extraction like molecular mass, calculate pKA, a MediaHandler is the right venue, I think, if not even a special field in Wikidata.
    2. +1. I'd rather like some mark-up language supported or even created as part of our parser than enabling uploads of some such files. --BaseSat (talk) 15:59, 13 July 2014 (UTC)
  • Pictogram voting comment.svg Comment There are XML-based format for such images: w:en:Chemical Markup Language. I'm not sure about current support, but it definitely have Java-based viewer and MediaWiki extension. See also bugzilla:16491. --EugeneZelenko (talk) 15:01, 8 July 2014 (UTC)
    • There is an extension but Brion Vibber (see also comments below) was not happy with their implementation; actually no MediaWiki developer commenting in the bug was really happy. Also I would like to avoid Java as not all people have Java installed, we would have to buy a certificate for signing the applet and because JavaScript + HTML5 allows doing the same (JSMol). Yes, there are XML-based formats, specifically CML and CML is supported by the tool we are going to use for rendering. But I'd like to start it simple and for creating chemical table files, Web editors exist. You may want to give the web-editor a try on http://mol.wmflabs.org/ — it's still very simple but I guess can be extended in the future. -- Rillke(q?) 15:30, 8 July 2014 (UTC)
  • Symbol strong support vote.svg Strong support Yes yes yes! Over time we could unify the appearance of all chemical tables. Love it! --Hedwig in Washington (mail?) 18:04, 8 July 2014 (UTC)
  • Symbol strong support vote.svg Strong support Yes, this would be a great improvement. Natuur12 (talk) 18:52, 8 July 2014 (UTC)
  • Symbol strong support vote.svg Strong support - one of those things that you think did exist but apparently nobody has "invented" it yet. Green Giant (talk) 19:44, 8 July 2014 (UTC)
  • Symbol support vote.svg Support Seems like a good idea to me, although I am admittedly a complete novice in this area. Michael Barera (talk) 01:44, 9 July 2014 (UTC)
  • Symbol support vote.svg Support Yes! and then please enable formulas in 3D! --trm (talk) 09:47, 9 July 2014 (UTC)
  • Symbol support vote.svg Support Looks very useful. Raymond 11:06, 9 July 2014 (UTC)
  • Symbol support vote.svg Support --ChristianSW (talk) 20:34, 9 July 2014 (UTC)
  • Question is that a 2D or a 3D file and how was the choice made? Also is not InChi now the most supported linear form? There are Structure Diagram Generation techniques to derive beautified 2D representations from SMILES or other linear specifications. While 2D coordinates are meant for neat representation, it might be more realistic to have 3D coordinates in some cases. What about large molecules? PDB? (PS: I do understand the merits and support the idea in principle - I might be able to help with some old substructure search code if someone is interested) Shyamal (talk) 05:35, 10 July 2014 (UTC)
    • Chemical table files support 3D coordinates although most web editors just set the z-values to zero. MOL files have a table for x,y and z atom coordinates as well as a bond table, specifying which which and atomes are connected. RXN files consist of one or more molecules. Their type (reactants or products) is part of the header.
    • For 3D-Representation, I have something in mind like using JSMol 3D viewer; perhaps we can offer a fallback solution for server-side rendering (a static image) at some point but all this needs huge efforts in code-review and coding. I think a 3D image is most useful if you can touch, rotate and so on.
    • PDB seems to be a protein-specific table file. Admittedly although highly valuable it would beyond my scope here -- in the time I have. Let's give mw:Extension:PDBHandler a shot … Instances are up and running but http://pdbhandler.wmflabs.org/ is dead. @Emw, Dzahn: Proxy deleted? -- Rillke(q?) 07:20, 10 July 2014 (UTC)
Hi, yes, PDBHandler was up and running and in the late phases of code review. It uses WebGL to provide a manipulable 3D representation of proteins and other biomacromoleules. It has server-side fallback rendering to produce a static image for browsers that don't support WebGL and printed pages. I haven't worked on the project for about a year and a half, but now might be a good time to dust it off and push it through last mile of the marathon.
It seems MolHandler and PDBHandler provide better rendering for non-overlapping regions of chemistry and biochemistry. Some of my code might help with server-side rendering (which, IIRC, was the most complex part of the code). How far along is MolHandler? Emw (talk) 12:42, 10 July 2014 (UTC)
@Emw: MolHandler is running and working on http://mol.wmflabs.org/ -- so far for the basics; however there is a request on de-wp for a lot of thumbnail parameters to be added to be "compliant with their standards" so I expect some results on that in about 2 weeks. Will you revive http://pdbhandler.wmflabs.org/ ? -- Rillke(q?) 13:07, 10 July 2014 (UTC)
Rillke, I'll look into it this weekend. Emw (talk) 12:40, 11 July 2014 (UTC)
  • Symbol support vote.svg Support: Incredibly cool. Bring it on! -- Tuválkin 05:02, 11 July 2014 (UTC)
  • Symbol support vote.svg Support --Mosmas (talk) 17:07, 11 July 2014 (UTC)

Distinguishing Wikimedia Foundation staff accounts for official actions and personal use[edit]

It is proposed that Wikimedia Foundation staff members should consistently use accounts with a personally identifiable name with "WMF" appended when acting on-wiki in their capacity as staff and reserved for that purpose. This will reduce confusion when Wikimedia Commons users are dealing with a fellow member of the community or a representative of the Foundation acting with special power. Personal accounts of staff members shall be considered members of the community and shall be treated as such, including following standard processes for granting access to user rights or advanced permissions.

A proposal from the Wikimedia Commons community is not binding for the Wikimedia Foundation, however this change is intended to improve relations between our project and the Foundation and we further believe the Foundation can institute this minor change with little to no disruption of their activities, and we further ask that they consider making this a requirement not just here but at all WMF projects.

Supporting links:

-- (talk) 05:50, 13 July 2014 (UTC)

Additional links:
-- (talk) 07:51, 13 July 2014 (UTC)
surely any such proposal should be at meta. Having every wiki have different rules for staff account naming in a world with SUL, seems like it would be too confusing for staff to reasonably follow. Bawolff (talk) 06:56, 13 July 2014 (UTC)
I disagree, as this can only serve to decrease participation. If the English Wikipedia Community and the Commons Community can be shown to have the same viewpoint, then meta will doubtless follow. As can be seen in the Arbcom discussion, there have been several assertions by staff and well known Wikimedians that RFCs by the community may be dismissed by the Foundation as not meaningful, unless thousands rather than hundreds take part. In terms of numbers, having this discussion on meta makes that view more extreme as the level of participation is invariably significantly lower than if we have discussions on the largest projects instead.
By the way, for this discussion, it would seem appropriate and in the interest of transparency if WMF staff would declare their status in this discussion, rather than expecting readers to check every participant's user page for possible notes, as this is a WMF policy related proposal. You can see how this has been done in the Arbcom case linked above. -- (talk) 07:35, 13 July 2014 (UTC)
  • Support. We regularly have (newish) staff accidentially misusing their staff rights to delete photos, etc, causing mini-dramas. They should consistently use staff role accounts and, as their induction seems a bit lax, we should detect staff accounts and add notices on the top of key action pages to remind them they are required to follow staff procedures when using their staff account. John Vandenberg (chat) 10:47, 13 July 2014 (UTC)
  • Oppose I don't like red tape. Not needed. Trying to solve a problem that doesn't exist. Multichill (talk) 13:27, 13 July 2014 (UTC)
  • Symbol support vote.svg Support User: Perhelion14:15, 13 July 2014 (UTC)
  • Symbol support vote.svg Support as per Fae and Vandenberg. russavia (talk) 16:03, 13 July 2014 (UTC)
  • Symbol support vote.svg Support, per Fae and Vandenberg. I’m really surprised this is not established mandatory policy, and I’m shocked (by the example) that it is acutely necessary. -- Tuválkin 19:52, 13 July 2014 (UTC)
  • Symbol support vote.svg Support it seems there is a problem here, and more clear lines would help.--Prosfilaes (talk) 21:52, 13 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose - this is a typical topic where having local policies only makes confusion more likely to happen. Keep this discussion at meta. Also, I'm worried as this would make it harder for beginning staffers to identify themselves as WMF employees, while testing out stuff and practicing. I am in favor of clearly identifying what is an office action and what not, I just don't think this particular approach is helpful to that effect. Effeietsanders (talk) 22:11, 13 July 2014 (UTC)
    • Feel free to set up an RFC on meta, there's no harm in it. Many Commons contributors are uninterested in reading pages on meta, this RFC is intended to represent the views of this community for how staff accounts are expected to be used here. -- (talk) 22:16, 13 July 2014 (UTC)