Template talk:Information/Archive 4

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Add optional "Assessments" parameter

Example

Description
This file has no description, and may be lacking other information.

Please provide a meaningful description of this file.

Source
This file is lacking source information.

Please edit this file's description and provide a source.

Author
This file is lacking author information.

If you think this file should be featured on Wikimedia Commons as well, feel free to nominate it.
If you have an image of similar quality that can be published under a suitable copyright license, be sure to upload it, tag it, and nominate it.

Discussion

{{Editprotected}}

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:

File:Syriancivilwarcollage2.png

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:
File:Syriancivilwarcollage2.png
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)

 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

{{Editprotected}}

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."

or:

  • "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 89.182.206.247 (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)
 Support for split and  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)

License

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)

ISBN

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)

Location

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)

Inconsistencies

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

{{Information
|Description=
|Source=
|Date=
|Author=
|Permission=
|other_versions=
}}

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)

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

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... 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)

Fixed --Jarekt (talk) 13:56, 10 September 2015 (UTC)

Can we add {{Private correspondence}} to the list of acceptable options in the Source field?

{{Edit request}}I've been wondering how to handle a recent concern I've had with how to properly fill in the |source= field for an image I uploaded when the author had given his permission in a private OTRS message and wished to remain confidential. I was eventually informed by LX that the correct option to use would have been {{Private correspondence}}. It would have been great if I could have found this right here in the Information template, and I would like to request that it be added to the description of |source= here so that it won't be so difficult for editors in the future to find. Can this be done? KDS4444 (talk) 23:10, 19 September 2015 (UTC)

It appears I was able to do this myself after all. This edit request may be ignored. KDS4444 (talk) 03:47, 21 September 2015 (UTC)

Missing dates

Hi all, i'd like to find all files with missing date. Is there any easy way? Maybe we could add a category similar to when the author is missing. --Arnd (talk) 11:47, 21 September 2015 (UTC)

Well, missing dates are not a big problem, compared to missing author or source. --Leyo 13:31, 21 September 2015 (UTC)
i know, but is this a reason against having such a category? I agree that a warning on the description page is not required. But a maintenance category would help at least me in reducing missing date. --Arnd (talk) 19:50, 21 September 2015 (UTC)
Well, I am indifferent here, weighing benefits and costs. Other opinions? --Leyo 21:21, 22 September 2015 (UTC)
Ok, i think i can generate such a list also by parsing a Commons dump or something like this. --Arnd (talk) 04:17, 23 September 2015 (UTC)
If "missing dates are not a big problem", why is this field declared to be "required"? Currently I'm working at an upload tool. This tool can give user warnings, if required fields are empty. Therefore I need to know, if "date" is required or not. --Hasenläufer (talk) 20:32, 6 March 2016 (UTC)
I think we should either have a date or a {{unknown|date}} template signifying that date of creation is unknown. Also photographs uploded under {{PD-old}} or similar templates should not use date of the upload in the "date" field. That said I do think that date is required in the same sense a license is or an author or copyright holder for copyrighted files (like Creative Commons files). Lack of date should not be a reason for deletion (except if it is required to validate license). I am OK with Arnd proposal to track images without date, although I am not sure what to do with such images. --Jarekt (talk) 23:39, 6 March 2016 (UTC)
Therefore the documentation of this parameter's status should be changed from "required" to "recommended". Right? --Hasenläufer (talk) 23:51, 6 March 2016 (UTC)
Done --Jarekt (talk) 01:48, 7 March 2016 (UTC)
Thanks! --Hasenläufer (talk) 07:59, 7 March 2016 (UTC)

Wikidata item

I remember I has Wikidata items added to some of my files, but I do not remember which files that were, and I can not find out now what is the appropriate template field. If someone remembers what the field is, could you please update the template information? Thanks.--Ymblanter (talk) 09:18, 17 March 2016 (UTC)

We do not have wikidata field for {{Information}} template but {{Artwork}}, {{Photograph}} and many others have one. --Jarekt (talk) 13:04, 17 March 2016 (UTC)
I see, thanks. Probably it was Artwork, i will search.--Ymblanter (talk) 19:11, 17 March 2016 (UTC)

Image generation

Currently only Other fields can be used for Image generation information; Other fields 1 is not an acceptable option.
Much more sense would give a new parameter, located between Author and Permission, like 

<!-- Image generation -->
{{#if:{{{imgen|{{{Imgen|}}} }}}{{{demo|<noinclude>1</noinclude>}}}|
{{{imgen|{{{Imgen|}}} }}} }}

This Imgen (for Image generation) would

  • be at a better location (near the Autor),
  • don't waste the "other fields",
  • use a shorter and easier to type parameter name
  • have an own, mnemonic identification useable for further maintenance
  • like in {{COAInformation}} and {{Map}}.

Can we discuss that? At the sandbox an example is inserted. sarang♥사랑 09:48, 20 August 2016 (UTC)

All other parameter names are words, while your suggested name is not easily understandable to anyone. I'd suggest to leave the template as is. --Leyo 10:14, 20 August 2016 (UTC)

But what about the name "Image" ? It's coding would look quite easy like

<!-- Image generation -->
{{#if:{{{image|{{{Image}}} }}}{{{demo|<noinclude>1</noinclude>}}}|{{{image|{{{Image|}}} }}} }}

At testcases an example can be seen. sarang♥사랑 10:44, 16 October 2016 (UTC)

I really mean this should be discussed wider before per COM:RFC. This is the most used template on Commons and this new parameter would be used at best at permille (although I would support it). ↔ User: Perhelion 19:40, 16 October 2016 (UTC)
Actually, why not create a separate infobox for vector graphics?    FDMS  4    20:13, 16 October 2016 (UTC)
Thank you for that idea. Might be the easiest solution; but it is a very complicated template, and to have another (very similar/99% identical)) template to maintain seems a less good solution. I am just thinking that the abuse of the other fields is neither good, and because the image generation has somehow to do with the author it should be located near to him, and not after long permission blocks. And the boring "+" to get the text is neither such a fine solution. All these is shown in the testcases. May be it is well known that we have already separate infoboxes with {{COAInformation}} and {{Map}}, they solve other requirements but I had been able to add the imgen parameter.. Now to create another infobox just because it is impossible to get this parameter (however its name) into the genuine one?
I am also thinking on future expansions for the upload tools - when they recognize the file type "svg" they should add this parameter. BTW, many not-SVG files are also created with a tool, and a lot of tools can create SVG and raster graphics. From this point of view the parameter "SVG" will be suboptimal; best would be "image" (as short as the horrible "imgen" but a word). sarang♥사랑 17:56, 17 October 2016 (UTC)

Language code not working

Good day, it seems that some language codes are not showing the language name, see File:Paul-Emile ottawa.jpg for example with the code "atj" for the Atikamekw language. Thanks, Amqui (talk) 14:02, 4 November 2016 (UTC)

It has nothing to do with {{Information}}. The relevant template is {{Description}}, but you may be more successful at mw:Extension talk:CLDR. --Tacsipacsi (talk) 14:52, 4 November 2016 (UTC)

Guideline for links in description field

I'd like some wider perspective/third opinion on User talk:Evrik#Could you explain please: whether there is any general guideline or preference for inline links to categories vs links to wikipedia articles. DMacks (talk) 17:40, 28 November 2016 (UTC)

Under Description, which currently says, "Wikilinks to Wikipedia articles. This helps with disambiguation and allows shorter format," I say we change it to say:
Description: Wikilinks to Wikipedia articles, Commons galleries or Commons categories. This helps with disambiguation and allows shorter format.
Evrik (talk) 17:50, 28 November 2016 (UTC)
✓ Done I changed description per Evrik suggestion. However links to Commons galleries or Commons categories should only be used if wikipedia articles do not exist. In my experience Commons galleries are much less informative than wikipedia articles. Categories are not meant to be informative. Linking to them is useful if there is no wikipedia article, but should be a second choice. --Jarekt (talk) 13:07, 29 November 2016 (UTC)
Thank you. FWIW I always try and make sure that gallery pages link to their respective wikipedia pages, and the same with categories. Check out Category:Minneapolis-Saint Paul International Airport as an example. Evrik (talk) 15:49, 29 November 2016 (UTC)

Templates that simplify uploads

Hello everyone, during my cleanups on Commons i saw that several users do not want to add parameter values itself when they already exist like the page title or the Exif or upload date. That is why i was thinking to create and promote templates that reuse already existing data as template parameters. Specially, i am about the title which is often reused as description and the Exif or upload data which is often reused as date. At best this could be done by adding a template that then just extracts those data and displays it. Is this possible? If not i would support to have a bot that replaces the template by the extracted data. What do you think? --Arnd (talk) 12:43, 17 December 2017 (UTC)

Upload wizard already extract location from exif (and date too I think?). You can probably update it to extract more. Multichill (talk) 14:06, 17 December 2017 (UTC)
Copying file name as description is also easy, just add {{subst:PAGENAME}} as description. and then clean up afterwards with VisualFileChange. All my uploads related to Category:Photographs by Judy Gallagher were done that way. --Jarekt (talk) 03:40, 18 December 2017 (UTC)
Multichill, yes the UploadWizard does this, and Jarekt, yes it is possible to do so. But there are many ways to upload to Commons and not all are as advanced users that are able to later cleanup. I would prefer the simplest solution for uploaders and upload applications such as e. g. Commons app. Why they all need to deal with the extraction of metadata (like dates, file name or even coordinates) from the files to fill in the required parameters? How often i run my bot because users did not want to invest that work and instead added something like "see title", "see metadata" etc. in many variants. If we would offer standardized templates for it we simplifiy uploads and could easily add the information to the parameters (if cannot extract them on the fly). --Arnd (talk) 14:31, 18 December 2017 (UTC)
Arnd, So what are you proposing? and lets look at each field separatly:
  • date - currently software can prefill dates based on EXIF, copy them from the date of the first image or enter them manually for each . I can not think of another improvement there.
  • description - we could have an option to prefill description with image title. That would be useful. Any other improvements?
--Jarekt (talk) 15:32, 18 December 2017 (UTC)
Jarekt, yes. With those two we could start and see how it works. --Arnd (talk) 12:56, 3 February 2018 (UTC)

Add Arabic parameters

Hi, is it possible to add Arabic parameters so that I can finish moving files from Arabic projects [3] [4]. As you can see here [5], parameters are not selected.

|description = وصف

|date = تاريخ

|source = مصدر

|author = منتج

|permission = إذن

|other versions = نسخ أخرى


Thank you. --Helmoony (talk) 18:19, 24 January 2018 (UTC)

I assume you are asking to set up arabic aliases to Information template, so Template:معلومات would work. I do not think we want to do that, as this will complicate the template a lot and we did not do it for any other language. You can get Template:معلومات to work by replacing it with {{Information}} template where |description = {{{وصف|}}}, etc. Than if you substitute the template you can get it to automatically replace it with {{Information}} template. I what I am saying is not clear I can show examples. --Jarekt (talk) 20:11, 24 January 2018 (UTC)
@Jarekt: Thank you for the technical solution. It's better to allow a bot to do that when moving files. I added this issue to a bot request Commons:Bots/Requests/JarBot. --Helmoony (talk) 20:38, 24 January 2018 (UTC)

Format for multiple dates

Hi there, looking at files like File:Uckermärkische Bühnen Schwedt.jpg we see several dates in the template parameter. However, the first date is not properly parsed in this case. It seems that a whitespace is needed before the line break. Generally I wonder what is the preferred format for such cases to guarantee a proper parsing? --Arnd (talk) 08:42, 18 February 2018 (UTC)

Fixing linter errors caused by other_fields property

The template includes the other_fields property without wrapping it in <tr><td>..</tr></td>. This can cause different errors depending on the type of content that is passed in.

  • If a page uses this template and passes in text or other content via the other_fields parameter, it will get moved out and before the table (Ex: {{Information|...|other_fields=some text here}}.
  • If a page uses this template and passes in a table via the other_fields parameter, once Tidy is replaced, this table will be split at this point. (Ex: {{Information|...|other_fields={{Retouched picture|..}} }}. See this real example here.
  • If a page combines the two by wrapping the table inside a tag like a div, you get both fostering and breaking of the table with different results for Tidy and Remex. See this real example here.

So, please fix the template and add the tr and td wrappers. Tidy will be removed by end of June 2018. SSastry (WMF) (talk) 13:28, 9 April 2018 (UTC)

SSastry (WMF), "other_fields" parameter is a quite a nasty hack using Code injection, which unfortunately is also the simplest way we can write custom extensions to infoboxes. It was used since 2008 and should be a rarely used feature. According to the documentation "you have to use {{Information field}}" with it, and that template takes care of providing proper formatting. All the uses you mention above do not meet that requirement and should be fixed if observed in any file. --Jarekt (talk) 17:12, 9 April 2018 (UTC)
User:Jarekt, Note that Template:Information field is generating <table>..</table>. You can nest a table inside another table only in a table-cell. So, you still need the surrounding <tr><td>..</td></tr> wrapper around the use of other_fields. SSastry (WMF) (talk) 17:46, 9 April 2018 (UTC)
Scratch that. I missed the use of onlyinclude! SSastry (WMF) (talk) 17:54, 9 April 2018 (UTC)
In that case, once Tidy is replaced, and rendering on these pages (that use other_fields incorrectly) changes / breaks, editors might fix them. SSastry (WMF) (talk) 17:56, 9 April 2018 (UTC)
SSastry (WMF) So hopefully Tidy is not needed for pages that use "other_fields" parameter according to documentation. Other uses might generate invalid HTML. I wonder if there is a way to track those. More troubling issue might be with {{Building address}} which is discussed here. That template relies on similar Code injection hack, is used on 657k pages and as far as I can tell produces invalid HTML. I can not think of any simple way to fix it. --Jarekt (talk) 18:12, 9 April 2018 (UTC)
Tidy is being replaced by RemexHtml [6], so invalid HTML will still be cleaned up, but the cleanup will happen differently. The high-priority categories on Special:LintErrors show which those pages are and also what piece of wikitext is going to cause that. Note that the changed rendering is not necessarily "wrong", it is different, and in some cases, might be the preferred rendering. SSastry (WMF) (talk) 19:03, 9 April 2018 (UTC)

Proposal for alt tags

{{Edit request}}

See here for original discussion.

I would like alt tags added to this template. Alt tags are a lot more universal than image descriptions, as they rely less on context. Combined with incorporation into Help:Gadget-Stockphoto, it could greatly increase the use of alt tags across all wikis, and therefore increase accessibility. Kees08 (talk) 00:26, 22 April 2018 (UTC)

 Not done Kees08, Your proposal, did not have a single comment. I am also not sure what are you proposing. I think you need to be more clear and build wider support first. --Jarekt (talk) 02:33, 29 April 2018 (UTC)

Sure, I will try to break it down further. There are six parameters in this template. I propose adding a seventh parameter. The parameter would be named alt. The information contained in the parameter would be alt text, used to help those using screen readers.

When implementing media from Wikimedia Commons into Wikipedia projects, myself and others use Help:Gadget-Stockphoto. Automatically inserting the alt text into the gadget would increase the usage of alt text across the projects, and therefore increase accessibility of information.

@Jarekt: Did that clear it up? Kees08 (talk) 21:48, 29 April 2018 (UTC)

Kees08 If we add new "Alt tag" than 45M images will be missing it. I doubt anybody will be adding them to very many old uploads. So for most images there will be no "alt tag". It might make more sense to write some gadget to automatically create alt tag based on description, but even that would be hard. There is also an issue with language, so the gadget would have to verify that the "alt tag" is in the same language as the project where they are adding the image. I think your best bet would be to wait for deployment of Commons:Structured data. It would be much more natural fit there. --Jarekt (talk) 02:12, 30 April 2018 (UTC)
Step two of the proposal was going to be to comb the Wikipedias with a bot for Commons images with existing alt tags. If only one article has an alt tag for an image, that one could be transferred to Commons automatically. If more than one exist, some sort of semi-automated process (probably where you have a radio list displayed next to an image and you choose the most appropriate one) could be used to select the best alt tag. Not to mention, I would add them to old uploads, and I am sure I would not be alone. I did not talk about this at first because I did not want to clutter up what I thought was a pretty straight-forward proposal that would help disabled people enjoy our content.
Yeah, it would have to span multiple languages, but that is the nature of Commons.
Reading up on structured data, that seems like a good way to organize data that already exists, but not to generate a lot of new data. Maybe I misread it though.
I think accessibility is really important, worded well by usability.gov: "By making your website accessible, you are ensuring that all of your potential users, including people with disabilities, have a decent user experience and are able to easily access your information."Kees08 (talk) 07:00, 1 May 2018 (UTC)
Kees08, The reason I thought structured data would be a good fit was that it is easy to add new metadata to the file and it supports multi language aspect of the data. However it might take a year or two arrive. Was your idea to display the Alt tags or just to store them? If you want just to store them than you can create a new template, like {{Alt description}} which does not show any visible fields and add it anywhere. Since most of us are not familiar with Alt tags, they would require much more explanations. Are interwiki links or hyperlinks allowed? What is the usual content of such tag and how does it differ from regular description? You can probably do a bot run for each language wikipedia without central storage. Write a bot to scrape existing alt tags from images on wikipedia and for each image found, look up if it is used elsewhere on Wikipedia and if so add the Alt tag there if missing. --Jarekt (talk) 10:25, 1 May 2018 (UTC)

Category:Author matching Creator template, Creator template not used

As discussed at Commons:Village_pump, Template:Information/author processing template is called by {{Information}} and adds Category:Author matching Creator template, Creator template not used to files where name in the author field matches existing creator template. We had something similar for {{Artwork}} and {{Photograph}} templates. The problem is that {{#ifexist:...}} is an expensive code and for last 6 years all files using {{Information}} do that check. The purpose of the check is to find candidates for adding Creator templates, but the process can not be done by bot (too many people have the same names) and it does not seems like anybody is working on emptying Category:Author matching Creator template, Creator template not used. I think we should remove it. Any objections? --Jarekt (talk) 02:38, 24 April 2018 (UTC)

✓ Done --Jarekt (talk) 02:11, 8 May 2018 (UTC)

Optional Parameter requests

Can we have an optional "publication date" parameter for when publication and creation date are different? Also, since the "description" is for visual description like alt in infoboxes can we have a "notes" parameter that would be to note stuff like context of the photo or art, and it would be a parameter of the infobox? Thanks, --PlanespotterA320 (talk) 01:03, 8 May 2018 (UTC)

The purpose of {{Information}} is to provide bare basic. If you need mode we have {{Artwork}} for artworks and other objects, {{Photograph}} for historical photographs, {{Book}} for books and other printed material, {{Maps}}, etc. See Commons:Infobox templates for details. --Jarekt (talk) 02:11, 8 May 2018 (UTC)
None of the have those things separated out.--PlanespotterA320 (talk) 19:08, 21 May 2018 (UTC)

Propose inclusion of location parameter

Propose to add the parameters of the 2009 {{Information2}} to this one, adding a "location" field to this by default. The location field could take any input, include a string of text, a Wikidata item, {{Institution}}, or {{Location}}. Various people have proposed this often over the years. It seems that there is some resistance but I fail to understand it and maybe someone else can clarify.

{{Information2}} has been available as an option since May 2006. It has 1400 uses as compared to 42 million for the default template. Problems with Information2 is that it is in limbo between approval and being fringe. As I show below with the list of links, location seems like a popular field request for the information template.

This is not the most urgent request because the 2017-2019 roll out of Commons:Structured data seems likely to change the interface anyway, but I thought that it would be useful to check in about changes for now and to get advice about current best practices.

My own project need is to mark collections of images depicting museum objects and archival documents which are from single institutions and not art. My preference would be to incorporate an {{Institution}} template somewhere that says that an object is at an institution. The objects I am considering are texts and objects from science museum collections.

Here are previous conversations talking about either putting location in the {{Information}} template:

Here is one more discussion from the art template seeking a use for museum objects which are not art:

Thanks Blue Rasberry (talk) 16:19, 21 May 2018 (UTC)

Example case

Consider File:Informed Consent Agreement Between Antonio Benigno and Walter Reed (English).jpg. I have some archival documents like this and a collection of medical devices in a university collection. I would like to note somehow that these objects are at the university, or even a particular collection.

Right now I just have an institution template in the description field of the information template. What better way is there for images of this kind of content? Blue Rasberry (talk) 20:19, 21 May 2018 (UTC)

wikidata

May we have wikidata parameter as it is in Template:Artwork ?. Is there some alternative template with this parameter, instead?. Thanks, --amador (talk) 04:44, 6 June 2018 (UTC)

In case of {{Artwork}} wikidata parameter has clear meaning: an item which stores metadata for a given artwork. {{Information}} template used by great majority of files, is meant to be used mostly for photographs taken by the uploaders and 2/3 of images on Commons use one of CC license templates( mostly used by such files). Such files do not have associated items on Wikidata, and the danger is that people will be adding Wikidata items for subjects or creators instead. --Jarekt (talk) 11:21, 19 June 2018 (UTC)

machine-readability

I noticed that this template adds all pages with the parameter "Author" capitalized to Category:Files with no machine-readable author. If the parameter is lower-case, then everything is OK. Could anybody with edit rights resolve this issue? --Jarash (talk) 18:12, 10 July 2018 (UTC)

Transcription parameter

Please can we have a |Transcription= parameter, like in {{Artwork}}? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:08, 3 August 2018 (UTC)

Artwork doesn't have a transcription field. Did you mean the inscriptions field? I don't think it make sense to add an inscriptions field to the Information template as it intended for items with basic information. However, if you can't use {{Artwork}}, don't want to use {{Inscription}} inside the description, and you need to add an inscriptions field to {{Information}}, you can use the other fields field to add a custom field. For example, you could do something like the following: 
{{Information 
 |description    = 
 |date           = 
 |source         = 
 |author         = 
 |permission     = 
 |other versions = 
 |other fields={{Information field |name={{int:wm-license-artwork-inscriptions}} |value={{inscription |1=example inscription |position=bottom right}}}}
}}
—RP88 (talk) 14:53, 3 August 2018 (UTC)
Yes, I meant |inscriptions=. Thank you for the work-around, but a dedicated parameter would be far less kludgy and so more user-friendly. My request stands. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 31 August 2018 (UTC)

I am still finding regularly cases where such a parameter would be useful. Can anyone help, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:41, 19 January 2019 (UTC)

{{Information}} is our basic template with only a couple of fields to cover simple cases. If you want to add more fields you either use the "other fields" or use one of the dedicated domain templates like {{Artwork}}, {{Photograph}}, {{Book}}, {{Map}}, etc. Multichill (talk) 15:49, 19 January 2019 (UTC)
Having been a user of Commons for over a decade, I'm familiar with the range of templates available, and use them. Nonetheless, I still regularly finding cases where a specific |transcription= parameter would be useful in this template, not least for the reasons I have already given, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:31, 19 January 2019 (UTC)
 Not done this template is used about 46657156 times and about 8660 times in combination with {{Inscription}}, so about 0,019 % of these files. Too much of an edge case. Multichill (talk) 00:02, 20 January 2019 (UTC)
Oddly enough, you don't have a veto. This is something for the community to decide. Your statistic is meaningless, because not all transcribed text uses {{Inscription}}; it took seconds to find File:2015.211296.Punch-Vol-cxxxvii 0425.jpg, for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 20 January 2019 (UTC)
This template has a quite a long history of denied feature requests. My response is in in line with that. As an admin I evaluate requests for edits to protected templates (and pages) and either mark them as done or not done. If you think I'm being unfair, you can go to Commons:Administrators' noticeboard to ask another admin to have a look.
Please don't change my comments. Changing other user's comments is not considered acceptable behavior on Commons and might result in a block. Multichill (talk) 20:20, 20 January 2019 (UTC)
You're not entitled to make an edict as an admin, especially once you've commented as a participant in the discussion; as you well know. You can dick around adding a bright red cross by inappropriately using {{Not done}} all you like, but you still don't get a veto over community discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:11, 20 January 2019 (UTC)
  • I like this idea. -- Tuválkin ✉ ✇ 02:27, 21 January 2019 (UTC)
  • strongly oppose, our template {{Information}} is the simple description one, we are describing something rather rare in usage and our practice have always been to extend (inherit) a new description template for thoses cases such as {{Book}}, {{Artwork}}. Moreover I'd like to remind everyone that attacking admin not wanting to do a protected edit after giving a rationale is wrong and is more likely to escalate into a conflict, when you can reach other admin on COM:AN or try for the village pump, and get wider audience, and build a consensus. --PierreSelim (talk) 09:48, 21 January 2019 (UTC)
    • "attacking admin not wanting to do a protected edit" No-one has done this. Please avoid false insinuations.
      There is already a pointer to this discussion on village pump.
      How is adding a bogus {{Not done}} template helping to "build consensus"?
      We don't need a whole new fork of {{Information}} just for items which include text, albeit there are many thousands of them, across a vast range of types of subject. I note that you give no substantive argument as to why such a parameter should not be added.
      As to the argument of simplicity, how is |other fields={{Information field |name={{int:wm-license-artwork-inscriptions}} |value={{inscription |1=example inscription |position=bottom right}}}} simpler than |transcription=? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 21 January 2019 (UTC)
      How about something like {{Inscription field}}? Jean-Fred (talk) 20:17, 21 January 2019 (UTC)

Как это сделать Бабур Рахатбеков (talk) 17:32, 25 January 2020 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:Information/Archive_4&oldid=412469577"