Template talk:Information

Active discussions

Rewrite in LuaEdit

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 informationEdit

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 ?Edit

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 generationEdit

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

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 statusEdit

So my understanding is that:

  • 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
  • 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, 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:
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 VersionEdit

@Zhuyifei1999, 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 FlickrEdit

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 templateEdit

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)

Missing label for source will cause LUA errorEdit

@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)
Return to "Information" page.