Template talk:Current

{{Recent}} vs {{Current}} vs {{Update}}

FYI, see Template talk:Recent#Difference between this and Template:Current. --Tomchen1989 (talk) 18:45, 30 June 2021 (UTC)[reply]

I've added some explanation here Template:Current#See also. --Tomchen1989 (talk) 19:08, 30 June 2021 (UTC)[reply]

Bad category title

many files in Category:Files that need updating dont "need" updating. "need" makes it sound like they "should/must" be updated but they're not. they may be updated if there is new info, but many dont have and wont have for a long time or forever. RZuo (talk) 11:10, 15 November 2023 (UTC)[reply]

How to update the many outdated files?

Lots of files are outdated, especially many charts in Category:Our World in Data have newer charts on WMC or at source even when they're in use.

What do you think about this, do you have any ideas how to address this in an efficient way? For example ways to automatically update charts and many charts at once and/or updating file-uses along with the image update.

I've created Category:Charts with newer versions available at the source which contain some examples (also relates to @RZuo: 's thread above which I agree with) and this as well as the Category:Charts by year of latest data categories which enable finding and updating outdated charts (an issue is that charts of earlier states are also useful; maybe it could become possible to use them in WP in a way that allows switching through prior versions or to pin which version is to be used, e.g. like [[File:img.png|v=2020|Description]]). Let me know if there already is some work on that, maybe some phabricator issue(s), or some current scalable/efficient practices. Prototyperspective (talk) 13:28, 12 March 2024 (UTC)[reply]

Prototyperspective. Need a way to redirect the existing OWID SVG files on the Commons to the PNG files on the Commons. Because SVG OWID files can no longer be uploaded or updated to the Commons. That is because they have the import-font URL in the SVG file.

And even if that URL is removed before uploading, then the Commons still only sees the first font listed in the font family. And often it is not a free font that the Commons has. So the Commons substitutes a free font that often does not work well with the image.

We could always reverse the redirect direction in the event OWID SVG files can again be uploaded to the Commons. In other words make the existing OWID PNG files redirect to the SVG OWID file on the Commons. --Timeshifter (talk) 07:19, 11 April 2024 (UTC)[reply]

I don't see how that relates to the question of how they could be updated well. With that I mean for example automatically or semi-automatically and maybe as part of some routine / collaborative effort.

Also I don't see why that would be needed: SVG files are still to be preferred. SVG files can be edited so this could be removed or not? Also OWID could change that and somebody should probably ask them about that. Could you do that? Prototyperspective (talk) 23:44, 11 April 2024 (UTC)[reply]

OWID has been asked. OWID prefers fonts of its own choosing, not the lame free ones provided by the Mediawiki software.

Phabricator threads have been done. The Mediawiki developers do not support automatically removing the import-font URL from the OWID SVG files.

So the hundreds or thousands of OWID SVG files on the Commons are not being updated. The simplest solution is the one I suggested: Redirect the existing OWID SVG files on the Commons to the PNG files on the Commons.

For new files people are uploading the OWID PNG files. So there is no problem there since the SVG files can't be uploaded easily, or with good results.

But the existing OWID SVG files on the Commons are used in many articles in many languages. To substitute a PNG file for all the article uses of a single popular OWID SVG file could take hours across many language wikis. Probably with many mistakes due to the different languages used even in the wikitext image coding. I know. I have seen this.

Currently, it is not possible to redirect an SVG file to a PNG file. Mediawiki developers would need to allow this. Maybe you can ask at Phabricator. I already did my time there, and don't have the time, energy, or health for this now. --Timeshifter (talk) 02:38, 12 April 2024 (UTC)[reply]

Okay good that somebody asked and thanks for your efforts and reply. I didn't know one of few particular fonts has to be used to avoid this error. If this obstructs the smooth, regular, quick updating of files, then something like accepting imports of fonts or automatically removing them should be done. Could you please link the phabricator issues? I'd like to put some additional support behind them.

For redirecting to PNG files: it seems like they differ from the SVG files. Maybe it needs a script that shows all file uses of the SVG files along with the equivalent/best-equivalent PNG for replacing the uses with the files that get updated. In any case, the best method probably would be to allow embedding interactive charts in Wikipedia and somehow import the SVG files for WMC. Prototyperspective (talk) 12:14, 12 April 2024 (UTC)[reply]

Mediawiki only allows free fonts to be used in SVG files that show on any wiki using MediaWiki. And only the free fonts in its list.

For OWID-related Phabricator threads here is "our world in data" (in quotes) search that pulls them up:

https://phabricator.wikimedia.org/search/query/63z3h6eXNRMb/#R

The developers in the Phabricator threads I participated in pooh-poohed the idea of removing the offending import-font URL in OWID SVG files. Maybe if more people ask for it they might do it. I have no idea.

The Commons page for an OWID SVG or PNG file shows all uses of the file across all languages of Wikimedia projects.

OWID always has both an SVG and a PNG file for any of their images. On the same download tab.

Automatic updating would be nice, but it would have to be the PNG files for now, unless Mediawiki removes the URL before uploading SVG files. I don't know if Mediawiki has ever done automatic updating of images.

Another problem is that Mediawiki substitutes a free font for the fonts in the font-family list in an OWID SVG file. That free font often does not fit the same, and messes up the image. Usually by extending past the edge of the image. So text is cut off. --Timeshifter (talk) 22:23, 12 April 2024 (UTC)[reply]

I wouldn’t like if MediaWiki tampered with my SVGs without asking me. However, it should be possible to create a Toolforge tool or maybe even a gadget that removes the @imports and the non-free fonts from the font lists (so that MediaWiki uses the free fonts specified by OWID rather than arbitrary ones) when asked to. It’s only a little bit less convenient than being able to upload directly, while it doesn’t come as a surprise to users, doesn’t have to be accepted by developers of MediaWiki itself, and it can be tailored down to OWID files rather than being a generic solution. —Tacsipacsi (talk) 10:06, 13 April 2024 (UTC)[reply]

That would be nice. I suggested at Phabricator that it should be an option, not a requirement, whenever the @import warning shows up during an SVG upload. So that one could OK its removal, and the upload could continue. That suggestion hasn't gone anywhere yet. Maybe if others asked for it too....

I like the non-free font removal option even more. Because I have found fonts to be even more of a problem then the @import removal.

But there are many OWID SVG files on the Commons, and having to go to Toolforge to take all these extra steps each and every time an OWID SVG image needs to be updated, will discourage most updating.

If it were an option offered during SVG uploading, and only required a checkbox, then it would work, I believe.

There may be some non-OWID SVG images that need @import and non-free fonts removed too. Any image uploaded to the Commons has to be a free image that can be altered, so there is no need to limit either the Mediawiki or Toolforge option to OWID images.

I would use the Toolforge option for some SVG images. --Timeshifter (talk) 15:52, 13 April 2024 (UTC)[reply]

If it were an option offered during SVG uploading, and only required a checkbox, then it would work, I believe.

The gadget solution (if possible) would work much like that, except that one would have to turn on the gadget once. (The warning could instruct users to do so, although this could pose issues with translation of the warning message.)

There may be some non-OWID SVG images that need @import and non-free fonts removed too. Any image uploaded to the Commons has to be a free image that can be altered, so there is no need to limit either the Mediawiki or Toolforge option to OWID images.

The problem is that while such removals are hopefully safe in OWID graphs (they look mostly the same afterwards), this is not generally true (font removal could lead to exactly the same display issues that OWID graphs currently have or even to unreadable text if a special font like Wingdings is removed, import removal to all sorts of missing styling). —Tacsipacsi (talk) 14:54, 14 April 2024 (UTC)[reply]

Maybe have both. A gadget and something at Toolforge.

So the tool would remove the @import URL and the fonts not available on Mediawiki. Then you could look at the resulting image and decide whether to upload it or not.

The gadget would be for OWID images, and it would work while uploading anytime its box is checked. So before an OWID SVG upload one would enable the gadget somehow. Then the following upload would automatically have its @import URL removed, and its non Mediawiki fonts removed. --Timeshifter (talk) 02:04, 15 April 2024 (UTC)[reply]

Manual updating of used files

Until there is some more routine automated mechanism for updating charts (discussed above), this method could be used to identify old charts to either replace or update them with a new version:

one can use the GLAMorgan tool to find uses of files in the subcats of Category:Charts by year of latest data (and Category:Maps of the world by year) such as used charts showing data up to 2014.

When it comes to OWID, most of these have a newer version available at source and one could go through each of those categories one by one, possibly even routinely & systematically (note that as new files could get added to these categories it would be best if files would be locally or publicly marked as checked at a scan/time).

Tracked in Phabricator
Task T363202

Maybe some WikiProject or something could be set up who do this updating. Please let me know if somebody is setting something like that up or proposed it somewhere. These cats and GLAMorgan could also be used to replace or complement (e.g. click to switch from image to interactive element) datagraphics with interactive visualizations once these are finally available on Wikipedias (see the issue on the right).

--Prototyperspective (talk) 20:11, 6 July 2024 (UTC)[reply]

I think I read somewhere that Mediawiki software now can read all of the font family in an SVG file, as it used to do. I don't know if this is true. If so, then there is no need to delete all fonts not usable by Mediawiki software before uploading. If it is working as before, then I believe it goes through the font family list until it finds a font it can use, or one it can substitute for from its fallback font list. I don't know if it searches through the whole font family list for a free one before substitution. Or if it substitutes earlier on.

So that means only the @import line needs to be removed. --Timeshifter (talk) 23:36, 6 July 2024 (UTC)[reply]

This is offtopic to this subsection and not relating to things I wrote above. Yes, I recently uploaded a few OWID files and only needed to remove the one @import line in the svg to make it work but that shouldn't be required either. Prototyperspective (talk) 14:18, 7 July 2024 (UTC)[reply]

Small addition: when charts have been updated – which is often done in whole batches where one can do this from the uploader's uploads page (uncheck "Include old versions of files) using cat-a-lot – one can use a search like the following to remove the cat from the earlier year(s) (in this example charts until 2021 have been updated to 2022): run this a few hours after adding the newer cats. Old charts are often still used in non-English language Wikipedias and only rarely is that article about a particular year or otherwise better served with an outdated chart or map. Prototyperspective (talk) 14:08, 21 July 2024 (UTC)[reply]

Efforts to view OWID charts

We are currently working on a way to view stacks of OWID slides. Once we have this working better we are planning on once again mass uploading OWID, but this time all years including all subregions of data.

We are planning on going with svgs as we want to preserve the ability to translate the slides and make the final output multilingual. If other are interested in joining in this effort please reach out. We have a contracted programmer working on it. Doc James (talk · contribs · email) 11:30, 9 July 2024 (UTC)[reply]

Doc James. That's terrific:

https://mdwiki.org/wiki/WikiProjectMed:OWID#Way_5_(being_built)

I believe most OWID images are interactive, and so by putting those on Wikipedia we also solve the problem of the non-interactive images being up to date. Let me explain:

We substitute the interactive image for the static image in Wikipedia articles. As long as there is a link back to the OWID page, one can download the static image. Or if the OWID stuff is truly fully mirrored on the Commons, then one can go to the page on the Commons and find the static image.

People copy the static images all over the web. And they often find those static OWID images first on Wikipedia pages.

I would love to put this OWID interactive world map on List of countries by intentional homicide rate:

https://ourworldindata.org/grapher/homicide-rate-unodc

There a slide bar by year on it. The static image download is for that year.

I hope there is a donation link to OWID on all the OWID interactive files on the Commons.

I wonder if it would be possible to hot-link an OWID interactive image from the Commons to other wikis such as Fandom or Shoutwiki. I am an admin on both. See:

Commons:Reusing content outside Wikimedia/technical

--Timeshifter (talk) 13:46, 12 July 2024 (UTC)[reply]

There are several issues with this: one can't hover over items in the datagraph (like a country or a line) to see more detailed text and labels and there would need to be some kind of OWID importer because for every time this thing is used one would have to download all the OWID images (and currently one even has to edit them to remove the @import line. I think displaying a selected static image (like the latest or most relevant or most data-comprehensive year) and just a button to load the interactive element in its place would be better. See my comments here. Also it doesn't solve the updating as the images would need to manually be imported just like it's the case now. This is not an "interactive image" but a stack of several static images. Please fix the issues with Way 2 and implement that. Prototyperspective (talk) 14:29, 12 July 2024 (UTC)[reply]

I'll take what I can get. My understanding is that Way 5 is the best we can get due to various WMF privacy/security concerns. You are right that the source page has more info by hovering over a country:

https://ourworldindata.org/grapher/death-rate-smoking

But the stack of yearly images at MDwiki is interactive by dragging the right-side slidebar.

Way 5 solves the problem of updating the images. My understanding is that it is done automatically at a mass level. And that is where the paid programmer is needed to maintain it.

We should link back to the OWID source for further interactivity. As I just did for an OWID map here:

List of countries by intentional homicide rate. That PNG OWID map was already uploaded. So I used it rather than going through the hassle of preparing and uploading an SVG map. See reference for it:

Homicide rate. Our World in Data. Interactive map at source. With yearly slide bar. Hover over country to see graph timeline of rate.

--Timeshifter (talk) 14:56, 12 July 2024 (UTC)[reply]

-- We should have something more to show in a few weeks. Doc James (talk · contribs · email) 16:15, 12 July 2024 (UTC)[reply]

Make template more compact

It is requested that an edit or modification be made to this protected page.
Administrators: Please apply <nowiki> or {{Tl}} to the tag after the request is fulfilled.

Get rid of the line break, so that the text is more compact on narrower screens.

This is more compact. Narrow your browser window to see:

This file may be updated to reflect new information. If you wish to use a specific version of the file without new updates being mirrored, please upload the required version as a separate file.

The icon needs to be made a little smaller too. So that the banner is less tall and less wide, and so that there is more room for text. Larger icons can make some banners too tall. This may be why some people complain about there being too many templates. They would complain less if they were less tall, especially in smaller screens like cell phone screens.

Compare at narrower screen widths. Existing template at narrower width so you can see what it looks like on a narrower screen:

This file may be updated to reflect new information.
If you wish to use a specific version of the file without it being overwritten, please upload the required version as a separate file.

Version with smaller icon and no line break. Div-wrapped at 485px width so you can see what it looks like on a narrower screen:

This file may be updated to reflect new information. If you wish to use a specific version of the file without new updates being mirrored, please upload the required version as a separate file.

--Timeshifter (talk) 21:24, 20 August 2024 (UTC)[reply]

User:Timeshifter Can you provide the code with desired changes? --Jarekt (talk) 20:03, 23 August 2024 (UTC)[reply]

I think the code might be here:

https://commons.wikimedia.org/w/index.php?title=Template:Current/i18n/en&action=edit

I would like the line break (<br>) removed. That would make the banner less tall on mobile phones.

Also, I would like the icon to be smaller. So that if it were removed, the height of the banner would be the same. Right now it is too large. It is making the banner taller on PC screens:

This file may be updated to reflect new information.
If you wish to use a specific version of the file without it being overwritten, please upload the required version as a separate file.

--Timeshifter (talk) 11:19, 24 August 2024 (UTC)[reply]

Scope of category added by this template

Please note Commons:Village pump/Archive/2024/08#Category:Files that need updating.

In the meantime, the number of files in Category:Files_that_need_updating fell from about 105,000 to 1,000. Enhancing999 (talk) 10:50, 10 August 2024 (UTC)[reply]

Clarify template. "Mirrored"?

"mirrored" does not make sense to me. See template:

This file may be updated to reflect new information.
If you wish to use a specific version of the file without it being overwritten, please upload the required version as a separate file.

Here is just the text. It has been edited. This is clearer:

This file may be updated to reflect new information. If you wish to use a specific version of the file without it being overwritten, please upload the required version as a separate file.

--Timeshifter (talk) 21:31, 20 August 2024 (UTC)[reply]

User:Timeshifter,

Done --Jarekt (talk) 18:06, 23 August 2024 (UTC)[reply]

Thanks! --Timeshifter (talk) 11:11, 24 August 2024 (UTC)[reply]

Template talk:Current

Contents

{{Recent}} vs {{Current}} vs {{Update}}

Bad category title

How to update the many outdated files?

Manual updating of used files

Efforts to view OWID charts

Make template more compact

Scope of category added by this template

Clarify template. "Mirrored"?

Navigation menu

Template talk:Current

{{Recent}} vs {{Current}} vs {{Update}}

Bad category title

How to update the many outdated files?

Manual updating of used files

Efforts to view OWID charts

Make template more compact

Scope of category added by this template

Clarify template. "Mirrored"?

Navigation menu

Search