Template talk:Information/Archive 4

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Add optional "Assessments" parameter





Code to be added (after </table>): {{{assessments|}}}

Field would only show up if an assessments parameter is passed a value (which would be {{assessments}} itself) as it appears above. This is to make sure assessments template(s) always appear after Information template. -- とある白い猫 ちぃ? 18:01, 12 April 2012 (UTC)

I do not think anything like this should be part of the template–it is an info-box, with a user-defined content. --Petrus Adamus (talk) 18:14, 12 April 2012 (UTC)
I agree with User:Petrus Adamus --Jarekt (talk) 18:59, 12 April 2012 (UTC)
You do realize, in terms of appearance nothing would change, right? The idea is to enforce assessments template be put below {{Information}}, not above. -- とある白い猫 ちぃ? 19:07, 12 April 2012 (UTC)
You can't enforce people using the argument to this template any easier than you can enforce people putting it below the Information template. I also fail to see a good reason to add it to this template. 19:13, 12 April 2012 (UTC)
Not done. Please obtain consensus before adding {{editprotected}}.
As for my opinion: I don't think this is a good idea. This template should stay as simple as possible. Multichill (talk) 21:17, 12 April 2012 (UTC)

Empty permission parameter

The documentation says that an empty permission-parameter is presented as "See below.". This does not seem to be true. --Bensin (talk) 18:30, 29 July 2012 (UTC)

It was changed after a resolution on COM:VP. The documentation must be updated. -- Rillke(q?) 18:36, 29 July 2012 (UTC)

use of "License" instead of "Permission" parameter

Lately I was doing a lot of adding of "no license" templates to images with no license, and noticed that a common mistake made by many people is the use of "License" instead of "Permission" parameter, see here. I do not know how often that happens, but I run into it few dozen times in last few weeks. I would like to propose to either add "License" as alternative name to "Permission" or at least create maintenance category to catch those cases. --Jarekt (talk) 17:00, 1 October 2012 (UTC)

I'd prefer a maintenance category or link. --Leyo 17:08, 1 October 2012 (UTC)
I'd prefer to add license as an alternative name, as it is simpler and sounds reasonable. However it has been argued that "permission" should contain things like OTRS and not the license proper (though I do not thik it makes any sense and it does not match the template doc)--Zolo (talk) 17:21, 1 October 2012 (UTC)
That actually is my point. Only OTRS should be inside the information template, but no license templates, especially if they are long. --Leyo 19:00, 1 October 2012 (UTC)
I can understand that long license templates do not look very good inside {{Information}}. But I do not think it makes sense to have the OTRS inside the template and the license out. Inside is more visible than below, so we should put more important things there. License templates are much more important to the final user than OTRS (OTRS are for maintenance only, and final readers should not have to be bothered with that)--Zolo (talk) 19:07, 1 October 2012 (UTC)

I do not think we need to debate proper placement of licenses in the image (in "permission" field or outside of the template). A lot of ink was spilled on that discussion and as a result large fractions of the images use both system. I think both systems are here to stay, no matter what anybody thinks or wishes. In the mean time I was trying to figure out what to do with images that mistakenly use "License" instead of "Permission" parameter to store licenses and as a result the license is not displayed. I will start with a maintenance category to see how many images might be affected. If number is small enough (as I hope) we can easily replace "License" with "Permission" field. --Jarekt (talk) 20:08, 2 October 2012 (UTC)

✓ Done See Category:Information template using 'License' parameter. The images will start filtering in slowly. --Jarekt (talk) 20:35, 2 October 2012 (UTC)

span class="description"

{{edit request}} Often leads to invalid HTML, HTML-Tidy them moves the span to an inner element and the mess is complete. See e.g. Template talk:Description#Inconsistent HTML tags

Therfore I suggest changing <span class="description"> to <div class="description"> which is allowed having div-children. -- Rillke(q?) 23:39, 11 November 2012 (UTC)

I do not know much about different HTML tags. Why do we even have <span class="description">, are there any programs that use those? --Jarekt (talk) 01:53, 1 February 2013 (UTC)
It's part of the emitted microformat; the suggested change won't harm that. Andy Mabbett (talk) 22:29, 1 February 2013 (UTC)

Wikilinking or External Linking for the Author Field

For this page:


I was wondering if it was reasonable to go and wikilink (or external link) for the names in the author field.

I picked a few random pages, and saw whether this was done or not.

File WikiLink External Link
File:Entrée Institut de France 23 quai de Conti.jpg Yes
File:Edificio principal, Jardín Botánico, Múnich, Alemania 2012-04-21, DD 04.JPG Yes
File:Nubes Mammatus en Yacanto, Córdoba, Argentina.JPG Yes
File:Canon EF 70-200mm F2.8 IS II USM without hood.jpg
File:Weatherreports Zugspitzplatt Bavaria Germany 20101006.jpg Yes
File:Dolphin A.JPG Yes
File:(Monte Carlo, from Fort Antoine, Monaco (Riviera)) (LOC) - The Library of Congress.jpg Yes

So I think it is reasonable to go ahead and add wikilinks or external links in the author field.

Jjjjjjjjjj (talk) 21:43, 31 January 2013 (UTC)

Has been done for this particular file:
Jjjjjjjjjj (talk) 21:52, 31 January 2013 (UTC)
Wikilinks would be preferable, but for images copied from flickr, and similar sites we often use external links. --Jarekt (talk) 01:48, 1 February 2013 (UTC)
okay, thanks for the feedback. Jjjjjjjjjj (talk) 22:15, 1 February 2013 (UTC)

Display order author/source

Shouldn't we list author before source? --  Docu  at 15:48, 2 February 2013 (UTC)

I think, we shouldn't. "Author" has narrower relation to the permission (license). Source can have closer relation to the description (both can give answer "from where" the file comes). --ŠJů (talk) 17:35, 13 February 2013 (UTC)

Uploaders are not Authors, Wikipedia is not a Source

It seems to be common that uploaders interpret themselves as sources by the act of uploading or acquiring the file, and label source={{own}} to all manner of documents clearly not created by them, even to, say, antique photographs. In a certain sense they are correct, but it helps no one that the uploader repeats that yes, they are in fact the uploader and the most recent source from viewers' point of view, and consequently fail to provide the authentic source. What is important is how and from where the uploader acquired the file. (right?)

I propose changing the template labels, or something in the upload process (in all languages) into more explicit, something that cannot be misinterpreted as "I am the source of this map done in the 16th century", or even "This file originates from my hard drive".

Another misconception that further obscures the origins of a document is mentioning Wikipedia as the source. What results is only a recursive link that points to itself. As with the file File:Einschienerp.jpg. This is only infuriatingly redundant, especially if a user wishes to know the source of a document and research for more information of it (like me, many times.)

In some cases the uploader simply doesn't exist anymore, which makes it next to impossible to get the correct information. That makes it even more important why these misconceptions should be eliminated even before the uploader presses on [Upload]. ~ Nelg (talk) 17:00, 12 February 2013 (UTC)

Symbol keep vote.svg Agree You are preach to the choir. Unfortunately there is not much we can do about it. --Jarekt (talk) 20:49, 12 February 2013 (UTC)

Broken microformat


This edit, citing this discussion, added <div class="hproduct"> and closing div at the end of the template. The addition was not mentioned in the cited discussion, and is ill advised; it causes the template to emit an incomplete hProduct microformat, when the template already emits an hCalendar microformat. The tag pair should be removed, ASAP.

The edit also removed <span class="summary" style="display:none">{{PAGENAME}}</span> , again not discussed, and that markup is, as noted in the template's documentation, required by the hCalendar microformat, and thus should be restored. Andy Mabbett (talk) 22:48, 1 February 2013 (UTC)

Over a year ago when I switched this template from wikitable to html-table, I was not intending to remove any microformat markup. I think that the most reliable way to restore those would be for someone more familiar with microformat to restore those tags in Template:Information/sandbox which I just synched with the current version of the Template:Information. Once there is a proposed new version, restoring such tags than me or other admins will have easier time modifying the template, without having to do it multiple times. --Jarekt (talk) 02:55, 2 February 2013 (UTC)
hProduct was made for people selling something while hMedia is what we want, I think. The issue is that we can't add an outer class to file pages and that the <a>-tag with rel="enclosure". An hCard (either as a template or as a preference) for each user would be also nice. I hope the last edit fixed both of the issues you raised (though the parser I used gave weird results [didn't notice the fn in hproduct]). If not, please let me know. Thanks in advance. -- Rillke(q?) 12:12, 9 May 2013 (UTC)

Examples for other_versions

Can I get an example of what to put in other_versions? I'd like File:President Bush holds Jessica McClure during the Midland Community Spirit Award Presentation in the Roosevelt Room at... - NARA - 186402.tif and File:President George H.W. Bush holds Jessica McClure in the Roosevelt Room at the White House (1989-07-19).jpg to reference each other. TJRC (talk) 04:38, 9 June 2013 (UTC)

✓ Done by someone already. --Jarekt (talk) 19:23, 9 June 2013 (UTC)

German Translation

{{Edit request}}

The term:

  • "Dieses Bild verfügt über keine Beschreibung oder es fehlen wichtige Informationen."

is not good and should be:

  • "Dieses Bild hat keine Beschreibung, oder es fehlen wichtige Informationen."


  • "Bei diesem Bild fehlen eine Beschreibung oder andere wichtige Informationen."

Reason: "verfügt über" is baroque blabla and redundant for "hat" (engl.: "has"). — Preceding unsigned comment added by (talk • contribs)

The translation is at translatewiki:MediaWiki:Wm-license-information-description-missing/de. Can a German speaker edit it, if the proposed version is better? --Jarekt (talk) 14:01, 17 June 2013 (UTC)
Related question: Do we need the second part, i.e. (in English) “This file has no description, and may be lacking other information.”? --Leyo 14:44, 17 June 2013 (UTC)
No, not really but you have to discuss this with Siebrand or Multichill. I don't want to waste my time running against walls. -- Rillke(q?) 12:35, 27 June 2013 (UTC)
✓ Done. Also, "Image" had to be replaced with "File". -- Rillke(q?) 12:35, 27 June 2013 (UTC)

Adding TemplateData information

Hello there - as part of a GSoC project, we're probably going to want to change this template to have TemplateData information in it, so we can automatically determine the information we can/should include in the UploadWizard details forms. This is part of a grander scheme to shift away from hard-coded support for Commons-specific templates and towards more configurable forms, as well as towards supporting multiple templates (so pictures and other image types could also have their own forms, in time, and artwork and books will be our first targets for expansion). If someone more experienced with this particular template wants to do the TemplateData spec, that would be great, else I'd be happy to draft it and push it once it's ready. --MarkTraceur (talk) 18:09, 11 June 2013 (UTC)

Since when is TemplateData activated here? Will we get IntelliSense soon?
But seriously, I would like to see this integrated into Template:TemplateBox instead to be messed into each template in JSON-format. Would this be possible? If, at all, please create a template/LUA module that builds the JSON. JavaScript object notation -– I love it, but I doubt that the default wiki user does. They will mess with the quotes, with Array and Object brackets. -- Rillke(q?) 19:06, 11 June 2013 (UTC)
I don't know if User:Krinkle has any plans for something like that, I guess you could ask him. For now I've put a beta version into Template:Information/sandbox/TemplateData and I'd be willing to explore how to flesh out the descriptions (I'm still not sure whether they're supposed to be wikitext, or what, but like I said I'm willing to play with it) and I think it's generally a good plan to move some of this infrastructure stuff into machine-readable formats. --MarkTraceur (talk) 19:15, 11 June 2013 (UTC)
Generally machine readable data is important and useful, yes. But adding redundant information isn't. I think a LUA module could do the job and Template:TemplateBox must be rewritten as VisualEditor will also access this data, I guess. -- Rillke(q?) 19:24, 11 June 2013 (UTC)
I copied this to {{Information}}'s documentation and did a null-edit to the template itself. API result. Ricordisamoa copied a LUA-JSON module here and I just tried it: It seems to work: {{#tag:templatedata|{{#invoke:JSON/usetest|test|description=This is a description}}}} -- Rillke(q?) 10:29, 9 July 2013 (UTC)
Helpfully, gerrit:71915 is adding an extra string type so we can represent things that are short-form text. Ideally date would be included as this type, if you wouldn't mind another update...but the patch isn't merged yet, either, so wait for it please :) --MarkTraceur (talk) 00:12, 12 July 2013 (UTC)
✓ Done -- Rillke(q?) 21:32, 17 August 2013 (UTC)

Voilà! Migration is in progress. -- Rillke(q?) 18:04, 6 August 2013 (UTC)

And now also Commons:TemplateData. -- Rillke(q?) 21:27, 17 August 2013 (UTC)

Detect missing information

I often found the word "unknown" as author or source data (eg.[1]) and this is enough to fool the template and avoid the {{Source missing}} or {{Author missing}} categorization. I'm a bot operator, so I could blank any blatant nonsense from author, data, source and description field parameters... but in my opinion we should also modify this template in order to immediately detect some obvious unacceptable values. Eg. "no", "none", "unknown", "I don't know", "foo", "empty", "nobody", "internet", "web", "?", "??", "missing". If there is enough consensus I can both prepare a modified version of this template and run the bot in order to detect and blank a broader range of nonsense data. What do you think? -- Basilicofresco (msg) 09:55, 9 September 2013 (UTC)

"Unknown" author is an legitimate statement, for many types of licenses. For example if it is {{PD-old-100}} work created in 16 century, {{Anonymous-EU}} work or {{PD-Polish}}, {{PD-GermanGov}} or many other types of works. However "Unknown" author and CC or {{PD-old-auto}} would be problematic. --Jarekt (talk) 13:16, 9 September 2013 (UTC)
For the “author” field, many variants should be replaced by {{unknown|authors}} or removed (depending on the case). There is also a lot of nonsense in the “other_versions” field. --Leyo 14:41, 9 September 2013 (UTC)

Maintenance category for pages using nonexistent parameters

In de.wikipedia, file pages using nonexistent parameters within Template:Information are categorized into a maintenance category. It is done using Module:TemplatePar. I suggest the same approach for Commons. Thoughts? --Leyo 21:51, 4 August 2013 (UTC)

I believe we can detect it, but I am afraid that we will just find another huge number of images with that issue, and than someone will have to fix them. So in other words there is no need for maintenance category if someone is not going to be working on fixing them. And we do seem to have a lot of existing maintenance categories that need emptying. Category:Media without a license: needs history check, Category:License review needed or Category:Creator template maintenance comes to mind. So many maintenance categories - so little time --Jarekt (talk) 01:31, 5 August 2013 (UTC)
There are indeed likely to be many file pages affected, but IMO such a category would provide a good starting point for semi-automatic fixes. In most of your examples, the fixes need to be done manually after careful review. I guess that there are e.g. many cases with spelling errors in parameters or “[Ll]icense” as a parameter. --Leyo 09:21, 5 August 2013 (UTC)
I created Category:Pages using Information template with incorrect parameter for the parameter errors. --Leyo 15:17, 9 September 2013 (UTC)

What about including templates transcluding Template:Information as done for Template:Book, here too? --Leyo 08:58, 30 September 2013 (UTC)

✓ Done --Jarekt (talk) 12:24, 30 September 2013 (UTC)
There are no templates in the category yet. I had fixed a few before. I'd guess that there are many user templates producing errors, but I fear that if we extended the check to the user name space, we would get lots of sandboxes and similar into the maintenance category. --Leyo 22:01, 30 September 2013 (UTC)

Parameter 1 errors

Parameter 1 errors make up a large fraction of all errors in Category:Pages using Information template with incorrect parameter. They are usually caused by an incorrect use of or missing special characters, whereas the other errors occur from spelling errors or the inadvertent use of non-defined parameters. What about adding 1= to the list of optional parameters and to create a subcategory for these errors? Category:Pages using Information template with parameter 1 errors? IMHO this splitting would facilitate fixing the errors (semi)automatically. --Leyo 15:36, 11 October 2013 (UTC)

No opposition, neither to the splitting nor to the category name? --Leyo 20:43, 14 October 2013 (UTC)
Symbol support vote.svg Support for split and GA candidate.svg Weak support for category name. I can not think of better category name, but this one might be hard to understand for people not familiar with the topic. The split will probably require changes in Lua code. may be we can detect duplicate parameters as well (like 2 conflicting authors, etc.) --Jarekt (talk) 03:01, 15 October 2013 (UTC)
What about Category:Pages using Information template with syntax errors then? What would need to be done is to add 1= to the list of allowed parameters.
According to User:PerfektesChaos (creator of Module:TemplatePar) detecting duplicate parameters is not possible in a similar way as we do with undefined parameters. --Leyo 10:27, 16 October 2013 (UTC)
Category:Pages using Information template with syntax errors would be better, I think. However I still not sure, how are you planning to implement it. My guess is that you are going to add 1= to the list of allowed parameters so we do not detect it as error, but we will add {{#if:{{{1|}}}|[[[[Category:Pages using Information template with syntax errors]]]]}} to detect it's presence? --Jarekt (talk) 11:57, 16 October 2013 (UTC)
Yes, this is my plan. Like this we would not capture empty parameters 1 caused by a duplicate pipe any longer. This may be seen as an advantage or a disadvantage. --Leyo 12:51, 16 October 2013 (UTC)
What about
{{#if:{{{1|}}}|<span style="color:red">Syntax error in [[Template:Information]]: “{{{1}}}”</span>[[Category:Pages using Information template with syntax errors]]}}
or similar? Displaying the value of parameter 1 would allow users to find the reason quicker. --Leyo 15:38, 16 October 2013 (UTC)
That sounds fine. I would suggest removing the {{#if:{{{license|}}}|...}} block at the same time. --Jarekt (talk) 15:58, 16 October 2013 (UTC)
Done, but the effect will take time to show. Unless a bot touches all files in the parent category…
There is an unwanted line break in the error message (example). One option would probably be to replace the “ ” by '' ''. Does anybody have an alternative solution? --Leyo 16:40, 16 October 2013 (UTC)

{{editprotected}} @Leyo: I think it would be better to detect empty parameter 1s (example). --Zhuyifei1999 (talk) 11:13, 21 November 2013 (UTC)

Zhuyifei1999, All empty parameter 1s as in ("{{Information|") were removed several times by me and the others, but there is always more when you check in a few days. --Jarekt (talk) 12:57, 21 November 2013 (UTC)
IMO my edit may be undone once we've cleaned up the legacy cases. But for now, it helps for (semi)automated fixing. --Leyo 13:09, 21 November 2013 (UTC)
Ok. --Zhuyifei1999 (talk) 14:45, 21 November 2013 (UTC)


Detached from section above:
Also what should we do with Category:Information template using 'License' parameter. Do we still need it as a separate category? It seems like people often add "license" instead of "Permission" (it makes much more sense for storing licenses). We could either add it as an alternative to "Permission" or remove the check since it is already done through Module:TemplatePar. Too bad about detecting duplicate parameters. --Jarekt (talk) 11:57, 16 October 2013 (UTC)

As I do not like license templates in the Permission field anyway, I would prefer not to add “License”/“license” as alternatives.
I guess that after having cleaned up the hundred legacy cases, we do not need Category:Information template using 'License' parameter anymore. --Leyo 12:51, 16 October 2013 (UTC)
I have clean them up once or twice before. It is a common error to make. I am neutral about license templates in the Permission field (although I do not use it in my uploads), however that is where many people place licenses. We are not going to change that. --Jarekt (talk) 13:49, 16 October 2013 (UTC)

How can we get rid of the 7 remaining files? I don't know why they are in this category. --Leyo 13:54, 16 October 2013 (UTC)

See Commons:Administrators'_noticeboard#File_can_not_be_edited_due_to_blacklisted_external_site --Jarekt (talk) 14:14, 16 October 2013 (UTC)

Licences for coats of arms

  • Apparently the presentation of coats of arms is free in any single wikipedia, why not in all of them at once.
  • One more aspect of this topic: Coats of arms are a kind of a logo. Recently, the copyright for logos has become stricter in Germany, due to a decision of a court of justice. So I phoned to the association of designers about the presentation of logos for presenting their bearers. The answer was that using the logo for a report on the institution or comapny, the logo has been designed for, is a case of freedom of press. Licence fees only have to be paid, if you use the logo for another desire.--Ulamm (talk) 00:39, 5 December 2013 (UTC)
That is interesting but I am afraid this might not be a right place to discuss it, since this forum is mostly to discuss technical aspects of the information template. I would try Commons:WikiProject Heraldry. As for licenses on coats of arms, my understanding is that whoever draw them is the copyright holder even if the design might be in public domain. In that respect they are different than logos. As for no license fees for logos if used to illustrate topics related to the company they were designed for. That is not good enough for the inclusion on Commons (or wikipedia), since we only take content released under free licenses, that would allow any use. See COM:LIC. --Jarekt (talk) 03:16, 5 December 2013 (UTC)
To me it is a question much wider than heraldy. Almost every company busy in production or transport has its logo. The company buys the full rights for this logo in order to use it on each item produced, or on each coach and each ticket. And WP usually presents this logo in its article on this company.--Ulamm (talk) 17:47, 5 December 2013 (UTC)
I'd suggest to move this discussion to e.g. Commons:Village pump/Copyright. --Leyo 18:03, 5 December 2013 (UTC)


Any thought of including isbn as a parameter in this template, for when books are uploaded? -Pete F (talk) 06:32, 27 December 2013 (UTC)

For books we use {{Book}} and it have ISBN. See Commons:Infoboxes--Jarekt (talk) 14:40, 27 December 2013 (UTC)


There are currently 215 files with the parameter Location in Category:Pages using Information template with incorrect parameter that are non-empty. Since the parameter is undefined, the information is not shown. Does anyone have a suggestion on how to make this information visible (e.g. adding to Description) and to do the necessary modifications in an automated way? --Leyo 01:32, 26 January 2014 (UTC)

{{Information2}} has "location" field --Jarekt (talk) 04:54, 26 January 2014 (UTC)
Sounds like a good solution to replace \{\{Information\n in these cases. Or is there any drawback? --Leyo 12:59, 26 January 2014 (UTC)
{{Information2}} is rarely used and it is unclear what is it's future. Also if something gets broken, it might be undiscovered for a long time. --Jarekt (talk) 18:49, 26 January 2014 (UTC)
An alternative would be to use Other fields, but the replacement is more complex. I don't know which option is better, but any is better than the status quo. --Leyo 21:00, 26 January 2014 (UTC)

Troubles with DATE

As soon as the Date contains not only the yyyy[-mm[-dd]] value, may be also a time, but has additionally the string (UTC) generated, the date conversion fails. The (UTC) is contained rather often. How about treating the date nevertheless? sarang사랑 09:33, 17 April 2014 (UTC)

Date is treated by {{ISOdate}} one of the most complicated and unreadable template we have. It is also very rarely touched in last 4 years, since it last maintainer user:Slomox semi-retired. The template needs to be rewritten as Module:Date but so far nobody tackled it. --Jarekt (talk) 02:20, 18 April 2014 (UTC)
@Jarekt: Why not use {{#time:}} instead? {{ISOdate}} treats only date strings in ISO format, while {{#time:}} treats both. --Zhuyifei1999 (talk) 11:41, 18 April 2014 (UTC)
@Zhuyifei1999: {{ISOdate}} shows the date in the language of the viewer and at the time the template was written only showed the date in the default language of the Commons (English?). It also had a lot of issues with some years (many before 1000) showing up incorectly. {{ISOdate}} is a giant case statement with different years and date formats being treated differently, with many calls to . Much of the complexity of {{ISOdate}} is likely no longer needed. --Jarekt (talk) 12:22, 18 April 2014 (UTC)

Thank you. I knew that the final treatment of Date is not done by Information itself, but did not look where it happens. We have skilled module writers, haven't we? They need to know about this challenge. Users often write dates in wrong formats, that can be resolved, if not corrected or tagged with an error msg. Would be nice, even if not such an urgent must. sarang사랑 10:25, 18 April 2014 (UTC)

This template at the English Wikipedia

The current version of this template at the English Wikipedia may be of interest. Sardanaphalus (talk) 19:23, 19 September 2014 (UTC)

In which sense? --Leyo 20:50, 19 September 2014 (UTC)
It uses {{navbox}} (but I don't think it's a better way). --Tacsipacsi (talk) 21:35, 19 September 2014 (UTC)
I agree. --Leyo 21:51, 19 September 2014 (UTC)
This is a template used on a LOT of file-pages and so far we keep it as bare-bones and low level as possible. I am not sure if it is required but I do not see a need to make templates more complicated unless we are trying to improve something. --Jarekt (talk) 03:45, 20 September 2014 (UTC)

Author field

That template also uses the word "Author" which is a bit confusing. In fact, we need a caption like "copyright", "credits" or some thing like that which cover all CMI. Many times "Author" != "copyright holder" != "preferred credits". So people use otherplaces to mention "actual credits"; but unfortunately MV and other tools only look on "Author" field. Off wiki applications like eol.org also look only on author field. What about renaming that field and insist people to provide "credits" there instead of many other places like "credit line", license tags, permission field, etc.? Jee 05:37, 20 September 2014 (UTC)

You may insert all captations you like with {{Information field}}. sarang사랑 10:02, 16 October 2014 (UTC)


Different Special pages for upload files offer e.g. an Information box as


where the sequence of Source= and Date= are exchanged to the latter box display. In spite to the other parameter names other_versions= is used instead of the better fitting Other versions=. Other upload pages have an even more exchanged parameter sequence. The transclusions of {{Information}} are always generated in another sequence than displayed.
Of course this is not so essential but it would be nice to have the same sequence wherever possible.
May I also suggest to generate Permission, Other versions, Other fields into the file description only if they got values, to avoid all the empty lines in the file descriptions. -- sarang사랑 10:02, 16 October 2014 (UTC)

Order of the fields do not matter and if there are several alternative names like other_versions and Other versions either one can be used. But I agree that it would be nice to always recommend the same empty template. I would go with the one used by the upload wizard. I do not like to hide unused fields, since it is more work to add them when they are needed. The only exception is Other fields which is mostly meant to be used by other templates expanding {{Information}} template and should not be shown unless really needed. One has to really know how to use that one to do it right. --Jarekt (talk) 15:28, 16 October 2014 (UTC)
Agree. Jee 15:50, 16 October 2014 (UTC)

Add identifying class

{{editprotected}} Please add fileinfotpl-type-information to the <table> classes (second line of the template)! See Commons talk:Machine-readable data#Identifying information-like templates for background. Thanks, --Tgr (WMF) (talk) 13:16, 22 October 2014 (UTC)

✓ Done --Jarekt (talk) 01:19, 24 October 2014 (UTC)

Commons:Deletion requests/Template:Uf

This discussion is of relevance for the information template, especially for automated extraction of data. There are a few open points to be clarified. --Leyo 14:07, 9 November 2014 (UTC)

As stated there, "... the upload tools & pages should offer an item to be filled with v&t information when the file to be uploaded is a SVG. Not correct using this proposed item inserts the new file in a maintenance category, so further action can occur."

Expansion request

As a consequence, we need a new optional parameter, located and displayed after the Author, to describe the creation tool and, for SVG files, the W3C-validity.
The parameter name "Creation" will be fine, also as the label in the English version that can be nationalized easily. It may also correspond with the name of the tagging template.
Such an optional parameter allows a more unique appearance of the file description, without the need of using the {{Information field}} and {incomplete, or none) home-brewn translations of the label. sarang사랑 08:48, 16 November 2014 (UTC)
  1. best solution: like {{Location}}, the tag about (SVG/graphic) creation can be coded following the Information box, and somehow it is afterwards inserted into the box.
  2. 2nd best: a new optional field like "(file} creation" allows the input of the information. It's display is located after the Author field, and the label is nationalized to the users language.
  3. 3rd best: a new optional field "Other fields 2" can be used, the information is displayed after the Author field. As a disadvantage compared against solution 2, no nationalization will occur.
  4. 4th best, without any expansion of the template, is to use Other fields 1 (where the information high above is too prominent) or Other fields (where the information far below disappears after long permission, derivation and other boxes).

sarang사랑 08:48, 16 November 2014 (UTC)

  • Option 1 or 4 would be fine. --Leyo 21:30, 5 December 2014 (UTC)
  • That would be my choice too. --Jarekt (talk) 02:44, 6 December 2014 (UTC)

While with option 1 and 2 any nationalization can be done at a central place, option 3 and 4 leave it to the single case as an insular solution; that means, in (almost) all occurencies no translation will be done, and if somebody does it will cause very much effort, nevertheless it will never cover every language. While the content of the boxes is always nationalized, the "other fields"-label (parameter "name" in {{Information fields}}) isn't.
As an advantage for preferred option 1 or 4, no expansion of {{Information}} is necessary.
The disadvantage of option 4 is the lack of unique appearance, each file will show another layout. sarang사랑 07:39, 6 December 2014 (UTC)

Fake machine readable data

Yes check.svg Resolved

The template uses the machine readable format defined at COM:MRD to mark author and source. When no value is supplied to the template, these fields contain a warning text, but still use the machine-readable markup, so a machine has no way of knowing that what it sees is not the author name / source. This results in strange attribution (see e.g. [2]) and makes it impossible to automatically exclude images with missing author/source from, say, article extracts.

Machine-readable markup should only be included when there is information to be read. For example, the author field could look like this:

<td {{ #if: {{{source|{{{Source|}}} }}} | id="fileinfotpl_aut" }} class="fileinfo-paramfield">{{int:wm-license-information-author}}</td>

--Tgr (WMF) (talk) 19:42, 5 December 2014 (UTC)

I thought we already did this, but apparently it's only for Permission. I'll go ahead and do it unless someone objects. Guillaume (WMF) (talk) 00:46, 10 December 2014 (UTC)
No objections. --Jarekt (talk) 02:14, 10 December 2014 (UTC)
Done in the sandbox for now. Guillaume (WMF) (talk) 18:49, 10 December 2014 (UTC)
Tgr: I was about to do this, then I wondered if we wanted to do the same for the description field as well. I think it makes sense, and we might as well do everything at once to spare the job queue. Thoughts? Guillaume (WMF) (talk) 21:44, 12 December 2014 (UTC)
I see no reason not to. A warning about the lack of description is not a description. --Tgr (WMF) (talk) 23:40, 12 December 2014 (UTC)
Done in the sandbox. Guillaume (WMF) (talk) 19:37, 17 December 2014 (UTC)

The author uses {{Information/author processing}}. The ID shouldn't be used also if it adds {{Author missing}}. --Tacsipacsi (talk) 11:17, 13 December 2014 (UTC)

I'm unsure what {{Information/author processing}} does. We're already checking if the parameter is empty; What else can we do? I don't want to complicate the template too much. Guillaume (WMF) (talk) 19:11, 15 December 2014 (UTC)
In this case we only need that if the parameter is one or two hyphens, it adds {{author missing}}. It does other magic, but that's irrelevant here. --Tacsipacsi (talk) 20:05, 15 December 2014 (UTC)
Tacsipacsi: Done in the sandbox, using these examples as test cases. It looks good to me now. Guillaume (WMF) (talk) 19:37, 17 December 2014 (UTC)
I simplified a bit, and it still seems to work. --Tacsipacsi (talk) 19:47, 17 December 2014 (UTC)
Good catch! Thank you. I've gone ahead and updated the main template. Guillaume (WMF) (talk) 20:15, 17 December 2014 (UTC)

Discussion of formatting for Description field

There is a proposal for a style guideline that would affect the Description field of this template. Please feel free to join in the discussion at Commons:Village_pump/Proposals#Formatting_of_image_or_media_descriptions. Thanks! — hike395 (talk) 18:06, 18 February 2015 (UTC)

'Editing undertaken' parameter

I'm uploading a large number (~500, maybe more later) images with metadata including phrases like "Editing undertaken: Unsharp Mask, Shadows/Highlights". Please add an |editing= parameter, so that this can be recorded separately from the description of the subject. Andy Mabbett (talk) 10:37, 27 March 2015 (UTC)

There already is {{retouched picture}} for such cases.    FDMS  4    12:38, 29 March 2015 (UTC)
There is, but it is not part of this template, I'm asking for a parameter into which that could be inserted, rather than including it in the description parameter. Andy Mabbett (talk) 11:49, 27 April 2015 (UTC)
AFAIK such templates are usually put below the infobox.    FDMS  4    22:41, 27 April 2015 (UTC)
+1. No new Information template parameter please. --Leyo 08:49, 28 April 2015 (UTC)
Why not? Andy Mabbett (talk) 09:45, 30 April 2015 (UTC)

Replacing uncommon replacement!?

I saw newly somewhere a discussion to replace uncommon information templates like User:Bdesham/Information (due the newly #Fake machine readable data). Can someone say more? User: Perhelion (Commons: = crap?)  09:28, 19 April 2015 (UTC)

Using user namespace templates in files is often problematic. The templates are often not maintained, not internationalized; they have unexpected behavior; files can not be easily edited or corrected; they do not include current standard of machine-readable metadata, etc. Some user namespace-templates are better than others. The most problematic are license templates since either author or some vandal can change or remove licenses from large number of files, without any trace in the file history and hardly anybody will notice even if the file is on someone's watchlist. See also this issue that removed license templates from thousands of files. Other problematic type of template are some home-brewed infobox templates used instead of {{Information}} template. A much less problematic type of user namespace infobox are templates like User:Bdesham/Information which are just personalized versions of {{Information}}, which is used to do the final formatting, internationalization and machine-readable metadata handling. I still prefer to replace them with simple {{Information}} (or other standard infobox templates). --Jarekt (talk) 13:27, 27 April 2015 (UTC)
I agree with Jarek. There are myriads of user templates, which makes maintenance and internationalization difficult. --Leyo 08:51, 28 April 2015 (UTC)

Parameter "Title"?

All CC licenses prior to version 4.0 require the attribution and naming of the "title" of the work. This parameter is included in {{Artwork}} and {{Book}} but not in this template. I think an addition of such a parameter would be most welcome. Best of wishes.--Paracel63 (talk) 12:13, 26 May 2015 (UTC)

Or does anyone know if "title" in the standard license requirement can be interpreted as meaning the name of the file proper? Many thanks in advance?--Paracel63 (talk) 12:21, 26 May 2015 (UTC)
AFAIK the attribution term only has to include the title if provided. I'd consider the filename to be the work's name unless semi-automatically generated. Content creators can specify a work's title using {{title}} in {{information}}'s description field.    FDMS  4    15:53, 26 May 2015 (UTC)

Hidden '(Reusing this file)'

This section is currently tied to the Permission field and not shown if empty. Please unty it from Permission and have it always shown at a prominent place on top or at the bottom of the template. This is actually important information for Reusers that should not be hidden. --Denniss (talk) 06:35, 3 August 2015 (UTC)

This is unnecessary, by default every Commons file has a series of media reuse buttons/links at the top that already includes a link to Commons:Reusing content outside Wikimedia. These buttons/links at the top of every file is installed by the Stockphoto gadget, which is enabled by default for all Commons users (even anonymous users who are not logged in). —RP88 (talk) 07:15, 3 August 2015 (UTC)
We can't have enough of this information; especially where it's most useful, close to attribution and licensing info. If you scroll the page down to view source/author/license any link to reuse info is gone/out of field of vision.--Denniss (talk) 12:53, 3 August 2015 (UTC)
When Information template is created the permission field is intended for license (as mentioned in the documentation). Now many people place license out of it. So one solution is to add a default value "See below" if that field is empty. Many people are already doing it. Jee 13:00, 3 August 2015 (UTC)
for years "See below" was displayed by default by the template when "permission" field was empty, I do not think we should be adding it by hand as it carries no information. I also agree with RP88 that Stockphoto gadget adequately fills the role of providing reuse information. Displaying "permission" row without any useful information in it makes page less readable. --Jarekt (talk) 16:05, 3 August 2015 (UTC)
I agree to the comment by Jarekt. “See below” is actually even being removed from the file description pages. --Leyo 20:50, 3 August 2015 (UTC)
The "see below" is completely useless, as writing "-" or doubling the textual content of the license template. sarang사랑 05:51, 4 August 2015 (UTC)

Time zones

None of the examples specify time zones. Can they be included in ISO 8601 format, or any other way? --ghouston (talk) 07:41, 10 August 2015 (UTC)

Commons:Deletion requests/Template:See below

Since the Template:See below is stated as being intended to be used in the Permission field of the Information template, I would like to notify the watchers here about my DR. --Leyo 14:34, 18 August 2015 (UTC)

Maintainance category for wrong dates

Hi all, as i understand finally we want to have only machine-readable dates in the respective parameter of the template. Is there any maintainance category that lists non-parsable dates so that we can work on it? --Arnd (talk) 20:19, 21 August 2015 (UTC)

@Aschroet: Category:Pages using Complex date template with incorrect parameter perhaps. Lotje (talk) 12:21, 22 August 2015 (UTC)

Lotje, this category i know. It contains files that use complex date template but in a wrong way. But there are many many files that do not use a template within the date parameter which cannot be parsed in an automated way. --Arnd (talk) 14:02, 22 August 2015 (UTC)

@Aschroet: maybe someone will come along and give us a helping hand. One never knows... Face-smile.svg Lotje (talk) 14:06, 22 August 2015 (UTC)
At the moment dates are processed by Module:Date and Module:ISOdate and none of those modules tags images if the date is not parsed right. In Module:ISOdate I started to work on "extended" version which would recognize some common unsupported formats (DD-MM-YYYY, MM-DD-YYYY, months in English, etc.) but I never finished testing it. Category:Files with lack of machine-readability also does not track dates. --Jarekt (talk) 14:59, 31 August 2015 (UTC)
Thank you for the explanation Jarekt. I hope you had a good time without Wiki and you are full of energy for new things. According to the dates, can these modules also handle dates which contain other templates like {{Taken on}}, {{Original upload date}} as it is described in the documentation? Or will that lead to a parsing error because the expanded form of these templates is then no ISO 8601 date? --Arnd (talk) 05:17, 1 September 2015 (UTC)
Among date modules Module:ISOdate does the parsing and Module:Date does the translation to user languages. You can see possible inputs in Module talk:ISOdate/sandbox/testcases, but if Module:ISOdate can not parse something than it leaves it as is. That allows you to use {{Taken on}} and {{Original upload date}} which call {{ISOdate}} and indirectly Module:ISOdate within it. --Jarekt (talk) 12:39, 1 September 2015 (UTC)
Ok, but this also means that we cannot detect wrong dates easily because a failing Module:ISOdate could also mean that the parameter could contain a template that uses a correct date. --Arnd (talk) 13:17, 1 September 2015 (UTC)
Probably Module:ISOdate could insert a hidden string (when date parsed successfully), which we can detect with another module called directly from {{Information}}, and add a tracking category if not found. --Tacsipacsi (talk) 13:43, 1 September 2015 (UTC)
Module:Date does add hidden metadata that looks something like "<span style="white-space:nowrap"><time class="dtstart" datetime="2008-11">November 2008</time></span>". But I am mot sure how to detect that string by {{Information}}. We are usually quite weary of asking {{Information}} (or other highly used templates) to do "behind the scene" tasks which might slow down millions of pages. If there is a clear need to detect such files than I would ask developers to add a test to other tests in Category:Files with lack of machine-readability. For starters majority of files in Category:Media missing infobox template have non-parsable dates. --Jarekt (talk) 16:42, 1 September 2015 (UTC)

Add a warning for impossible dates?

Would it be possible to add a small warning box in the date field when a date in the future (i.e. 2017-01-01) is used as the creation date? Since it isn't possible to create an image after it is viewed, it would make sense to add a warning about this, just like Wikipedia has warnings for missing titles in references (not sure if they handle dates). --BurritoBazooka (talk) 18:54, 9 September 2015 (UTC)

The best place to handle this is {{ISOdate}} (probably using some parameter since that template can be used anywhere). --Tacsipacsi (talk) 19:21, 9 September 2015 (UTC)

Bitte um Hilfe

Die Datei: File:Ivo Puhonny Grauslich.jpg ist versehentlich im Rahmen des Kulturdenkmal-Wettbewerbs hochgeladen worden und trägt falsche Informationen, die ich nicht ändern kann. Der Creator der Marionette ist Ivo Puhonny. Und die passende Lizenz sollte anzeigen, dass der Urheber Puhonny vor 70 Jahren verstorben ist. Wäre schön, wenn ein Experte die Lizenz richtig stellen könnte und das selbst erstellt verschwinden lassen könnte. Danke im voraus --MoSchle 04:08, 10 September 2015 (UTC)

Pictogram voting keep.svg Fixed --Jarekt (talk) 13:56, 10 September 2015 (UTC)