Template talk:Information/Archive 5

Unexpected filename in file description

Looking at Special:Search/dokkum, I noticed that many results have their excerpt start with a repetition of the file name, which looks messy and unprofessional (in my opinion). For example:

File:Windmill Zeldenrust in Dokkum.jpg DescriptionWindmill Zeldenrust in Dokkum.jpg English: Windmill Zeldenrust in Dokkum build on the cities bulwark defence. Date 9 February 2013, 16:39:57 (3,464 × 2,309 (3.16 MB)) - 01:18, 24 November 2016

The part that is unexpected is that the excerpt contains the filename, causing it to show up twice. (In addition to lacking of space between it and the word "Description"). I traced this back to Template:Information, which contains the following code (simplified):

<td class="fileinfo-paramfield" lang="{{int:lang}}">
{{int:wm-license-information-description}}<span class="summary fn" style="display:none">{{PAGENAME}}</span><!-- required for hCalendar and hProduct microformat; though hMedia would be more appropriate -->
</td>
<td class="description">{{{description|{{{Description|}}} }}}</td>

It is intentionally being added (albeit visually hidden). It has a comment explaining that it is "required for hCalendar and hProduct microformat", but I am unsure to verify whether this is actually working and being used. Does anyone know?

Also, if we want to keep it, I'd propose we move it toward the end of the Template output, rather than on top, and consider adding the class searchaux so that it is not indexed as part of the text content (mw:Help:CirrusSearch). We may want to do the same for the word "Description" as well. --Krinkle 02:19, 27 September 2018 (UTC)

Krinkle, I was just wandering about this and other irregularities of the html produced by this template:

1. why do we have <span class="summary fn" style="display:none">{{PAGENAME}}</span> in the space where one expects translated word "Description"
2. why <td> cell for date has "lang" field, which is often wrong. For example HTML of File:Radomsko ul. Reymonta 58.jpg has <td lang="en">styczeń 2015 r.</td> which is incorrect as the cell content is in Polish not English.

Looking at the edit history it looks like user:Rillke first added <span class="summary fn" style="display:none">{{PAGENAME}}</span> with this edit to the cell with the description text and later moved it with this edit to the cell with description field name, explaining that he was fixing HTML-Tidy-hack issues. user:Rillke was not active in last 2 years except for few edits yesterday, but maybe he can help to figure out if this is still used. Also pinging @Pigsonthewing: who often advocates for microformat issues. As for wrong language labels in date <td> cell, that was added by user:Ebrahim with this edit. Ebrahim since we can not determine the language of the content of the date field (if not in standard YYYY-MM-DD format) can we remove the lang field? --Jarekt (talk) 16:02, 1 November 2018 (UTC)

Rewrite in Lua

Module:Information is designed to replace wikitext implementation of Template:Information, and it can be tested through Template:Information/sandbox. The module is designed pr produce exactly the same html as the current template and it is being tested on small number of files using {{Information2}} template, which at the moment calls Template:Information/sandbox. The rewrite was motivated by future Commons:Structured data when {{Information}} might have to interact with Structured data the way {{Artwork}} or {{Creator}} interacts with Wikidata, but in the mean time it offers 50% faster load time, smaller expansion depth and smaller memory use. Please test {{Information/sandbox}} by temporarily replacing {{Information}} in the most complex and messy description pages you can find. I will do the same. --Jarekt (talk) 12:42, 2 November 2018 (UTC)

I don’t see any traces of {{Information/author processing}} and {{Parse source}}, nor any parameter check (done by Module:TemplatePar in the wikicode version). Maybe the former two should be rewritten in Lua, too, to avoid invoking templates from Lua code (especially the author one: it’s really simple, while the current wikicode implementation runs these tests twice in order to ensure {{Author missing}} is not marked as machine-readable author; this could be made even more simple in Lua, at lest in terms of time complexity). —Tacsipacsi (talk) 14:18, 2 November 2018 (UTC)

{{Information/author processing}} was used to find and correct thousands of files with bad metadata. It is done now and Module:Information will ignore any fields with only punctuation. {{Information/author processing}} was also used for checking if there is a creator page matching author name and using that instead. That feature was turned off as it was creating great many wrong creator names. So I thing all current tasks of {{Information/author processing}} are being done by the module. As for {{Parse source}} I also do not think it is necessary anymore, In the past we used it to correct thousands of local translations of "own work" phrase to {{Own}}, but now it is done and with very few being added I do not think we need to perform a check on 50M files to find occasional new case. So in my opinion those 2 templates should be disabled, except that I do not want to do unnecessary edits to the template, if they can be avoided. --Jarekt (talk) 17:23, 12 November 2018 (UTC)

OK, but I would like to have a bot check all usages just before the switch, so that nothing breaks out of a sudden. (Maybe a regular, e.g. monthly, check is also worth to find the new wrong inclusions. This latter can even be narrowed down to the pages that changed since the last run, so it uses far less resources than the template/module version.) Such a test seems pretty easy using Pywikibot. —Tacsipacsi (talk) 20:27, 12 November 2018 (UTC)

Any bot runs that have to go through 50M files would take forever. Maybe if you run it off a data dump, but to run it of the live website I ca usually visit 10-20k pages per day. Also there are no plans for deployment in near future. I was [[Commons_talk:Structured_data#Lua_version_of_the_{{Information}}_template|asked not to deploy for time being]]. BTW, Files affected by {{Information/author processing}} go into Category:Bad author info and files affected by {{Parse source}} can be found here. So anybody can check and fix files that are corrected by those 2 templates. --Jarekt (talk) 00:08, 13 November 2018 (UTC)

Sorry for not having checked the figures. However, I think the 10-20k/day is a realistic number for bots writing the wiki (because of their performance constraints). I’ve just ran a bot doing nothing but printing the article size, and it went through 180,000 pages in around an hour (it preloads pages in 50-article packets, which can be increased to 500 for bot accounts, resulting in an even faster script). It means approximately 4.3 million pages a day, and I think it’s closer to the performance of the bot resolving this task than your 10-20k. So 50M files can be checked within two weeks, which is not instant, but neither something we should call forever. Although the category/template is just as good, except that the category contains only the file-namespace pages, maybe this could be expanded to all pages (hopefully there’s not much). —Tacsipacsi (talk) 00:11, 14 November 2018 (UTC)

Additional information

There are ~190K images in en.WP waiting to be copied (moved) here. An unknown number of them have a |additional_information= parameter (example). Can we accommodate that, to facilitate quick transfers? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:03, 17 January 2019 (UTC)

We could concatenate |description= and |additional_information= before displaying it in the description field. --Jarekt (talk) 03:02, 18 January 2019 (UTC)

@Jarekt: Yes, that would work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 18 January 2019 (UTC)

Andy, Yes we can do that, but I realized that I do not understand why. We transfer files all the time from other language Wikis and for all the other ones we do not need to modify Information template. I am not exactly sure how that is done by I belive it involved some sort of mapping mechanism, which is not always 1 to 1. Another approach I used in the past to fix files moved from other wikis with their native infoboxes is to use "subst:". For example, we have files transferred which use {{Изображение}}, {{파일 정보}} or {{Зображення}} templates. For those I occasionally would run a bot to replace "{{Изображение" with "{{subst:Изображение" which neatly inserts {{Information}} template and renames all the fields. Perhaps as we move en.WP files here we can use some temporary template like Information_en_wp which would have to be substituted. template:Information_en_wp could do all the concatenating of |description= and |additional_information= fields. What transfer tool will be used for this? --Jarekt (talk) 13:37, 18 January 2019 (UTC)

@Jarekt: The new "FileExporter" gadget. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:16, 21 January 2019 (UTC)

Andy, I looked through the documentation and it is not clear how to deal with such parameters. So I asked about it at mw:Help_talk:Extension:FileImporter. --Jarekt (talk) 16:16, 21 January 2019 (UTC)

Make description optional ?

It might be a bit early for that, but I think that now that we captions outside this template, the description parameter can be made optional.--Zolo (talk) 17:05, 16 February 2019 (UTC)

I think the template should make sure at least one (or even at least the English) description is given before not warning for empty description field. As far as I know, it’s not possible yet, but will be once. —Tacsipacsi (talk) 23:35, 16 February 2019 (UTC)

Image generation

After some years, I try again to discuss the parameter "image". All the time until now the parameter "other fields" is abused for the file description, where IMHO it should not be – an own parameter for the description, with a more significant and shorter name, and positioned near to the author instead of below lof the permission, might be much more adequate. I made a demonstration example using the {{/sandbox}}. Some information-related templates (COAInformation, Map) have such a parameter ("imgen" works as well as "image") since many years; but I believe that not another derivate of Information is needed, the parameter "image" should be standard in the standard Information template. -- sarang♥사랑 16:17, 25 October 2019 (UTC)

Since this morning, that parameter is established and can be used. Some better integration of it would be helpful. Maybe that it can be done? -- sarang♥사랑 13:47, 12 November 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. -- sarang♥사랑 13:47, 12 November 2019 (UTC)

Rewrite in Lua (again)

As I reported a year ago (see above), Module:Information is designed to replace wikitext implementation of Template:Information, and it can be tested through Template:Information/sandbox. The module is designed to produce exactly the same html as the current template and it is being tested on small number of files using {{Information2}} and {{Flickr}} template, which at the moment calls Template:Information/sandbox. The rewrite is step one of plans to better integrate {{Information}} with Commons:Structured data, so in the future {{Information}} will be able to access image metadata from either wikitext or from structured data. Another motivation is to clean up some of the current dependencies, like for Template:Information/author processing. It follows my work on other file infobox templates like {{Artwork}}, {{Photograph}}, {{Book}}, {{Art photo}}, {{Location}},{{Institution}} or {{Creator}} which were rewriten in Lua in order to be able to pull metadata from Wikidata. Please test most messy cases you can find, by previewing the page with {{Information}} replaced with call to {{Information/sandbox}}. Unless there are known issues I will roll out the Module:Information within a week. --Jarekt (talk) 13:47, 8 November 2019 (UTC)

Sounds like a good plan to me! Multichill (talk) 13:00, 9 November 2019 (UTC)

New Lua version is deployed. Please report issues here. --Jarekt (talk) 14:21, 11 November 2019 (UTC)

@Jarekt: Got problems, seems to have difficulties with a table like from {{AutVec}} at the authors field; e.g. Ccross.svg and others with AutVec. -- sarang♥사랑 15:23, 11 November 2019 (UTC)

I will see what I can do about it. --Jarekt (talk) 16:36, 11 November 2019 (UTC)

@Jarekt: It might have been better to write it with <table> or with <span> – but many other templates, also author templates, do it with wikitables. Sorry for your troubles because of that, thank you for enabling it -- sarang♥사랑 17:23, 11 November 2019 (UTC)

In my testing Module:Information was producing the same html code as original template, but {{AutVec}} seems to be the first example of template which produces different html code: the old template somehow converted wiki tables to html tables, while with the new code this conversion is not happening. We stopped using wiki tables in most templates years ago, so I guess I did not run into them during my testing. The easiest solution to {{AutVec}} would be to rewrite it using html tables, I wonder how many other templates like that we have. --Jarekt (talk) 18:41, 11 November 2019 (UTC)

Problem with my autor template, see File:Олещук Ігор Андрійович - 07106012.jpg and others my files. --Микола Василечко (talk) 19:32, 11 November 2019 (UTC)

Микола Василечко I changed the template to use html tables. The output is the same. --Jarekt (talk) 20:31, 11 November 2019 (UTC)

Both of the above problems seem to be because old code automagically got line breaks after opening (and before closing) <td> tags thanks to the template calls—maybe just changing all wrappers around line 45 to "\n%s\n" would fix them. —Tacsipacsi (talk) 20:50, 11 November 2019 (UTC)

Tacsipacsi good idea. That fixed the problem in the images that had it. Thanks. --Jarekt (talk) 00:10, 12 November 2019 (UTC)

@Jarekt: I just gave it a look: the template:{{Created with}} is used 870K times, also from a great lot of other templates for their final output, and makes its display also with wikitables. Many oldfashioned templates do it that way. Do you think it should be redesigned? -- sarang♥사랑 06:26, 12 November 2019 (UTC)

I just redesigned {{AutVec}}, instead of with wikitable I do it now with <span>, and it works fine. -- sarang♥사랑 10:26, 12 November 2019 (UTC)

Hi Jarekt, thank you for your rewrite. Today I have seen a mis-alignment, i.e. on File:Elfter im Elften, Köln, 2019-0220.jpg. The left column is aligned to the top of the cell, the right column to the middle of the cell. And/or an additonal linebreak on the left side was added. It looks a bit unaesthetic now. Raymond 14:04, 12 November 2019 (UTC)

Wrapper values changed from %s to \n%s\n apparently produce redudant white-space in output for all uses, compared to old version. I think adding \n characters wasn't a good idea. Also \n after closing div should probably be removed for the same reason. 2001:7D0:81F7:B580:6470:3A0A:134F:E038 18:45, 12 November 2019 (UTC)

Current status

So my understanding is that:

• Module:Information version from 26 October 2019‎ (first deployed version)

• Did not render properly some templates using wiki tables which were in author or source field
• Had a nice "compact" look for the table rows

• Module:Information version from 11 November 2019‎‎ (current version)

• Differs from the previous version by adding "\n" line breaks above and below author , source and date fields
• Does render properly all templates we know of
• Had many table rows with extra spaces on top and bottom making them look unnecessarily fat

I will research ways to slim down the rows and still be able to render all templates and will deploy once I find a good solution. Some potential solutions:

• rewrite problem templates to use html templates, however it is not clear how many are problematic
• Information template can detect problem templates and add page brakes around them
• research it we need page brakes on top and on the bottom or would just one

--Jarekt (talk) 03:25, 13 November 2019 (UTC)

@Jarekt: Is there an example page where I could reproduce both issues? I'll look into why the rendering could be different. I don't think a general change from wikitable to html table should be necessary. --Zhuyifei1999 (talk) 08:19, 13 November 2019 (UTC)

@Zhuyifei1999: Formerly problematic files, File:Олещук Ігор Андрійович - 07106012.jpg, are good examples. (The wiki tables aren’t broken now, of course, as the live version fixes that issue.) The current problem is that MediaWiki inserts <p> tags around the parameters, which have margins. One fix is to try to find out if the line break is necessary, and insert it only then; another, easier but less elegant one is to simply add some CSS class to the data fields and apply CSS .class p:only-child { margin: none; } (with .class changed to the appropriate class). In any case, I think it’s time for the transition from MediaWiki:Filepage.css to using TemplateStyles on file page templates, which makes maintenance easier and doesn’t require repeating rules in MediaWiki:Common.css. —Tacsipacsi (talk) 10:55, 13 November 2019 (UTC)

@Zhuyifei1999: I created Module:Information/slim which is the version of the module with all the fields in the slim version (without "\n" around them). That page is also transcluding a test page with problem templates. --Jarekt (talk) 14:11, 13 November 2019 (UTC)

@Tacsipacsi: You do have much better grasp of what is going on and why with html and css. All I can do is try random things and see what is happening. Ideally a code like Module:Information/slim would be deployed as it is the most visually pleasing. Any help with rewriting CSS files if it can magically resolve some of the issues would be great. By the way, File:Олещук Ігор Андрійович - 07106012.jpg is also rendering correctly because I rewrote the problem template {{WasMykola}} to use html templates. I think this issue might be related to phabricator:T2529 and phabricator:T14974 tickets. --Jarekt (talk) 14:11, 13 November 2019 (UTC)

@Jarekt and Tacsipacsi: I don't get the issue regarding the margin. I made {{Information/sandbox}} use the old wikitext version of the template and it does produce the same <p> in the source field of User:Zhuyifei1999/sandbox, like the current lua version. --Zhuyifei1999 (talk) 17:36, 13 November 2019 (UTC)

File:Ghost.svg is a simple example where cells include inline text, not tables. It currently uses the pre-Lua version from sandbox and there's no dirty <p> inside information template. If I preview it using current main Lua version then <p> is added in date, source and author cell. 2001:7D0:81F7:B580:44EA:8AF7:6868:9924 19:32, 13 November 2019 (UTC)

Ah thanks. I see what you mean. --Zhuyifei1999 (talk) 20:20, 13 November 2019 (UTC)

We have too many sandboxes. I was trying to use the following logic:

• {{Information}} calls Module:Information
• {{Information/old}} calls prelua version (I have similar /old) for all or most lua conversions)
• {{Information/sandbox}} calls Module:Information/sandbox
• no template calls Module:Information/slim (at the moment it was not necesary)

Can we restore this logic? --Jarekt (talk) 20:27, 13 November 2019 (UTC)

Restored --Zhuyifei1999 (talk) 22:21, 13 November 2019 (UTC)

Ok, so my testing shows that pwrapp-ing does not occur if </td> is one the same line as the text that was being wrapped. User:Zhuyifei1999/sandbox. Does that fix the issue? That said, I tried to find the exact logic that is responsible for this, but html5depurate doesn't do this specific case and I have no idea how to test remexhtml --Zhuyifei1999 (talk) 22:21, 13 November 2019 (UTC)

That seems to do the trick, yes.

There still are additional newlines inside cells in page source, though. They don't display, so maybe it doesn't matter. I tried to figure why wikitable doesn't break without entering preceding newline inside cell in old version. Wikitable seems to be saved by passing it through #if parser function: <td>{{#if:{{{source}}}| {{{!}} ... {{!}}} }}</td>, while <td>{| ... |}</td> breaks. Is there a Lua equivalent that allow processing the cell content in similar manner?

PS I also removed the redundant newline after closing div in sandbox. 2001:7D0:81F7:B580:9C1A:4FAA:C223:BBB2 15:14, 14 November 2019 (UTC)

The reason the parser function works is likely phab:T14974. A linebreak is 'magically inserted' right before the {| if it is substituted in by a parser function. --Zhuyifei1999 (talk) 16:21, 14 November 2019 (UTC)

Next Version

@Zhuyifei1999 and Tacsipacsi: I updated Module:Information/sandbox adding:

• The field wrapper "\n%s" as suggested (thank you for debugging this)
• Build in code for {{Description missing}}, {{Author missing}} and {{Source missing}}
• Build in code for error reporting when template has incorrect parameters, so we can stop calling Module:TemplatePar from the template
• Initial version of code for accessing Structured data: when description is missing the code will check if Structured data has captions and use them instead.

I will deploy this weekend when I have more time to watch it after the deployment. I think I tested the new version on all the files that gave us trouble in the past. Are there any other files I am forgetting to test on? --Jarekt (talk) 04:55, 16 November 2019 (UTC)

 Done new version is deployed. Hopefully that will be the last change for a while.--Jarekt (talk) 04:26, 17 November 2019 (UTC)

Dedicated field for Flickr

The idea for this line is to have a dedicated line for images from Flickr that show a design like the integration on Sympetrum fonscolombii, female, Sète cf04.jpg. I know that there is {{Flickr}} as version of {{Information}} that is made for images from Flickr. I know that you can also do that by including other_fields and some information, but that would not be a standardised way. It could also work like {{Object location}} that is a seperate template, but adds a line to the existing template.
Another idea is to not make this Flickr exclusive, but to call the new information field "website" that would be located below the source. Either by entering a value in a seperate field or by detecting the "flickr.com" in the URL the logo could be included. This could also be used for other images like USGov images (including Navy, Army, Air Force, etc.). Any ideas or comments on that? --D-Kuru (talk) 10:32, 13 December 2019 (UTC)

D-Kuru, In general we try not to add new fields to {{Information}}, and since the very first version of the template the list of supported fields did not change. That list also matches, fields in similar templates in about 200 sister projects. Also looking at File:Sympetrum fonscolombii, female, Sète cf04.jpg I am not sure what is the purpose of the flickr field. Usually flickr field would serve as a source but in this case it seems like the image was first uploaded to Commons by the photographer, so the flickr field only serves as a side note that there are other places on the web where you can also find the same image. We usually put that kind of info in the talk page. --Jarekt (talk) 14:47, 13 December 2019 (UTC)

OK, this one got lost somewhere over the holiday season.

I understand that many people don't want to change a template that is that heavy in use and wide spread. And since there are other ways to include such an information-line AND form a visual unity it may is better to leave it as it is. Here the flickr field has not the value that could be added to other images since this image is also taken by a user from Commons. The idea was more for images that were not taken by a user from Commons so that it's easier to see on the first sight (eg. for admins or the average user) where is image is taken from.

--D-Kuru (talk) 23:00, 10 January 2020 (UTC)

How about a Flickr source template (Category:Source templates)? We have a number of that type of template, which can be placed in either the Source or Other versions areas as appropriate. Not sure we have one right now, but it could make sense. That is normally how we typically show file sourced from other places (such as, say, {{LOC-image}} or {{NARA-image}} or {{ID-USMil}}). Category:Flickr templates actually does have several source templates, often for particular Flickr accounts, like {{Flickr-Brooklyn-Museum-image}} or {{Flickr-Parma-Volley-Girls}}. There is a generic source template {{Flickr source}}, but it creates a bare link and not a box. There is {{Flickr box}}, used on exactly one file as far as I can tell, but that is not used as a source but more noting the same author uploaded the file to Flickr as well as directly here (though there is {{Flickr own work}} for that as well). I guess boxes like that could go in "other versions". I suppose we may not have a box version common, because Flickr is neither the author nor the copyright owner who decided to release the photos under a free license -- they just provide the platform, and maybe some consider it advertising, beyond simply stating the source. Obviously, it's nice that a platform allows its users to easily license things like that. I could maybe see a boxed version of a template which constructs the URL (may enable easier redirecting if the URL format changes, though Flickr's never really has I don't think), but not a separate Information template field. I would prefer a box inside the Source area, if it is the direct source, or "other versions" if it's denoting a separate upload or version available on Flickr. The example image does not make that clear (though it appears to be an "also uploaded by me at" situation). Carl Lindberg (talk) 23:27, 10 January 2020 (UTC)

There is {{Flickr}} which is actually {{Information}} for flickr images, but some images don't use that template. The change would be very easy here, but we would miss out on the images that don't use {{Flickr}}.

I don't see advertising here. You don't aim to lure people into a paid subscription. You just make clear on the first view where the image is taken from. But of course, if you really want you will be able to find the advertising-bogeyman behind every corner (eg. {{ID-USMil}}: YVAN EHT NIOJ!).

I don't think that I mentioned this: The point of such a line would be not not have something like |other_fields={{Information field}} so that eg. the design could be updated for all at once without the need to edit every single image.

--D-Kuru (talk) 00:54, 11 January 2020 (UTC)

New update to the template

I just released a new update to the template with better support for pulling metadata from SDC, if missing. Please notify me if there are any issues. --Jarekt (talk) 22:52, 17 April 2020 (UTC)

@Jarekt: There was one serious issue (serious in the sense that it caused minor issues on many file pages and thus also a large cache pollution), which I’ve fixed on Sunday. Another, much less widespread but not less annoying issue with the current implementation is that if the description is from SDC, langWrapper() shows language names in the user’s language and as-is, while {{Description}} uses autonyms and capitalizes the first letter. This means that using a German interface text, {{hu|Mintaaláírás}} from wikitext shows as

Magyar: Mintaaláírás

while if it was in SDC, it displayed as

ungarisch: Mintaaláírás

which is also semantically invalid HTML, as it states (through the lang attribute) that the whole box is in Hungarian, while the language name is in German in fact. But the biggest issue is that it’s different from what users are used to and harder to find (if a user searches for the description in a given language, we can assume they speak that language, while this is most probably, but not necessarily true for the current interface language). —Tacsipacsi (talk) 21:46, 22 April 2020 (UTC)

Tacsipacsi, Thanks for fixing the first issue with ID. How was that issue manifesting itself? As for the language issue. I began experimenting with possible solutions at Module:Test and I think I got it in the Module:Information/sandbox. However, lets not roll it out yet as I would also like to add a strip down version of Module:Wikidata label (so I can remove the dependence). I would also like to get number of files in Category:Pages with script errors to zero, beforehand, so I can see when there are issues with the new code. --Jarekt (talk) 09:30, 23 April 2020 (UTC)

@Jarekt: The issue manifested by the fallback text getting into the machine-readable description (viewable with for example the Multimedia Viewer) of files like File:Erdos inequality.png (this file now has the sandbox, so you can play around with it—the Multimedia Viewer doesn’t process previews, one has to actually save the template to see the affect). I don’t think we need to hurry with fixing the language issue—there shouldn’t be many files that have the {{Information}} template, no wikitext description, but have SDC description, so it won’t be widely noticed. —Tacsipacsi (talk) 22:06, 23 April 2020 (UTC)

I think the current sandbox version, has all the issues fixed I can think of, including removing dependence on Module:Wikidata label. --Jarekt (talk) 01:50, 24 April 2020 (UTC)

I have deployed the new version. with the changes discussed above. --Jarekt (talk) 19:58, 28 April 2020 (UTC)

Table tag error

This template has an error in table tag, which in turn is throwing errors in thousands of pages as can be seen in Lint errors: Table tag that should be deleted. I do not understand which part of the code is responsible for this. I request anyone experienced in template editing to correct this error. Thank you AVSmalnad77 ^chat 07:59, 5 January 2021 (UTC)

@AVSmalnad77: I looked at Lint errors: Table tag that should be deleted and fixed couple files like this one. The issue is not with the {{Information}} template but with how people use it. I browsed through a dozen pages and in each case it was badly used "other_fields" field which is compatible with {{Information field}} and few other templates but not much else. I wonder if there is a way to get a list of affected pages, so we can fix some of the known issues by bot. --Jarekt (talk) 18:42, 2 March 2021 (UTC)

@Jarekt: it is possible to get a list of pages using advanced search. This shows that currently there are 58 pages having other_fields with {{Retouched picture}} like the example you have given. Similarly this shows 213 pages have wrong use of {{Vva}}. All wrong template uses can be searched this way. AVSmalnad77 ^chat 05:17, 3 March 2021 (UTC)

{{Vva}} and {{Retouched}} should both not be used with |other fields= but as |other versions=. -- sarang♥사랑 11:04, 1 May 2021 (UTC)

Edit request

{{Edit request}} Move {{Heavily used template}} from Template:Information/Archive 5 to Template:Information/Archive 5/doc, without the nosubst. 84.250.14.116 13:39, 3 July 2021 (UTC)

No thanks, we need it there for protection.   — Jeff G. ツ _{please ping or talk to me} 14:04, 3 July 2021 (UTC)

@Jeff G.: I don't really like how the notice is missing from the /doc page, nor do I like there is no {{Documentation|content={{Heavily used template}}}} at the top to clearly see from Template:Information/Archive 5 the nosubst'd warning is not part of the template to be transcluded. 84.250.14.116 20:58, 3 July 2021 (UTC)

The doc is not heavily used, the template is, so that's where {{Heavily used template}} belongs. See Template:Heavily used template/doc for usage. Also, it is clear from the doc and the wikitext that {{Heavily used template}} is not included.   — Jeff G. ツ _{please ping or talk to me} 21:21, 3 July 2021 (UTC)

(Edit conflict × 2) @Jeff G.: Why? What’s the risk in someone removing the warning template? The template is protected because it’s used on more than 63 million pages. The banner doesn’t appear on these pages anyway, it only appears on this very page, so any vandalism against it would affect only this very page. Furthermore, it slows down the parsing of these 63M+ pages, since the parser needs to parse these 58 bytes of wikitext that it eventually drops. Not much, but when we multiply this with tens of millions, it may have considerable performance impact. (On the other hand, of course, any edit to this template means that all 63M+ pages need to be reparsed once, which also takes quite some server resources. So in the short run, any change affects performance negatively; but in the long run, we may impact performance positively.) —Tacsipacsi (talk) 21:58, 3 July 2021 (UTC)

@Tacsipacsi: The risk is that someone could impact parsing on all those files any more than it has already been impacted. I'd like to see some metrics on that. @Mormegil: You added that template 19:20, 2 January 2008 (UTC), what do you think?   — Jeff G. ツ _{please ping or talk to me} 10:45, 4 July 2021 (UTC)

Errm… thirteen years ago? Don’t really remember that… :-) But… no, that wasn’t me, it was just a failed reverted attempt to simplify the code. It was User:Gmaxwell in 2007. :-) But I don’t think we really need fourteen-years-old motivation, the point is whether the guidance on Template:Heavily used template/doc is correct or should be changed, but that discussion should be held there, right? (I can say I don’t really see a point in keeping the notice directly on the template pages, so I agree with Tacsipacsi the warning template should probably better be placed at the top of the /doc subpages.) --Mormegil (talk) 08:17, 7 July 2021 (UTC)

Missing label for source will cause LUA error

@Jarekt: I noticed on [1] that I get the LUA error "Lua error in Module:Information at line 271: attempt to concatenate local 'label' (a nil value)." . This is because file available on the internet (Q74228490) has no label in Polish. If you switch it to some other language which has a missing label like Spanish you get the same error. I think Module:Information should be updated to check if the label is actually available and if that's not the case, fall back to English (or use some sort of fallback chain). Multichill (talk) 12:34, 2 May 2020 (UTC)

It should be fixed now. --Jarekt (talk) 02:40, 4 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 02:59, 9 February 2022 (UTC)

The permission parameter

Hi @Jarekt: , many users ignore the suggestion to let this field blank when an entry to == {{int:license-header}} == is present; very often they add nonsense as "see below", or they repeat the license or parts of it. How about expanding the upload feature (which handles e.g. the {{Location}}) to avoid the upload of the whole |permission= line when a license header is used? When it is done with new uploads, possible errors (e.g. having the license header but specifying the license with permission) are immediately obvious: there are also other checks possible to correct well known misuse.
Currently the cleanup tool removes empty permission parameter lines when the license header is present. It seems better not to upload at all useless parameters - and the permission is definitively useless when the license header exists! -- sarang♥사랑 10:40, 1 May 2021 (UTC)

@Sarang: How about just having upload tools and the cleanup tool put the license on the |permission= line and dispensing with the == {{int:license-header}} == section altogether?   — Jeff G. ツ _{please ping or talk to me} 12:57, 1 May 2021 (UTC)

I think |permission= is for more custom things, mainly free text. License templates are already too wide, putting them into a not full-width template cell makes the situation even worse; CommonsMetadata extracts license templates put in this field twice (once as a license template, second as additional terms specified in the permission field). These are not “permissions”, these are licenses. —Tacsipacsi (talk) 14:35, 1 May 2021 (UTC)

@Tacsipacsi and Jeff G.: To your arguments I agree: "small" licenses as PD-shape or PD-ineligible may fit into the description block, more or less. Complicated licenses don't, they create an own large block. A license may be of interest but it is not describing the file - when I do not want to reuse the file I won't care for licenses but I want to know about the file - so to me is much more of interest values of the parameters other versions and other fields, and may be geo-locations. If these informations are too far below because if a very large license in permission they are too much out of view and reach.

Most times the place below of the license header is better suited ! And then empty permissions are of no advantage. -- sarang♥사랑 16:43, 1 May 2021 (UTC)

@Jeff G.: A decade ago we had a big discussion about where to place licenses, and the side that argued for placing them in a new section won. We do not want to rehash those wars and definitely not start a edit war over moving licenses from one end of the page to another. I do not object to changing license location for your files (although uniformity would be less surprising to users), but please do not create any processes for license in other people's files. @Sarang: , I maintain the template but have no idea how the upload wizard works, and what you propose is Upload Wizard changes. The "see below" or other text like that was the standard over a decade ago. It is useless but might have been necessary back then to suppress warnings. I generally prefer template with no empty fields, but traditionally we kept all basic fields in the information template. I think removal of the permission field is not going to fix much as I think the upload wizard leaves it blank and I do not see users adding them later. However one can file a phabricator ticket to remove it, like the one we had for removal of "other fields" field from upload wizard output. --Jarekt (talk) 03:23, 2 May 2021 (UTC)

@Sarang, Tacsipacsi, and Jarekt: It was just a thought. I will not rehash those wars.   — Jeff G. ツ _{please ping or talk to me} 03:33, 2 May 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 03:27, 9 February 2022 (UTC)

Ips Correction

SET default ips Correction in pages for public health SULTAN UMAIR AHMED ARAIN (talk) 08:36, 15 May 2021 (UTC)

@SULTAN UMAIR AHMED ARAIN: What is "ips Correction"?   — Jeff G. ツ _{please ping or talk to me} 13:58, 15 May 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 03:33, 9 February 2022 (UTC)

Something wrong

Tracked in Phabricator
Task T286679

The template now displayed "Disgrifiad" , "Ffynhonnell" , "Awdur" even i am using Eng commons in the preference. Something wrong in the module? Matthew hk (talk) 23:38, 18 July 2021 (UTC)

@Matthew hk: You use British English (en-gb), don’t you? Someone mistakenly put Welsh translations on British English pages on translatewiki.net, see phab:T286679. The wrong translations have already been deleted on translatewiki.net and now they’re waiting to be removed from Wikimedia wikis as well. I hope the removal will happen at latest with the weekly software update on Wednesday. —Tacsipacsi (talk) 20:05, 19 July 2021 (UTC)

Yes. Hong Kong teach somesort of British English in old days. Matthew hk (talk) 03:44, 22 July 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 03:37, 9 February 2022 (UTC)

Something wrong II

In my current attempt to upload a new file (File:Logo-Kontrovers-BR-Fernsehen.jpg), I suddenly get 2 error messages after uploading:

• "This file is lacking source information. – Please edit this file's description and provide a source."
• "This file is lacking author information."

In reality, however, both specifications were made by me, as you can see in the source code.--Bestoernesto (talk) 00:12, 21 July 2021 (UTC)

You forgot to close {{De}}. Multichill (talk) 15:27, 21 July 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 03:38, 9 February 2022 (UTC)

"gallery tag"

The description of the "other versions" field says:

Links to files with very similar content or derived files; use thumbnails with {{F}} or gallery tags, e.g. {{G}}.

I am not sure where the "gallery tag" link is supposed to point, but I am pretty sure it is not supposed to point at the Wikipedia mainspace! (The target article does not exist anyway.) Brianjd (talk) 12:34, 21 November 2021 (UTC)

The link should point to Wikipedia:Gallery tag; I have fixed it. The problem was introduced in revision 378514089 by Sarang. Brianjd (talk) 12:44, 21 November 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 03:39, 9 February 2022 (UTC)

depicted person template recommendation vs template example

The first dot point in the description of the "description" parameter says to use the Depicted Person template to identify notable people, however the depicted person template is not used in the Piers Sellers example in the Example Usage section.

Shouldn't the example be updated to use the Depicted Person template?

Neuroxic (talk) 00:15, 20 June 2022 (UTC)

Having problems

I don't know why, but when I copy and paste the template and preview it, it fails. Templates don't work. The English version of Wikipedia's template succeeds. -- 61.120.241.1 14:06, 10 December 2022 (UTC)

What do you mean by “templates don’t work”? When I copy and paste the usage sample below, it works for me: it appears, and I can fill in the parameters. —Tacsipacsi (talk) 21:52, 10 December 2022 (UTC)

---

{{Information  |description = test  |date = 11 December 2022  |source = Own work  |author = 61.120.241.1  |permission = test }}

Copy and paste Template:Information. See File:Oku-Rib-Farm.JPG. No table is created.

DescriptionInformation/Archive 5	test
Date	11 December 2022
Source	Own work
Author	61.120.241.1
Permission (Reusing this file)	test

Copy and paste en:Template:Information. Table is created. I don't know why this is happening. I didn't have this problem until a few weeks ago. By the way, I'm using Firefox and Edge on Windows 11. --61.120.241.1 23:15, 10 December 2022 (UTC)

I fixed File:Oku-Rib-Farm.JPG. Lines  |description = etc. didn't start with a normal space but with an nbsp (U+00A0). --Achim55 (talk) 14:46, 11 December 2022 (UTC)

I got it！ I think NBSP should be removed on usage section. Thank you all respondents. --61.120.241.1 09:37, 12 December 2022 (UTC)