Module talk:Information

Extra paragraph + break

@Jarekt: the page is outputting an extra paragraph and break, which creates too much space after the infobox (link). I couldn't figure out the source of this; can you take a look?

@Magog the Ogre: , which file did it happen to? BTW most discussions on related subjects are at Template_talk:Information#Current_status --Jarekt (talk) 05:08, 14 November 2019 (UTC)

@Jarekt: it's on every page, as far as I can tell. The screenshot is from File:Urumqi Glacier No. 1 Annual Mass Balance.png. Magog the Ogre (talk) (contribs) 00:30, 15 November 2019 (UTC)

@Magog the Ogre and Jarekt: this sounds like it could be the same issue as what I reported at phabricator:T238390? --Lucas Werkmeister (talk) 00:54, 15 November 2019 (UTC)

@Magog the Ogre: I do see <p><br /></p> in here and here, but I do not see it here or here. Strange. --Jarekt (talk) 03:37, 15 November 2019 (UTC)

I just verified that {{Information/sandbox}} does not seem to have this issue. I suspect the issue was fixed with this edit. --Jarekt (talk) 03:38, 15 November 2019 (UTC)

Wikibase design issues

With respect to how this module deals with Wikibase data it seems inefficiently and poorly designed. The only Wikibase data access (calls via mw.wikibase namespace) in this entire module is via the fairly expensive mw.wikibase.getEntity function and the rest of the code then depends on parsing entire mw.wikibase.entity structures. This includes external API functions (exported functions that do not take a single frame argument; they are all named with leading underscores and are intended to be called from other Scribunto modules—not invoked from MediaWiki templates) which expect an entire entity structure to be passed to them which in turn requires callers to make expensive calls to mw.wikibase.getEntity. This should be redesigned to make more optimal calls to mw.wikibase.getLabelByLang and mw.wikibase.getBestStatements (I also notice the module always blindly just takes the first claim matching a specific property not the "best" which means it may use claims marked "deprecated", etc.; for now that might be safe enough for SDC since the editor used by regular users does not seem to allow one to make such claims but it should probably be written to be safer like generalized WD code would be). In my opinion the bigger issue is with exposing API functions that require entire entity structures to be passed around thus requiring the caller to make expensive Wikibase calls; these should probably be rewritten to pass around entity IDs and not entire entity structures themselves, however, since they are exposed, such changes impact all potential callers. —Uzume (talk) 12:43, 20 April 2020 (UTC)

Also since this seems to target specifically SDC MediaInfo items and not WD items, it makes sense to switch this module from the mw.wikibase API to the more specific mw.wikibase.mediainfo API (I realize SDC-MI items and WD items use the same WD property pool for their statements: claims, qualifiers, and references). Also I am confused by the naming of _SDC_Description which seems to access Wikibase labels and not Wikibase descriptions. Perhaps it would be better named _SDC_Caption (and perhaps mw.wikibase.mediainfo.getCaptionByLang should be considered though the current code also seems to iterate over all the labels and that might be hard without the entire entity structure). —Uzume (talk) 15:42, 20 April 2020 (UTC)

@Uzume: It’s possible to set preferred rank through the UI (in addition to the normal rank), but it’s called “prominent” rather than “preferred” (which makes sense for depicts statements, but not so much for other properties…). Deprecation is not possible AFAIK. Passing whole entities: I’m not very familiar with the module, but while most of the time loading whole entities has a negative impact on performance, if they need to be loaded anyway for whatever reason, passing the loaded objects can improve performance. So getting rid of such expected parameters by any means, without taking the context into account—which is how I interpret your above comments—is not a good strategy. Also passing whole entity objects can make it possible to create reliable units, which won’t break just because edits to file pages/Wikidata items. —Tacsipacsi (talk) 23:13, 23 April 2020 (UTC)

@Tacsipacsi: I knew about "prominent" but did not think it meant "preferred" in that context (I should have considered that but frankly I just did not really think about it too much). That is good to know. I understand there is much to consider for performance design. I was not just trying to get rid of passing complete entity structures "by any means, without taking the context into account". I want it considered—in context. I understand due to spacial and temporal locality it can sometimes improve performance but I am pretty sure in this case any minimal locality gains are (on average) outweighed by the losses of extraneous accesses in obtaining and traversing more data than is necessary (I realize the API uses some metatable techniques to fetch some larger pieces of data like statements on demand and employs caching, etc. so the impact is not as horrendous as it originally was in the beginning) and negative temporal locality (due to the large size of unneeded data, .i.e, potential cache evictions, etc.). I was actually planning to work up something in the sandbox making the parameter optionally an entity ID or the entity structure. It has not been my top priority yet though so, I will get there when I get there (and maybe someone will beat me to; that is how the world works). Performance design aside, I was actually more concerned with API design and locking us into having to pass entity structures around. Even if that is currently optimal from a performance standpoint (which I very much doubt), that might not always be the case and there are issues like cohesion, information hiding, etc. that seem more important for future flexibility. —Uzume (talk) 23:58, 23 April 2020 (UTC)

@Uzume: , Sorry I did not notice this discussion. I will addrress some of the issues you raise:

• accessing statements via item ID or via entity. I was working under assumption that, like on Wikipedia, mw.wikibase.getEntity() call to access your own properties is cheap while mw.wikibase.getEntity(item) to access someone else's properties is expensive. So the most efficient way is to get the whole entity once and then parse it, as opposed to multiple calls to get each statement separately. Also biggest Commons entities seem to be much smaller than biggest Wikidata ones.
• I agree that we should be using "getBestStatements" whenever possible. In the past this function did not seem to work on Commons entities, which forced me to rewrite the code to access statements without using it. If it works well now, than perhaps we should switch back.
• Function names like _SDC_Description ae named after infobox field they fill, not after name of property where the info come from. In Information template there is mostly 1:1 ratio between them, but in Module:Artwork, where this practice started, there is a lot of many-to-one relationships.
• About mw.wikibase vs. mw.wikibase.mediainfo functions to call, I have no idea what is the difference. Originally there was only mw.wikibase which began to support M-codes of Commons entities at some point, so we began to use it. Latter mw.wikibase.mediainfo was introduced. I think in cases where we know that we will be accessing only commons entities than mw.wikibase.mediainfo should be used.

I think I addressed all the issues. Thanks. --Jarekt (talk) 13:41, 24 April 2020 (UTC)

Mobile version

Following a series of similar projects on dewiki, I wanted to suggest making the template responsive. This requires only one simple change: sandbox. With Module:Information/styles.css, all information tables on a screen width below the breakpoint of 720px (mobile devices) will be displayed vertically. Regards, XanonymusX (talk) 20:26, 2 February 2021 (UTC)

@XanonymusX: Thanks for preparing this change! In general, I’m also a big fan of responsive design; however, there are two points I don’t agree with:

• Centering. I think it looks ugly with everything centered. What about making only the “left column” (i.e. the blue cells) centered?
• Affecting everything within the table. This is definitely a bug, it causes side effects for example in the World Heritage template on the sandbox talk page. The style should apply only to the table this module generates, i.e., it should use the child selector > instead of the general descendant selector (space).

Also please note that there are some other templates using the same styles; this patch (loading the very same TemplateStyles page) should be applied there as well. —Tacsipacsi (talk) 19:56, 5 February 2021 (UTC)

• Well, I just went for the simplest possible change. In the templates I usually work with, centering everything is the best solution, but I agree that with longer descriptions that can actually make it harder to read. If we go only for the first column, we need to target those specifically by class, which makes it a little more complex (certainly doable though).
• No, it’s actally meant to be a feature! ;) I am not sure which side effects you are referring to in the example (I have added an !important now to have the width behave the same on the mobile version and in the desktop version), although the problem with the World Heritage template is that it shouldn’t be a table in the first place (as a regular div it would not be affected). It is of course a certain risk to have the styles affect all the potential contents of the description, but it is part of a cost-benefit analysis: if there are still tables (real ones, like the photographer vcard) within the description, they will still ruin the mobile view most of the time by being way too broad to fit into the one-column layout, and then the change does not improve anything. While even if some tables should happen to be adversely affected, it would only be an aesthetic problem again, the information is still the same. I have no overview over all the different tables that could come up in Commons descriptions though, so my cost-benefit analysis might be faulty. For now, I have added the styles to my global.css and am going through random pages on mobile.
• If the same styles are used in cases that should not be affected, we would have to add a new class to this template specifically for the responsiveness. Otherwise it could also be an option to add the styles to the Common.css in the long run. Oh, and of course Template:Artwork and the likes would be candidates for the same change.

--XanonymusX (talk) 20:42, 5 February 2021 (UTC)

• I think it looks pretty ugly, so yes please!
• Well, then it’s a bad feature, you can’t assume anything about the contents of the information template. For example, the vcard becomes uncloseable (as your display:block overwrites the display:none used to close it), and the birth/death data becomes hard to understand thanks to the ruined colspans. And this is just one template, there are endless possibilities to (ab)use tables that could be ruined by your generic rule. And even without making changes to embedded templates, there is gain: the width of the left column. Not perfect, but still better. (Not to mention pages that don’t include other tables in the information table: these could be fixed entirely with the more restrictive rules as well.)
• I don’t know of any cases that should not be affected, only about other templates that should be affected as well. I don’t think Common.css is a good solution in the long run, though: it doesn’t load on mobile, it doesn’t load on foreign wikis (the rules have to be repeated in MediaWiki:Filepage.css), and in general, it makes the connection between the template and its styles less explicit.

—Tacsipacsi (talk) 02:55, 8 February 2021 (UTC)

Okay, I see. Then let's go for a less risky method; I will work on it!--XanonymusX (talk) 17:29, 8 February 2021 (UTC)

As vector-2022 is influencing the way this template is rendering (toccolours), I picked up this issue again. I've prepared changes in the sandbox and to the CSS page to handle both vector-2022 and to improve mobile rendering. —TheDJ (talk • contribs) 19:54, 21 January 2023 (UTC)

I have chosen not yet to deal with the case of the "missing information" box. I think this thing should be split off into a separate module with its own style module. —TheDJ (talk • contribs) 20:43, 21 January 2023 (UTC)

Add "Depicts" from Structured Data

I'd like to suggest adding "Depicts" from Structured Data to "other_fields". This would show the information from structured data on the front page. "Depicts" is an excellent addition to the "description" information which is to often empty, poor, or only in one language. I would cover the insert with an IF to show nothing if the "Depicts" data in structured data is empty.

The follwing code is derived from Template:Geograph from structured data

{{#if: {{#property:P180|from=M{{PAGEID}}}}|{{Information field
 |name  = {{Label|P180|link=-|capitalization=ucfirst}} 
 |value = {{#property:P180|from=M{{PAGEID}} }} [[File:OOjs UI icon edit-ltr-progressive.svg |frameless |text-top |10px |link={{fullurl:{{FULLPAGENAME}}}}#P180|alt=Edit this on Structured Data on Commons|Edit this on Structured Data on Commons]]
}} }}

Sebastian Wallroth (talk) 09:49, 20 January 2022 (UTC)

require('strict')

{{Edit protected}} As per the new lua feature mentioned at m:Tech/News/2022/42, could require('Module:No globals') be replaced with require('strict') -- WOSlinker (talk) 17:26, 25 October 2022 (UTC)

 Done. Jonesey95 (talk) 04:47, 26 October 2022 (UTC)

Replacement of deprecated attributes

{{Editprotected}} In line 101, cellpadding="4" should replace to border-spacing: 4px;. It's a deprecated attribute in HTML5. See here for more information. Baris6161TURK (talk) 21:19, 7 January 2023 (UTC)

I've prepped this change in the sandbox. —TheDJ (talk • contribs) 19:19, 21 January 2023 (UTC)

This was done. —TheDJ (talk • contribs) 15:14, 28 January 2023 (UTC)

Improving the specification for Information templates

Because of TemplateStyles I've been going through the template information variants a bit, and trying to wrap my mind around them. Unfortunately due to various flukes of history some bad decisions were made and I think it is time we deal with some of them.

These are the current problems

1. There is a div around the information template, but we don't know why...
2. This div has class commons-file-information-table, but is not the table itself
3. Sometimes this div is followed by "stacked" additional cells. These cells are wrapped in a table with the class commons-file-information-table, but they don't share the same structure as the div with that classname
4. The main tables (those wrapped with divs) carry fileinfotpl-type-subtype classnames. but no other distinct class that indicates they are part of the fileinfotpl system.

Because of this it's actually hard to share styling for these template right now, because we have mixed areas, with specific elements and semantic classes with metadata and styling classes.

Additional problems:

1. Commons metadata uses ids for fileinfotpl- metadata fields (these should probably have been classes)
2. Row headers are currently styled cells
3. The table header is a plain row instead of a table caption
4. There are 'third' cells sometimes, but these are purely visual, they have no machine readable meaning and they also mess with potential mobile layouting of a data table
5. There are nested tables for the purpose of layouting EVERYWHERE (especially in the wikidata stuff it seems)
6. There is still lots of valign, cellpadding and other deprecated html

I've started writing down some new rules for myself in: Module:Information/styles2.css, with which i will experiment in the sandbox for Module:Artwork. I welcome some input on them. —TheDJ (talk • contribs) 15:14, 28 January 2023 (UTC)

Commons metadata uses ids for fileinfotpl- metadata fields (these should have been classes): unless ids are duplicated, there should be no downside to keeping the ids while adding class names. Then anything that exists that relied on these being ids won't break. - Jmabel ! talk 18:40, 6 February 2023 (UTC)

yes, it was not the intent to remove them (at least at this time). —TheDJ (talk • contribs) 21:27, 7 February 2023 (UTC)

Proposal: Move template styles to site-wide CSS

{{Information}} and its module and /styles are among the most transcluded pages on Commons, and the number of transclusions is putting serious strain on the database (see discussion in T343131). Ladsgroup suggested that we can improve this by moving the styles to site-wide CSS, to remove the 85 million (and counting) template links to Module:Information/styles.css. Specifically, I propose that we:

1. Copy the contents of Module:Information/styles.css to MediaWiki:Filepage.css, with a big comment pointing out that it must be kept in sync with /styles.css;
2. Also add such a big comment to /styles.css, pointing out it must be kept in sync with Filepage.css, and protect the page so that it can only be edited by interface administrators;
3. Modify Module:Information (Build_html() function) so that it skips the templatestyles inclusion if used in the File namespace; optionally, we could also add a check of mw.site.server, so that on external wikis that copy the module’s code, the templatestyles would still be used (since they might not have copied the Filepage.css).
4. Optionally, set up some automated process that alerts interface admins if /styles.css and Filepage.css diverge. But I’m not convinced this is needed, tbh.

External wikis that use files from Commons via the InstantCommons feature also import Commons’ Filepage.css (see MediaWiki code), so by putting the files in Filepage.css rather than common.css, we ensure that the information box still looks correct on those wikis; the namespace check in step 3 (and keeping /styles.css rather than deleting it) is then needed to keep the information styles when the template is used outside the File namespace, where Filepage.css isn’t loaded. (This means there will still be some templatelinks to the /styles.css, but only some 27 thousand rather than 85 million.)

Does this sound okay? CC people who have edited the module recently: Jarekt, TheDJ, Jonesey95.

I’m happy to make these changes myself if there is agreement, though I’ll need a sysop to do the protection change in step 2. (But that could be done at any time, and frankly the page should have some level of protection already, given how widely used it is.) Lucas Werkmeister (talk) 13:41, 20 January 2024 (UTC)

Lucas Werkmeister, I never got into CSS much, so I have no opinion on proposed changes and will be happy to assist with any edits. I added protection to Module:Information/styles.css and yes it is crazy that it did not had any. Last edit was by a mobile edit by IP, luckily it did not look like vandalism. Ping me if you need help with any edits. --Jarekt (talk) 15:39, 21 January 2024 (UTC)

Generally it sounds good to me. Thank you for doing this. Amir (talk) 13:04, 24 January 2024 (UTC)

I’ve implemented this at Module:Information/sandbox now; see Special:Diff/844949633 (CC @Jarekt). You can see it in action at File:Zusammen gegen Rechts Berlin 2024-01-21 - Lucas Werkmeister - 01.jpg and User:Lucas Werkmeister/sandbox; of course, as long as MediaWiki:Filepage.css hasn’t been updated, the file has broken styles. If this looks okay to you and nobody objects, I think we can go ahead with the other steps in a few days. Lucas Werkmeister (talk) 19:31, 24 January 2024 (UTC)

Lucas, All I can see at the moment is that the test file has (as you said) broken styles, while the same template copied to a different namespace looks fine. The code change looks fine. --Jarekt (talk) 02:31, 25 January 2024 (UTC)

After step 1 we can check that the test file looks correct again before implementing step 3 :) Lucas Werkmeister (talk) 21:32, 25 January 2024 (UTC)

A potential complication I only just realized, which fortunately turns out to be fine: you can have pages in the File namespace without an actual file (e.g. subpages like File:Alignment chart.png/author, or redirects; there are also some files like File:(Toulouse) Shiva accompagné par deux divinités - Cambodge Style de Baphuan - Musée Labit.jpg that seem to be broken somehow); but those pages do load MediaWiki:Filepage.css, so we don’t need to distinguish them in Module:Information – checking the namespace is still enough. Phew :) Lucas Werkmeister (talk) 16:38, 27 January 2024 (UTC)

Steps 1 and 2 are (mostly) implemented. (I would still like to see /styles.css protected a bit more strongly, but it’s not urgent.) Right now, the table in File:Zusammen gegen Rechts Berlin 2024-01-21 - Lucas Werkmeister - 01.jpg still looks broken – let’s see if there’s just a cache on Filepage.css, I guess… Lucas Werkmeister (talk) 21:04, 30 January 2024 (UTC)

It looks correct now (\o/), so if I don’t hear any objections, I’ll make the Module:Information change (step 3) tomorrow. Lucas Werkmeister (talk) 22:04, 30 January 2024 (UTC)

Step 3 done. @Jarekt: Can you change the protection on Module:Information/styles.css so only interface admins can edit it, to match Filepage.css?

Also, one consequence I only realized recently is that this affects the “Preview page with this template” feature; I wrote this down at Module talk:Information/styles.css as a caveat when editing those styles, but it also applies when you’re working on Module:Information – when you preview a file there, the table will look broken because the module will (correctly) skip adding the templatestyles, but filepage.css isn’t loaded on the preview. I’m not sure what’s the best place to document this for Module:Information, to be honest. Lucas Werkmeister (talk) 19:06, 31 January 2024 (UTC)

Lucas, I do not seem to be able to change protection of Module:Information/styles.css to interface admins. not sure why. I also noticed that MediaWiki:Filepage.css is not protected. Should it be? I will keep in mind the issue with “Preview page with this template” feature. Thanks for working on this. I am working on Module:Self to replace 7 templates called by {{Self}}. --Jarekt (talk) 01:29, 1 February 2024 (UTC)

@Jarekt Interface admin is not a protection level for normal pages, it is implemented only in the MediaWiki namespace. All MediaWiki namespace pages that end in .css or .js, in addition to certain interface messages that contain raw HTML, are automatically protected to the interface admin level. Interface admin-level protection is not required for TemplateStyles pages because they use a sanitized subset of CSS that prevents the use of dangerous properties. Template editor protection is sufficient. AntiCompositeNumber (talk) 02:14, 1 February 2024 (UTC)

@AntiCompositeNumber: But the reason I’d like the page to be restricted to interface admins is unrelated to dangerous properties. If styles.css and Filepage.css should be kept in sync, and Filepage.css can only be edited by interface admins, then it follows that non-interface admins can’t correctly edit styles.css either – they would have to file an edit request for Filepage.css anyway, at which point they might as well leave the styles.css edit to the interface admin fulfilling the edit request as well. I’d like to enforce this working mode via page protection, but if that’s not possible, then I guess we just have to live with the risk of the pages going out of sync until someone notices. Lucas Werkmeister (talk) 20:34, 1 February 2024 (UTC)

@Lucas Werkmeister concerning "I’m not sure what’s the best place to document this for Module:Information, to be honest.": Maybe at Template:Editnotices/Page/Module:Information? --Marsupium (talk) 12:03, 1 February 2024 (UTC)

@Marsupium: Sounds good; should the edit notice use some kind of template or can I just put plain text in there? Lucas Werkmeister (talk) 20:37, 1 February 2024 (UTC)

Hi, I've never written one myself, but looks like {{Editnotice}} is used. --Marsupium (talk) 21:47, 1 February 2024 (UTC)

 Done, thanks. Lucas Werkmeister (talk) 13:06, 4 February 2024 (UTC)

Just to mention it here as well: it turns out that the styles are currently missing from previews when editing file pages without VisualEditor. (First reported on my talk page.) I’ve already submitted a fix for this in MediaWiki core (T356505), so it should be resolved next week. Lucas Werkmeister (talk) 13:08, 4 February 2024 (UTC)

This should be resolved now. Lucas Werkmeister (talk) 14:46, 6 February 2024 (UTC)

Proposal: Evaluate SDC P1259 (coordinates of the point of view)

Currently, Module:Information seems to evaluate location of creation (P1071) (11,379,180 files) and location (P276) (13,108 files), but it ignores coordinates of the point of view (P1259) (4,151,113 files). If the textual file description doesn't contain {{Location}}, there's no hint in the file description that the file already is geocoded. Since coordinates of the point of view (P1259) is much more common than location (P276), i think it would be justified (and useful!) to include coordinates of the point of view (P1259) as something like function p._SDC_Object_Location (i'm not sure if this is sufficient to make a coordinates of the point of view (P1259) value appear in {{Information}} by default...). Fl.schmitt (talk) 19:56, 20 September 2024 (UTC)

Additional data: I've scanned two arbitrarily selected multistream dump archives for file pages with coordinates of the point of view (P1259), having {{Information}} but no {{Location}}. The first archive had 499,936 file pages with SDC P1259. From those, 1,258 file pages lacked {{Location}} (~ 0,25%). The second had 147,179 file pages with SDC P1259. From those, 2,053 file pages lacked {{Location}} (~ 1,4%). So, only a relatively small number of file pages doesn't "show" a location that's present in SDC, but I think even this "small" number would justify evaluating coordinates of the point of view (P1259) by default, too. This could also solve the issue of discrepancies between "manually" added {{Location}} and SDC Location. Fl.schmitt (talk) 20:28, 20 September 2024 (UTC)

Add QuickStatements link to transfer data to SDC

It would be nice if the module added an icon with link to QuickStatements to transfer data to SDC akin to the functionality of Module:Artwork and complementing the work of BotMultichillT and SchlurcherBot to add source of file (P7482), creator (P170) and inception (P571). That would allow to easily move data manually and even out of the preview without need to save it in wikitext before. --Marsupium (talk) 16:39, 2 November 2024 (UTC)