Template talk:Taken on

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 3 days.

Archives 1

Threads older than 720 day(s) may be archived.

Edit request: addition of new "subject=" parameter

{{Edit request}} I request the addition of a new "subject=" parameter.

At the moment, an editor can specify a "location", and the template will then automatically categorise the photograph as "[location] photographs taken on yyyy-mm-dd". But there are also certain subjects that should similarly be categorised in this way. At the moment, eg, there are "Category:Aviation photographs taken on yyyy-mm-dd" (currently there are 321 categories in this form) and "Category:Railway photographs taken on yyyy-mm-dd" (currently 7527 such categories). Similar subject categorisations might be created in future, eg "Category:Water transport photographs taken on yyyy-mm-dd".

So I request that this template be amended such that if it is configured as, eg, {{Taken on |subject=Aviation |location=Japan |yyyy-mm-dd}}, it will automatically categorise the photograph as both "Category:Aviation photographs taken on yyyy-mm-dd" and "Category:Japan photographs taken on yyyy-mm-dd". Thanks in advance. Bahnfrend (talk) 04:34, 18 December 2023 (UTC)

 Not done Bahnfrend, I am not a big fan of automatic categories added by templates, unless they are some sort of maintenance categories. One issue is that sometimes those categories do not make sense for a given file and people end up removing otherwise useful templates to fix categorization problems. Another issue is that it is unclear how those categories got there, breaking en:Principle of least astonishment. --Jarekt (talk) 04:04, 19 June 2024 (UTC)

Edit request: parameters to suppress specific categories

{{Edit request}}

Currently, videos of the Sun clutter the category Category:Videos of 2023 (maybe also some other cats). It's fine if for example the Category:2023-12-30 is set, I'd only like to suppress the automatic addition of this specific category.

It would be better if one auto-set category can be set as a parameter, it's surprising this isn't already possible. If it was possible, one could set a category like Category:Videos of the Sun in 2023 by SDO (see Category:Videos from the Solar Dynamics Observatory) as a parameter in Template:NASA SDO/date.

Please make it possible to define which category is suppressed or whether or not the "Videos of {year}" category is suppressed (would favor that for now) and/or which category is set in place of "Videos of {year}". Prototyperspective (talk) 13:46, 31 December 2023 (UTC)

Please implement this, can't edit the page. Videos of 2023 and other categories are still mostly filled with SDO videos of the Sun. Prototyperspective (talk) 14:03, 17 March 2024 (UTC)

Prototyperspective, One can suppress addition of any automatic category by setting "|cat=no" parameter. Then one can add any category they want to individual files. Would that solution work for you? --Jarekt (talk) 04:11, 19 June 2024 (UTC)

Thanks, it's better than nothing but it would only be a temporary solution because it would be good to keep the other cats. Another issue is that it would be difficult to edit so many files at once so some script/tool would probably be needed. However, the files are now gone from Videos of 2023 etc so this seems solved now even though I don't know how, maybe @Don-vip: solved it. I still think a parameter to suppress a specific auto-set category or the year category in specific would be useful but the problem seems solved now. Prototyperspective (talk) 13:54, 19 June 2024 (UTC)

Use of the location parameter for country subdivisions

Somewhat recently, Mike1979 Russia has been moving files from categories such as, e. g., Category:Russia photographs taken on 2020-08-14 to, e. g., Category:Perm Krai photographs taken on 2020-08-14 (Special:Diff/843345227). At a glance, I see no prior discussion for these changes.

When the file uses {{Taken on}} for categorization, such a move is performed by using, say, location = Saint Petersburg in place of location = Russia (where Saint Petersburg is a city which is also a federal subject / constituent of Russia; Special:Diff/843346465.)

So far as I can tell, such a change is at odds with the {{Taken on}} documentation, which clearly specifies that the value of the location parameter is ought to be a country, not a subdivision thereof. So, the question is, do we want to adopt the new usage, and update the documentation accordingly; or should we rather revert the edits back to align with the current documentation / usage?

Personally, I’d prefer for the use of location to specify country to be retained (though I won’t be opposed to a separate new parameter for country subdivisions.) Otherwise, if it’s decided that location can be used for subdivisions, I’d argue that implementing the change at large should be done with a bot, not manually.

Thoughts?

M4773R (talk) 11:00, 19 January 2024 (UTC)

1. The changeings in the template was forced, since if you leave the "location=Russia" will come OVERCAT.

2. In the “usage” description of the template, there is no strong requirement to use the names of countries only. There is a requirement to use categories from "Category:Photographs by date by country", which was followed.

3. The main category already had subcategories that were not countries, for example, Guam, Scotland, Crimea, etc. The UK was already divided into sub-categories by location.

Thus, I do not observe the described problem; it is enough to remove the word in the "Localization" section. Mike1979 Russia (talk) 07:11, 20 January 2024 (UTC)

@M4773R: , @Mike1979 Russia:
I think that location may is a bad option to present as default in the first place as it will except literally anything as input. location=Untied Sattes of Amrecia? No problem! location=Glory Hole Theme Park^ref? Fine as well. You just would have to create the category which is not a huge deal at all.
It's also not something new for a category to have subcategories for images taken in a specific place. Otherwise you would have to also question the existence of United States photographs taken on 2025-01-01 as Photographs taken on 2025-01-01 already exists. So why not also have a subcategory like New York City photographs taken on 2025-01-01 if there are enough images for such a category.
My main problem with location= is that it's a high maintenance tag. Example: If the category for country X has 1'000 files and you want to group the 200 files taken in state Y into a single category, you would have to edit 200 files because you would have to change the value for "location" for each of them.
I would add keys for "country", "state" (or "province") and "city". The template would check if there is a category for the city and place the file in there as second priority, if there is no category for the city, it would do the same thing for state (or province) as third priority and again the same for country as fourth priority. The value for location would be first priority and would overwrite everything (to keep existing entries and templates working). The main advantage would be that nobody would have to sort out any images, but they are placed in the category automatically as long as the category itself exists.
Contra arguments to that: I have no idea how much stress this would put onto the servers of Wikimedia. This should be checked first. Second (as of now at least), the files do not show up in the new category even the image description page says they are in that category (As far as I know it's because of some cache issue). If you make a zero-edit (edit page -> change nothing -> save changes) the file shows up in the category.
What do you think about that solution? --D-Kuru (talk) 20:24, 9 November 2025 (UTC)

Criteria and bots for the "Videos by year" categories

Please see and participate at Category talk:Videos by year#Criteria? Bot?. Prototyperspective (talk) 16:43, 24 June 2024 (UTC)

Unexpected text Expression error: Unexpected < operator

Over the last week or so, I've started getting Expression error: Unexpected < operator in red whenever I use this template. Oddly it only seems to affect new usage, and not files where I have used the template more that ago. I've checked the template parameters and cannot see anything wrong, and there certainly isn't a < anywhere in sight. An example can be seen atː

File:Station Street, Nottingham (geograph 8028865).jpg

Can anybody explain?. -- Chris j wood (talk) 13:55, 28 April 2025 (UTC)

I suspect that #time may have changed recently. The problem comes from you supplying a time along with the date. That seems to cause #time to choke for some reason. — hike395 (talk) 23:48, 28 April 2025 (UTC)

I accept that removing the time does fix it, and I can, if necessary, do the same for the dozen or so files I've uploaded in the last week or so. I'm a little reluctant to do so because it is losing information, but I'm much more worried about the hundreds (thousands?) of files I've previously uploaded using the same syntax. The ones I've sampled seem ok (which is puzzling in itself) but have I created a problem going forward (for example when another editor makes an unrelated change). For #time to change its behaviour in this way is surely a bug; how best to report it?. -- Chris j wood (talk) 12:35, 29 April 2025 (UTC)

I suspect that older pages have not been re-rendered: if they are edited, I'm guessing that they will likely display the bug.

As for reporting the bug, I'm not sure. Perhaps you can bring it up at Commons:VPT? The specific bug appears to be:

{{#time: U | 2025-04-22 14ː09ː49}} →

which then causes the behavior you see in {{Taken on}}. This may be a new behavior, I'm not at all sure. Even applying {{ISOdate}} does not seem to fix this:

{{ISOdate|2025-04-22 14ː09ː49}} → 22 April 2025 14ː09ː49

{{#time: U | 22 April 2025 14ː09ː49}} →

— hike395 (talk) 21:20, 29 April 2025 (UTC)

@Chris j wood: Hold on, something very mysterious is going on. Let me pursue a bit longer. — hike395 (talk) 21:30, 29 April 2025 (UTC)

@Chris j wood: -- this is amusing. You aren't typing a valid date because you are not using standard colons in your time:

Unicode code point U+3A :

For some reason, you are using "Modifier Letter Triangular Colon":

Unicode code point U+2D0 ː

Not sure where this funny character came from, but if you delete the pseudo-colon and replace it with a colon, it all works. — hike395 (talk) 21:48, 29 April 2025 (UTC)

Eek. That explains it. I've been having all sorts of problems in the editor dialog recently, with lots of characters not coming out as I expected. Following your reply and a bit of experimentation, I've realised that somehow I had set the keyboard to the International Phonetic Alphabet (SIL). Quite why SIL translates U+3A to U+2D0 I've no idea, but as both look superficially the same, I hadn't noticed it. Sorry to have troubled you, and thanks for your help. -- Chris j wood (talk) 12:32, 30 April 2025 (UTC)

Shouldn't a bot convert dates in the date field to add this template?

Wouldn't it be better or isn't it needed that a bot does these kinds of edits: Special:Diff/1027345526 where the date in the date field is moved into the template along with further data inferred from the categories?

It may also need some checks for plausibility – sometimes people have added wrong dates to the date field. I'm not entirely convinced of there being much of a benefit of this template but if there is this template and it's to be used, I think it should be used more widely / consistently and be set by a bot rather than manually as a time-sink by human users.

A related issue is that categories like the subcategories of Category:Videos of 2024 by country usually miss far more than half of the files that would belong into them and that the usefulness is limited if this is also added to videos regardless of the video quality or subject – e.g. the cat may be useful if it's only added to the best quality files or videos of significant events in that location but not mundane videos that just happen to be recorded in that location. Prototyperspective (talk) 13:29, 3 May 2025 (UTC)

One issue is that {{Taken on}} should only be used for photographs, not for maps or other artificial images. I don't think there's a easy way to tell the difference between a photograph and a non-photographic jpg on Commons. — hike395 (talk) 16:35, 3 May 2025 (UTC)

Isn't it also used for videos? One could check whether the file is in a photographs category somehow (in addition one could also check exif data). Prototyperspective (talk) 16:43, 3 May 2025 (UTC)

All jpgs can have EXIF, and some photographs have broken EXIF tags. I also don't know of a generic photograph category (other than, of course, the ones that this template places into, e.g. Category:Photographs taken on 2022-03-10).

In any event, I doubt you'll find someone who is willing to take on this tricky bot programming project. — hike395 (talk) 16:55, 3 May 2025 (UTC)

I know, this is about photograph-specific EXIF data. Regarding categories, theoretically it would be any file anywhere underneath Category:Photographs but there are some miscategorizations so a more fine-grained list of cats such as deepcategory:"Photographs by lens" etc would be needed. Prototyperspective (talk) 17:09, 3 May 2025 (UTC)

Detect errors

Could parsing errors like this: File:Viceregal lodge Shimla.jpg be detected and resolved within the template? -- DaxServer (talk) 14:31, 10 May 2025 (UTC)

@DaxServer: What would you have it say for "{{Taken on |1={{other date|?}} |location=India}}"?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:39, 11 May 2025 (UTC)

@Jeff G. Personally, I'd put it in a tracking category. I don't think I'm looking for any display text, so anything works for me. -- DaxServer (talk) 13:36, 11 May 2025 (UTC)

@Jeff G. Perhaps Template:Error can be used to say, say, "Invalid date" ? -- DaxServer (talk) 15:11, 16 May 2025 (UTC)