Jump to content

Template talk:Automatic archive navigator/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Examples

Examples at Template:Aan/Archive_101 seems to be outdated. The layout doesn't correspond to what the template actually generate. --Kslotte (talk) 14:33, 14 July 2010 (UTC)

De facto standard

I'm wondering thy this template isn't used as the de facto standard for archives? Is there some issues with this template before it can be "released"? This template seems to have the best usability compared to others. --Kslotte (talk) 18:12, 12 July 2010 (UTC)

I'd prefer a merge rather than simply promoting one over the other. That way we get consistency across both old and future deployments. Chris Cunningham (not at work) - talk 14:16, 14 July 2010 (UTC)
Sounds as good plan. Any merge schedule? What are we waiting for? --Kslotte (talk) 14:26, 14 July 2010 (UTC)
A conclusion to the discussion above regarding the preferred styling. Might be a while yet. Chris Cunningham (not at work) - talk 14:46, 14 July 2010 (UTC)

Type attribute

(Thread started on User talk:Ash and relocated for future convenience:)

Pages are misusing the "type" attribute to present this template as a "content" tmbox, which it isn't. There should be no need to override the "type" attribute. I've fixed the mistaken use of this parameter in various auto archivers where it was producing bad results, but removing it from the template code itself is the best way to fix them all at once. The big red error message was present in the old code; it was simply hidden behind an includeonly so that it wouldn't appear under the template page. As you wrote the template, you're probably the best person to properly fix that, but the old hack can easily be re-added. And as far as deployment goes, less than 500 transclusions on a template like this is really pretty low; limit it to the talk and Wikipedia talk namespaces (to avoid all the links which are part of the template logic itself) and there are less than a hundred transclusions. I don't particularly see the need to have yet another archive banner anyway, but for the time being it's best that it visually mirrors the other ones (indeed, this one may be a suitable replacement for {{talkarchivenav}} in the long run, as it has neater auto-detection). Any other thoughts? Chris Cunningham (not at work) - talk 16:16, 10 January 2010 (UTC)

Sounds like a good fix to me, so long as the documentation is trimmed in line with the change. I wrote the script in order to have more intelligent auto-detection and debugging it took aaages so I suggest making use of the test pages that already exist as pointed to in the current documentation to ensure the variations still format correctly. No problem if you roll it out, I'll add a note if any glitches appear.—Ash (talk) 16:32, 10 January 2010 (UTC)
Great. I'll roll out the changes and update the documentation tomorrow. Chris Cunningham (not at work) - talk 17:37, 10 January 2010 (UTC)

Bugs with latest change

There seem to be two problems with the new version as demonstrated by the variations at Template:Aan/Archive_101.

  • The page names have lost style formatting below the text notice, these previously inherited the same style as the text. This feature is particularly useful if indexing a range of pages that may not be standard archives and the banner may even be used as a page footer with small fonts. I designed the sub-notice page names to be boxed for style reasons and don't see why having them floating outside of a box is a beneficial change and may cause problems if the user sets the optional style parameters.
  • The parameter for customizing left hand image has been lost - this was a neat feature that I certainly would like working again.

—Ash (talk) 11:49, 11 January 2010 (UTC)

I have rolled back until the above issues are addressed.—Ash (talk) 03:40, 13 January 2010 (UTC)
The sandbox code has been updated to account for the obvious bugs. The styling cruft is precisely why people shouldn't be cooking up their own archive templates: Wikipedia is not an easel, and it is not actually important that people are able to choose the exact colours of all the templates that they use. I think the current state of the sandbox is an acceptable compromise at this point. I'm prepared to backmerge said code with the original template at this point, barring any obvious bugs. Chris Cunningham (not at work) - talk 10:04, 19 January 2010 (UTC)
I disagree on the styling issue. This template (as documented) can be used in its default state to create headers for standard archives, it can also be used to index any other numbered sub-page including personal talk page archives or used as a more complex footer template for indexed pages. By chopping out these optional user parameters, the functionality is much reduced and would lead to having to create yet more archive template alternatives rather than having a useful generic and customizable alternate. The styling you prefer has been in use on {{atn}} but there is no particular reason to think this was by a robust consensus. Of course, you are free to copy this template and make a more style-restricted alternative.—Ash (talk) 10:10, 19 January 2010 (UTC)
I'm opposed to the proliferation of unnecessary template forks; that's what this still is in my opinion. Right now, practically every transclusion uses the basic syntax and ignores the extreme levels of customisation built into it. We should not be encouraging people to come up with weird and wacky new ways to flag archive pages; instead, we should encourage the use of a simple set of standards which make things easier for both readers and automated tools. Once the useful changes from this template (and it certainly has noticeable improvements over {{atnhead}}) have been back-ported, I think redirection will be appropriate for this template. Chris Cunningham (not at work) - talk 10:25, 19 January 2010 (UTC)
Okay, that's your viewpoint, it's not a consensus. At a minimum I would like to see user talk page archives have a different style to article archives. As there is not an accepted standard for user page archive naming (I archive mine by year number), or style, this seems a useful and reasonable customization.—Ash (talk) 11:01, 19 January 2010 (UTC)
That can be decided in a more centralised discussion, such as on TfD. But there's no rush. Chris Cunningham (not at work) - talk 11:57, 19 January 2010 (UTC)
As the discussion is not about deletion, TfD doesn't fit the bill. I suggest a RfC at Help talk:Archiving a talk page might suit if the issue is how much user-customization of styles should be included.—Ash (talk) 12:02, 19 January 2010 (UTC)
TfD is soon to be renamed to templates for discussion, which should help. It's the best place to get a wider opinion on the subject of a merge. The help talk namespace is seldom frequented. Chris Cunningham (not at work) - talk 13:43, 19 January 2010 (UTC)

Current status

For now, I'm removing {{{type}}} again. It's misleading and, due to some unforeseen reason, has already resulted in several pages being marked as type=content for no reason which gives them bright orange borders. Chris Cunningham (not at work) - talk 13:45, 19 January 2010 (UTC)

Is this still an issue with type paramenter misusing? Can I do AWB bot run to correct this? Is it properly used in any cases? I assume all article talk page archives should not have the type=content. Reasoning for the changes something like this? --Kslotte (talk) 13:32, 12 July 2010 (UTC)
It's no longer an "issue" as such as type no longer does anything at all; however, as it's an invalid parameter it should be removed from any existing transclusions. Chris Cunningham (not at work) - talk 14:14, 14 July 2010 (UTC)
Here was it removed. Before the default was the archive image, but now it is the information image that is shown. Should it be corrected? --Kslotte (talk) 14:25, 14 July 2010 (UTC)
D'oh. Fixed. Thanks. Chris Cunningham (not at work) - talk 08:24, 15 July 2010 (UTC)
We need to remove the parameter to get an end of using the parameter. I was thinking of putting my KslotteBot into work. A few test edits already made. I will also replace the auto-archive bot archive settings. Do I get a consensus to proceed? --Kslotte (talk) 17:11, 15 July 2010 (UTC)
Support --Oneiros (talk) 23:38, 15 July 2010 (UTC)
No objections. This shouldn't be at all controversial, as it has no effect on deployed instances. Chris Cunningham (not at work) - talk 12:45, 17 July 2010 (UTC)
AWB bot run has been done. About 1000 edits. --Kslotte (talk) 10:12, 5 September 2010 (UTC)

Module merged with Template:Talk archive navigation

I've just updated Module:AutomaticArchiveNavigator to complete the requested merge at Wikipedia:Templates for discussion/Log/2013 November 12#Template:Talk archive navigation. Now, this template is the same as {{talk archive navigation}}, but with different default settings. The archive links are now displayed below the banner, like {{talk archive navigation}}, although the arrows still appear after the first skip in numbering like they used to. There are a few new options as well. You can change the number of links displayed with |links=n, and you can set an archive prefix with |prefix=, so, for example, this will now work on ANI archives with the code |prefix=IncidentArchive. Please leave a message at Module talk:AutomaticArchiveNavigator if you spot any issues with the module code. — Mr. Stradivarius ♪ talk ♪ 07:15, 9 October 2014 (UTC)

For want of a rapier a bludgeon was used (attributed to Bomber Harris)

The archive

exists, but

was a redirect from

and{{aan}} incremented as expected until archive 130 but then stopped working. From 130 onwards there were neither forward or back links. This appears connected to the change in name as for newer MOS sub pages the algorithm seems to handle sub-page of a sub-page.

I guess the elegant (rapier) solution is to patch this algorithm, but for want of a rapier I have used the bludgeon approach: I created a page

This seems to give the algorithm something to get its teeth into and page 130 {{aan}} showed red links below as expected (but no page 131), so I then created similar links for the red pages:

Hopefully when the database catches up it will create links for all the aan's from 130 upwards.

-- PBS (talk) 18:56, 22 April 2015 (UTC)

@PBS: That will only work if you create redirects for all the archives, from 1 all the way through to 130. The module assumes that if it finds an archive that doesn't exist, then there must be no higher-numbered archives for that prefix. So as Wikipedia talk:Manual of Style/Dates and numbers/Archive 3 and upwards don't yet exist, the module assumes that the highest archive is Wikipedia talk:Manual of Style/Dates and numbers/Archive 2. It also assumes that pages with lower archive numbers than the current page also exist, which is why the links for the lower archive numbers show up at Wikipedia talk:Manual of Style/Dates and numbers/Archive 130. To fix this in the algorithm we would need to specify both page prefixes and check archives at both prefixes for existence. However, this would double the number of expensive parser function calls needed, which would not be a very good design decision as we are only allowed 500 of them per page. The alternatives are to either create all the redirects as I mentioned above, or to just move all of the archives to one prefix. (I can do either of those with some script magic if you like.) Or you could set all of the aan transclusions to use |noredlinks=no so it will display the links even if it thinks they don't exist. — Mr. Stradivarius ♪ talk ♪ 23:04, 22 April 2015 (UTC)
Actually, thinking about it, there is a better way to do the search - we could start at the current archive, then search both above and below for the number of links that we want to display. That would fix the higher archive numbers in this case, but it would still break around the point where the archive prefixes switch. You could always patch those with redirects, but having the same prefix would be neater I think. — Mr. Stradivarius ♪ talk ♪ 23:18, 22 April 2015 (UTC)
As I said bludgeon, (I could create them as well using AWB)!
I think that altering the start to the current archive number is the most elegant solution, with look back and forward from that point (and only display them if the exist). No need for page prefixes, one ends up with complicated interfaces when options like this only occur occasionally. In this current example, we would only need to create a minimum of two redirects for the list to continue, and 10 if it is to appear completely seamless. As we are only talking about talk page archive navigation, I think that two would usually suffice. -- PBS (talk) 23:45, 22 April 2015 (UTC)

Other archives

Why does this only display earlier archives, not later ones? For example, see Wikipedia talk:Manual of Style/Dates and numbers/Archive 145 where archives 140, 143 and 144 are listed, but not archives 146, 147 or 150, all of which exist.

I would fix it myself, but it's been Lua-ised. --Redrose64 (talk) 11:16, 23 March 2016 (UTC)

This is because it uses Module:Highest archive number to find the maximum archive number to display, and that module uses a binary search to reduce the number of expensive function calls it uses. The early archives of the dates and numbers pages are at "Wikipedia talk:Manual of Style (dates and numbers)/Archive n", but the module is searching for archives like "Wikipedia talk:Manual of Style/Dates and numbers/Archive n". The archives from Wikipedia talk:Manual of Style/Dates and numbers/Archive 3 to Wikipedia talk:Manual of Style/Dates and numbers/Archive 124 don't exist, which confuses the algorithm. At the moment, it thinks that the highest archive number is 163. This could be fixed by creating redirects for all of the "Wikipedia talk:Manual of Style/Dates and numbers/Archive n" pages. Or if there's a demand for it, it would be possible to add different prefixes to the algorithm, at the cost of multiplying the number of expensive function calls by the number of prefixes to be checked. — Mr. Stradivarius ♪ talk ♪ 12:12, 23 March 2016 (UTC)
It shouldn't need to. Start at n (in this case 145), look for n-1 n-2 n-5 which will turn up 144, 143, 140; then look for n+1 n+2 n+5 which will turn up 146, 147, 150. --Redrose64 (talk) 12:17, 23 March 2016 (UTC)
There's a complicating factor - as part of my effort to standardise {{aan}} and {{tan}}, I added a |links= parameter which can specify an arbitrary number of links to be displayed. Try previewing {{aan|links=20}} at User talk:Jimbo Wales/Archive 118, for example. The default for {{aan}} is seven links, and for {{tan}} it is three, but both numbers can be overridden. I see that I have very unhelpfully left this parameter undocumented since October 2014, so I'll go and correct that now. As for fixing the module, it could be done with two binary searches, one ascending and one descending, starting at the current archive. Alternatively we could get rid of the |links= parameter; given that it hasn't been documented until now, presumably it is only being used in the module itself. Although it may be prudent to add a tracking category for it, just in case people have found out about it in some other way. — Mr. Stradivarius ♪ talk ♪ 12:36, 24 March 2016 (UTC)

Is this template supported by any policy?

The current wording of "do not" seems too strong if no policy exists which is against editing archive pages. -- Kendrick7talk 02:00, 19 May 2016 (UTC)

There is nothing wrong with the wording. As I explained in response to your related question at Wikipedia talk:Talk page guidelines, there is no policy that archive pages can not be modified. There is though a general practice that they aren't modified. We generally do not modify them because it gives a false impression of the conversation that happened. There are times though, such as the incident that led you here, where it is appropriate to modify an archive. If we reduce the wording there could be more edit warring over changes as editors try to push the limits. In short the wording is appropriate and at times we might need to ignore it to do the right thing. -- GB fan 10:40, 19 May 2016 (UTC)
It seems that we have two discussions going (the original is here), which goes against WP:MULTI. --Redrose64 (talk) 10:51, 19 May 2016 (UTC)
My mistake, three discussions: but this one is closed. That goes against WP:FORUMSHOP. --Redrose64 (talk) 10:53, 19 May 2016 (UTC)
Not forum shopping, just asking questions. So if there's no policy backing this template, I'll send it to WP:MfD. -- Kendrick7talk 01:27, 25 May 2016 (UTC)
Templates go to WP:TFD, not WP:MFD. Also, having spotted Wikipedia talk:Requests for comment#Is there a time limit for admins to change their mind about how they closed an Rfc? on my watchlist, I now make it four discussions. --Redrose64 (talk) 08:43, 25 May 2016 (UTC)

Centering first/last archive

Is there a way to center first archive because it is misinformative when there are two archives center together relatively to the template (first thought is that there are only those two archives). Maybe to add invisible Archive 0 left to the Archive 1, so 1 and 2 move to the right and get centered.

Also, I don't see reason for default red last archive link; you cannot navigate to it because it doesn't exist (that link should be changed to "Make Archive ?" if goal was to have red link so that user can click and make next archive). If last one gets removed, same thing applies: something should take its space so that first and second displayed arhives are to the left and center, not both centered alltogether.--Obsuser (talk) 12:19, 9 May 2017 (UTC)

Moved from Module talk:AutomaticArchiveNavigator
 – {{3x|p}}ery (talk) 17:57, 20 February 2019 (UTC)

After the merge, {{aan}} shows red links to archive pages that don't exist yet; e.g. at Talk:Intergovernmental_Panel_on_Climate_Change/Archive_12.--Oneiros (talk) 18:21, 18 October 2014 (UTC)

@Oneiros: I think I had a reason for doing it that way after reading the TfD discussion, but if people are seeing it as a bug, then keeping the old behaviour is probably best. I've changed the module so that {{aan}} suppresses red links by default. You can always change this on individual archive templates by setting |noredlinks=yes or |noredlinks=no. — Mr. Stradivarius ♪ talk ♪ 03:45, 31 October 2014 (UTC)
Moved from Module talk:AutomaticArchiveNavigator
 – {{3x|p}}ery (talk) 17:57, 20 February 2019 (UTC)

@Mr. Stradivarius: The top of Talk:Annexation of Crimea by the Russian Federation/Archive 8 currently displays a blue "Archive 7" link followed by two bold black unlinked "Archive 8" due to selflinks. The second of these should have been a red "Archive 9" link, and purging the page will make it so (I tested on other newly created archives at [1]). I guess the issue is that when the page was created (via the API if it matters), ifexist or a Lua equivalent returned false for the page itself so the module thinks the page itself is the first non-existing archive. It will automatically be fixed by any rerendering of the page but it's confusing while it lasts. Could the module add code to say that if the page being created is registered as the first non-existing archive then add 1 to the archive number in the link? PrimeHunter (talk) 10:27, 14 June 2016 (UTC)

@PrimeHunter: Hmm, this is an interesting one. I think we need both a fix here and in MediaWiki. It probably makes sense to assume that the current page is the highest archive number if the search for the highest archive number gives a number smaller than the current page's number. At the moment, previewing {{talk archive navigation}} in Talk:Annexation of Crimea by the Russian Federation/Archive 18 gives a red link for Archive 17 on the left, a bold non-link for Archive 18 in the centre, and then a red link for Archive 9 on the right. This feels odd and shouldn't be allowed to happen. Or a better idea may be to implement Redrose64's suggestion at Template talk:Automatic archive navigator#Other archives, which would fix both this issue and the issue brought up in that thread. In addition, it sounds like there is a bug in the handling of Scribunto's #ifexist equivalent or in the MediaWiki code it is calling. Pages being created should be treated as existing, and if somehow they are not being treated as existing when they are parsed, that is a problem. — Mr. Stradivarius ♪ talk ♪ 11:06, 14 June 2016 (UTC)
I have encountered missing sequential archive numbers before but don't know how common it is. If the module detects it then I suggest adding a maintenance category like Category:Archives with missing earlier archives. A red link to the first missing archive will be helpful for the cleanup so I suggest keeping it but maybe add "(first missing archive)" after the link. The text could link to Category:Archives with missing earlier archives if that page is created with an explanation and cleanup suggestions like to move the archives and check whether the page being archived has a wrong counter in an archiving template such as counter at User:MiszaBot/config#Parameters explained. There could be an optional parameter to ignore missing archives.
I previewed {{talk archive navigation}} on Talk:Annexation of Crimea by the Russian Federation/Archive 9 and got the correct result: A red link to Talk:Annexation of Crimea by the Russian Federation/Archive 10. I saved the page and got the same correct result. I have deleted the page again. So the #ifexist issue may not be in Scribunto but in pages created via the API, like when bots create archives. I don't know the API well enough to test an API creation of a page using #ifexist to test for itself without Scribunto. PrimeHunter (talk) 12:31, 14 June 2016 (UTC)
Moved from Module talk:AutomaticArchiveNavigator
 – {{3x|p}}ery (talk) 17:57, 20 February 2019 (UTC)

Go to any of

the right-hand link should be a link to the next archive - blue for the first four of these, red on the last one because MediaWiki talk:Common.js/Archive 22 doesn't exist. But on all of them, it's a redlink to the wrong archive - MediaWiki talk:Common.js/Archive 3. This is a bug. --Redrose64 (talk) 20:31, 18 October 2016 (UTC)

This is the same issue as Template talk:Automatic archive navigator#Other archives. The module thinks the highest archive number is 2, because MediaWiki talk:Common.js/Archive 3 to MediaWiki talk:Common.js/Archive 13 are missing. — Mr. Stradivarius ♪ talk ♪ 00:46, 19 October 2016 (UTC)
Moved from Module talk:AutomaticArchiveNavigator
 – {{3x|p}}ery (talk) 17:57, 20 February 2019 (UTC)

On Talk:Martin Luther King Jr./Archive 9, the link to Talk:Martin Luther King Jr./Archive 10 is red for some reason. Esszet (talk) 15:02, 5 November 2017 (UTC)

@Esszet: A WP:PURGE fixed it. --Redrose64 🌹 (talk) 15:50, 5 November 2017 (UTC)

Arrow issues?

This is weird and confusing behaviour. These navigation links and arrows should always be there!

Headbomb {t · c · p · b} 21:42, 27 June 2019 (UTC)

The arrows represent breaks in sequence. If all the links in sequence are displayed, there's no need for an arrow. --Redrose64 🌹 (talk) 09:44, 28 June 2019 (UTC)

The situation is due to how the module has to work and the peculiar sequencing in the second of the following.

The module minimizes the number of expensive calls by avoiding checking for the existence of pages unless necessary. It starts by checking for Archive 10, then follows certain rules to guess what it should look for next. The lack of navigation at Wikipedia talk:Bot policy/Archive 24 is due to the broken sequencing shown above (the module assumes that if Archive 10 does not exist, there is no point checking every number above that). I think the arrow confusion is due to the module using links that it knows exist (from following its rules). It inserts an arrow to indicate that, to reduce overhead, it has not checked intermediate numbers. It only aims to shows three numbers on each side. Johnuniq (talk) 10:34, 28 June 2019 (UTC)

@Johnuniq: Well then, on Archive X, the module should look for Archive X−1, Archive X−2, Archive X−3... on one side, and Archive X+1, Archive X+2, Archive X+3... on the other side, stopping after it doesn't find one. So if you have /Archives 18-28, and you're on Archive 20, then you should have

— | Archives 18 | Archives 19 | Archives 20 | Archives 21 | Archives 22 | → Archives 28

and if on Archive 18, something like

— | Archives 18 | Archives 19 | Archives 20 | → Archives 28

or whatever is needed so that it works as designed.

Although I have to say 

-- Gets an archive number given i, the position in the array away from
-- the current archive, and the current archive number. The first two
-- offsets are consecutive; the third offset is rounded up to the
-- nearest 5; and the fourth and subsequent offsets are rounded up to
-- the nearest 10. The offsets are calculated in such a way that archive
-- numbers will not be duplicated.

Seems a bit weird to me. And it looks like the "fourth and subsequent offsets" aren't given. A dynamic

Archives X−5 ← | Archives X−2 | Archives X−1 | Archives X | Archives X+1 | Archives X+2 | → Archives X+5

would make a lot more sense to me, with — in place of wherever the sequence ends. E.g.

— | Archives X−1 | Archives X | Archives X+1 | Archives X+2 | → Archives X+4

Headbomb {t · c · p · b} 14:31, 28 June 2019 (UTC)

The documentation includes "The template relies on all archives from Archive 1 to Archive n to exist." The problem is (see "18 to 28" above) that the archive pages are numbered in a weird way. The solution is to work out why that is to avoid making things worse, then move all the archives so they are correctly numbered. Then automatic linking will work perfectly. My hunch is that the module approaches the target number in jumps (to avoid the overhead of unnecessarily checking for page existence which is slow). The module ends up with knowledge of certain links and it uses them. That's just a hunch that I don't think is worth investigating when the real solution is to fix the broken archives. Johnuniq (talk) 02:04, 29 June 2019 (UTC)
Well, the archives aren't broken, that's the thing (see Wikipedia:Bots/ArchiveBox). It's a case where the main pages got split, and the archive sequence was maintained. Headbomb {t · c · p · b} 20:39, 30 June 2019 (UTC)

See Wikipedia talk:WikiProject Chemicals/Archive 2015, where there are links to previous:

Archive 2010 ← Archive 2013 Archive 2014 Archive 2015

to this current archive (2015) but no link to the next (Archive 2016). 2016's does actually exist; the same problem appears on all earlier archives as well. The template (or underlying module or submodule) always thinks the one being viewed is the last one available. DMacks (talk) 20:15, 18 March 2017 (UTC)

Ah, I see now #Other archives above, from almost a year ago reporting this same problem. In the case at hand, we have years not serial-numbers, so "just create the lower missing ones" is not a viable solution. The use of years appears to be one of MiszaBot's standard archive layouts, so this is probably not a one-off use-case situation. Definitely a missing feature that Module:Highest archive number only supports starting at "1" rather than an optional parameter for where to start the search. DMacks (talk) 20:22, 18 March 2017 (UTC)
@DMacks: I would have fixed it myself, only the code has been converted to Lua, and so is no longer understandable even by those who are a whizz at proper template coding. --Redrose64 🌹 (talk) 10:01, 19 March 2017 (UTC)
@Mr. Stradivarius: this and several other bugs on this talkpage could possibly all be resolved if {{Highest archive number}} could be fed an explicit start value. Could you document the parameters of Module:Highest archive number.findHighestArchive(prefix, i, lower, upper)? DMacks (talk) 12:56, 1 October 2019 (UTC)
@DMacks: I've had a go at implementing this at Module:Highest archive number/sandbox. For example: {{#invoke:highest archive number/sandbox|main|Wikipedia talk:WikiProject Chemicals/Archive |start=2005}} → 2024. Let me know if you spot any problems with it, and if not I'll add it to the main module. There's not much point documenting that function, by the way, as it isn't accessible from outside the module, and it isn't intended to be (most users won't be interested in the internals of the exponential search algorithm). Best — Mr. Stradivarius ♪ talk ♪ 15:08, 1 October 2019 (UTC)
Looks nice! I had asked about docs because I had started to look at doing it myself before realizing it wasn't documented so I'd just as easily ask the original author for help:) DMacks (talk) 18:43, 1 October 2019 (UTC)
@DMacks: This is now up live: {{highest archive number|Wikipedia talk:WikiProject Chemicals/Archive |start=2005}} → 2024. — Mr. Stradivarius ♪ talk ♪ 16:20, 8 October 2019 (UTC)
Great! I cloned that handling of |start= to propagate from Module:AutomaticArchiveNavigator/sandbox2. With that (and now that {{aan}} propagates that parameter as well), Wikipedia talk:WikiProject Chemicals/Archive 2015 gives the proper links. DMacks (talk) 06:37, 10 October 2019 (UTC)

[rerquest] Yearly archives currently not displayed

Module:AutomaticArchiveNavigator seems to stop incrementing through numbered archives when there is a break. This works fine for simple "Archive 1"/"Archive 2"/etc. articles, but it means the module never reaches to the 2000's for yearly archives named like "Archive 2003"/"Archive 2005". I'd like to see this ability added inherently (though a special parameter to flip the logic to yearly archives is fine, if required). Keep in mind for testing that there may be skips in the years, so it needs to be robust in incrementing the whole range of 2003 thru CURRENTYEAR. Adding this function could means this could replace several yearly archive headers like {{Annual archive}}. -- Netoholic @ 14:17, 26 June 2020 (UTC)

Requested move 18 July 2020

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved (closed by non-admin page mover) DannyS712 (talk) 14:47, 26 July 2020 (UTC)


– Match name with template * Pppery * it has begun... 20:17, 18 July 2020 (UTC)

Is this really necessary? Wasn't there a case not so long back that a module was seriously broken simply by being moved to a different name for aesthetic reasons? --Redrose64 🌹 (talk) 20:39, 18 July 2020 (UTC)
It's possible to move a module without breaking things. I've done it many times. The fact that other users are editing carelessly does not mean it is an inherently bad idea to move modules. * Pppery * it has begun... 02:06, 19 July 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Use of the word "revive"

Hello,

Should "revive" in this template (and other templates, such as Template:UserTalkArchive, although I'm not sure if that's the only other one) be changed to something like "restart"? This would be to avoid idiomatic language. Other suggestions for what can replace it are welcome. Regards, DesertPipeline (talk) 13:00, 27 June 2021 (UTC)

Hi folks! For some reason, when I place {{Automatic archive navigator}} atop an archive page, links do not appear. My archive pages seem to be properly named (verify). Any thoughts, ideas, suggestions? Thanks! — SpikeToronto 17:06, 3 June 2021 (UTC)

User:SpikeToronto: I think it might be because of the leading zeroes? Regards, DesertPipeline (talk) 13:02, 27 June 2021 (UTC)
@DesertPipeline: I had hoped that wouldn’t be it. I’ll run a test dropping the leading zeros and see how that works. It won’t be immediately, though. Thanks for the suggestion! — SpikeToronto 17:14, 27 June 2021 (UTC)
To editor SpikeToronto: this template has a |prefix= parameter, so you might try using |prefix=Archive . (The html code just adds a space after "Archive".) That should work with your method of archive numbering. Might save you from having to rename your archive pages. Hope it works well. P.I. Ellsworth - ed. put'r there 06:04, 17 October 2021 (UTC)
Never mind. I see you've found a solution with redirects. Cool! P.I. Ellsworth - ed. put'r there 06:23, 17 October 2021 (UTC)
Still, that’s an amazing suggestion. Thanks Paine Ellsworth! — SpikeToronto 10:21, 17 October 2021 (UTC)
It's my pleasure! Paine  18:07, 17 October 2021 (UTC)

Template-protected edit request on 21 February 2021, remove boldness from date parameter/text

I think the period parameter should produce regular styled text, not bold.

Rationale: Bold date text is unnecessary and makes it all cluttered with two very different bold messages next to each other that takes away attention from the important message that no edits should be made. Example here. The optional date is of less significance and aimed towards experienced readers. Bold text should only highlight the most important bit(s) so that skim readers and newcomers get the crucial. I suspect that since date in the banner is unusual, fairly experienced readers might miss it, and that's why the author thought that the text should be bold styled. That might be the case, but the message isn't that important anyway. Very experienced readers should look there too, and numbers will stand out from the usual text and can be fairly easily noticed when skim reading. And in any case can dates be seen in other ways. The cluttered impression that the date parameter can produce now might prevent people from using it, boomeranging the intention of giving more information in an easily overviewed summarised form. Perhaps others don't agree, and the ultimate solution would be to give the choice to the user how the text should look. Mango från yttre rymden (talk) 19:22, 21 February 2021 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. I'd suggest posting a comment to some relevant pages, perhaps Help talk:Archiving a talk page, pointing to your proposal here. If there's a consensus (or no opposition) after a while, feel free to re-open this request. Elliot321 (talk | contribs) 20:15, 21 February 2021 (UTC)
Ridiculous. Not going to spend a month to argue for such common sense and low intrusion thing. That's what it took to convince another equally stubborn editor to implement an equally straight-forward alteration. It was so exhausting that I don't want to return to that and complete the job for a while. Already spent a freakin' hour coming up with a decent explanation here, and I regret that very much. I figured this was uncontroversial so I should definitely not have been so humble and presented it as a matter of taste, rather sticked to my guns and portrayed it as common sense, period.
Not going to bother with this shit. If you don't want improvements, then fine, remain shit. You lords should remove the "uncontroversial" clause in the edit request guideline as it's never applicable. Good day. --Mango från yttre rymden (talk) 21:05, 23 February 2021 (UTC)
To editor Mango från yttre rymden: I think this is controversial and contentious. You're trying to alter something that's been working just fine for many years. And if you rant like that over something as trivial as bolding an obscure period dating in an obscure archive template, you don't stand a chance out there among the real wolves of Wikipedia and the really important things that need improvements. You better tighten those tummy muscles if you truly want to become a veteran editor of this encyclopedia. Best of everything to you and yours! P.I. Ellsworth - ed. put'r there 00:06, 12 October 2021 (UTC)
  • I support this. If someone wants to bold the text in that parameter, they can do so manually, but if they don't want it bolded they currently have no way around that (I think?). Regards, DesertPipeline (talk) 13:05, 27 June 2021 (UTC)
  • Support, per DesertPipeline. — SpikeToronto 17:24, 27 June 2021 (UTC)
  • Support as well, simple enough change, not controversial. From WP:ER consensus should be obtained before requesting changes that are likely to be controversial (emphasis added). This should have been done the first time as it was clearly not controversial and page protection is in place to prevent vandalism, not to prevent constructive editing. —Locke Cole • t • c 21:05, 11 October 2021 (UTC)
  • Oppose. It's fine just the way it is and has been for many years. If it ain't broke, then don't try to fix it. P.I. Ellsworth - ed. put'r there 23:53, 11 October 2021 (UTC)
  • Comment. Not to complicate matters, but this template is powered by a Lua module, so such an edit as this will require an editor who is versed in Lua. Those editors have been kept pretty busy converting Wikimarkup templates into Lua templates, so they'd most likely put this kind of request on a far-back burner. Just sayin'. Think I figured out how to do this, but I still don't think it should be any less than in italics. P.I. Ellsworth - ed. put'r there 00:58, 12 October 2021 (UTC) 20:41, 15 October 2021 (UTC)

Workaround

@DesertPipeline and Mango från yttre rymden: See example below in wikitext, but basically you have to enclose the text in a <span></span> tag, set font-weight to normal, and then it seems to render out correctly. If you view the output syntax I'm sure it looks ugly though... that being said, I think it should be either output as basic text as-is (with it being easier for folks to use standard wiki-text to bold it or italicize it as needed), or make the bolding a parameter that can be disabled. —Locke Cole • t • c 08:26, 12 October 2021 (UTC)

To editor Locke Cole: please find another way to illustrate the template below, because your usage of the {{aan}} template turns this page into an archive-like page and disables section editing. Thanks in advance for fixing this! P.I. Ellsworth - ed. put'r there 10:31, 12 October 2021 (UTC)
Will fix. Original template invocation for anyone who looks at the history for an example: {{aan|period=<span style="font-weight: normal;">foo bar baz</span>}}
As it's Lua there's no way to subst and remove the offending markup that inhibits section editing and new sections. :( Just copy the wikimarkup above to a separate page and preview it to test it. —Locke Cole • t • c 19:07, 12 October 2021 (UTC)
@Locke Cole There's nothing about Lua that would prevent substing. The template just has to be set up for it by changing {{#invoke: to {{safesubst<noinclude />:#invoke:. --Ahecht (TALK
PAGE) 20:46, 12 October 2021 (UTC)
Don't know enough about LUA to provide a choice between bolding and not bolding, but I would like to suggest a compromise, so I will ping the editors who are thus far involved...
To editors Mango från yttre rymden, Elliot321, DesertPipeline, SpikeToronto and Locke Cole: as I still think that some emphasis should be used with the |period= parameter's text, what if the bolding were to be changed to italics? Can we live with that at least? P.I. Ellsworth - ed. put'r there 10:31, 12 October 2021 (UTC)
Yeah. I don't really care about this anymore, I declined the edit request feeling it might be a controversial change as well as not really an improvement. Making the variable part of this template harder to spot doesn't make sense. Regardless, if people want to go ahead with this change I wouldn't mind if it's changed to italics or nothing at all, I never really pay attention to this template on talkpages anyway. Elli (talk | contribs) 13:23, 12 October 2021 (UTC)
@Elli Why should the variable part be emphasized in any way? The template is designed to create a natural-sounding sentence. We don't need to warn readers that it's Mad Libs. --Ahecht (TALK
PAGE) 20:49, 12 October 2021 (UTC)
This is not an uncommon template to see. Hardly anyone is going to read or care about the text of the template the hundredth or thousandth time they see it - the only reason they'd read it at all is for the text which varies. Hence, emphasizing it to make it easier to pick out. Elli (talk | contribs) 20:53, 12 October 2021 (UTC)
  •  Not done until someone actually sandboxes something, validates the tests, and comes to a consensus there is nothing for passing uninvolved edit-request handlers to do here. — xaosflux Talk 18:51, 15 October 2021 (UTC)
    I might've missed something, but... WP:TPE has requirements that editors who are granted access be competent enough to implement the edits being requested (there are, in fact, multiple tests one must pass before being granted the user request when requesting it). Walk me through the logic of all those tests/requirements if it still falls on the requesting editor to actually do all the work to make the change but can't (because of the protection restriction)? If there's no need for any technical ability beyond simply copying/pasting, it seems like the requirements for TPE access should be significantly less onerous. Protection should not be misused to create separate classes of editors. It should be used to prevent vandalism. This request most assuredly is not vandalism. —Locke Cole • t • c 18:53, 17 October 2021 (UTC)
    Please see Wikipedia:Edit requests#General considerations. Editor Xaosflux did not imply that the passing uninvolved template editors had to be clueless. It is required that the edit be very specific in order to prevent errors or to prevent misreading the requestor's meanings. Please AGF. P.I. Ellsworth - ed. put'r there 22:42, 17 October 2021 (UTC)
    I suspect this reply will be a colossal waste of my time, but sure, let's engage: Please see Wikipedia:Edit requests#General considerations Neat. Let's go down the list, shall we?
    1. Is your request specific? The original request (above) was most decidedly not vague: I think the period parameter should produce regular styled text, not bold.
    2. Is your request uncontroversial? It doesn't get much more benign that simply changing how text is styled... this is about as controversial as changing ... to … (&hellip;)...
    3. Is your request necessary? The template is permanently protected so only template editors or those with higher permissions can make changes. So... yes?
    4. Is your request sensible? Yes, and as to the consensus bit that originally stopped this from being implemented, I agree with the original requestor that this change is not controversial. In fact, if you ignore the three editors with permissions who have decided to use their positions to stonewall the initial request, you'd see this change enjoys unanimous consensus.
    Editor Xaosflux did not imply that the passing uninvolved template editors had to be clueless. I don't... I don't know what you're responding to here? It is required that the edit be very specific in order to prevent errors or to prevent misreading the requestor's meanings. Again, I think the period parameter should produce regular styled text, not bold. is not something I'd expect someone to "misread" or cause an "error". Please AGF. Good faith is not a death pact, and when you see something totally benign turned into almost an RFC you start to lose faith that everyone is acting with good intentions (not calling you out, but it strikes me as unacceptable that three editors with access/permissions have resolutely declined to act on this uncontroversial and unanimously accepted request). That makes me question whether the RFP/TE process is actually functioning as intended (or if such intentions were not an error). At the very least I'm wondering if template editors shouldn't have requirements similar to WP:INVOLVED...
    I'll say it again: the primary reason we protect pages is because of concerns over vandalism, not to prevent editors from being constructive. —Locke Cole • t • c 00:27, 18 October 2021 (UTC)
    So it seems you mean that just because we're template editors, we don't get to have an opinion about things? The !vote was not by any means "unanimous", and in fact was by no means a consensus with just a few editors involved. You appear to be turning this into a circus, so we shall wait to see if a consensus forms below. If it does, then it does. If it doesn't, then it doesn't. After all the research I've put into this, it was certainly a good learning experience for me in terms of learning about LUA. So there is that at least. Happy trails, fellow volunteer editor! P.I. Ellsworth - ed. put'r there 00:52, 18 October 2021 (UTC)
    So it seems you mean that just because we're template editors, we don't get to have an opinion about things? Yes, that is precisely what I mean. If TEs are going to become the arbiters of consensus, they should emphatically not be involved in the discussion as it projects an image (even if that image is not correct) that TEs may be abusing their positions. For the same reason WP:UNINVOLVED exists for administrators. The !vote was not by any means "unanimous", and in fact was by no means a consensus with just a few editors involved. Can you point to the part of WP:CON that says "just a few editors" is insufficient? And I'll note you continue to ignore the fact that no consensus was necessary, as this change was clearly not controversial. But sure, the first responding editor declined it due to a "lack of consensus" (not because they opposed it), whereupon other editors came to support the change as well. The protected edit request was re-activated, where you entered the picture to close it again and this time !vote against the change. One person opposing three other editors is not a reason to hold back a change. You appear to be turning this into a circus You appear to be making personal attacks, do stop or I'll see you at WP:AN/I. so we shall wait to see if a consensus forms below yes, your obstruction has paid off. Congratulations on being disruptive to the project and making sure something can't be done that you don't like because you have permissions the rest of us do not. I'm sure you're very pleased with yourself! —Locke Cole • t • c 05:39, 18 October 2021 (UTC)

Continued

Editors please see discussion below that continues on this issue. P.I. Ellsworth - ed. put'r there 22:42, 17 October 2021 (UTC)

Text used with the period= parameter

Ref.: remove boldness from date parameter/text discussion above.

Let's see if we can come to consensus in regard to the edit request above? The initial request was to remove the bold typeface from the text that appears when the |period= parameter is used. In that discussion I suggested that rather than remove emphasis altogether, we change the bold typeface to italic typeface. I have placed this in the sandbox and the difference can be observed on the testcases page. We should involve the editors above who expressed an interest one way or another, and they are editors Mango från yttre rymden, who initiated the request, as well as DesertPipeline, SpikeToronto, Locke Cole and of course myself. Would ask that you please take a look at the testcases page, see the difference, and then return here to give your opinion. Choices are:

  1. continue as is with bold text
  2. place the text in italics
  3. remove emphasis and use plain text

That third choice is not represented on the testcases page; however, it is hoped that we can agree which of the three choices is best after seeing the difference between choices 1 and 2 on the testcases page. Best to all! P.I. Ellsworth - ed. put'r there 21:33, 15 October 2021 (UTC)

Consensus for plain text already exists above (which would be my 1st choice), italics would be my 2nd choice and status quo would be my 3rd/last choice. I'm not entirely sure why anyone would twist themselves into knots defending any sort of emphasis for this. I'd considered that there may be an accessibility reason for emphasizing the period, but even then, I don't think someone using a screen reader needs the period field to be emphasized. Bolding and other emphasis should be used sparingly, not simply to serve as decoration. —Locke Cole • t • c 05:32, 16 October 2021 (UTC)
@Paine Ellsworth: I appreciate the work you’ve put into this. However, I prefer !vote for plain text that the user can style/emphasize however s/he wants in the user talkspace (e.g., bold, italics, etc.). Thanks! — SpikeToronto 05:59, 16 October 2021 (UTC)
To editors Locke Cole and SpikeToronto: editor Elli said it best in the previous discussion... This is not an uncommon template to see. Hardly anyone is going to read or care about the text of the template the hundredth or thousandth time they see it - the only reason they'd read it at all is for the text which varies. Hence, emphasizing it to make it easier to pick out. That is why I'd hoped we could come to a compromise using italics rather than bold or plain. P.I. Ellsworth - ed. put'r there 06:52, 16 October 2021 (UTC)

Perhaps the best solution would be to have a parameter to disable the bolding of the text in the period parameter. Also, to delineate between them, adding a line break might help; see the example I added.

Example of template with line break

Please let me know your thoughts. Regards, DesertPipeline (talk) 13:53, 16 October 2021 (UTC)

Addendum: If the period parameter is not passed, the line break shouldn't be present, as it's not necessary in that case. DesertPipeline (talk) 17:07, 16 October 2021 (UTC)

To editors DesertPipeline, SpikeToronto and Locke Cole: as you can see on the testcases page, a new parameter has been introduced in the sandbox called |period_plain=. Use of that parameter instead of |period= reduces the bold typeface to plain text. Also placed a line break after the period text or period_plain text as editor DesertPipeline suggested. We can go live if acceptable. P.I. Ellsworth - ed. put'r there 01:34, 17 October 2021 (UTC)

I appreciate what you've done, but I still believe the default behavior for the period text should be to just be standard text, not emphasized. If anything, I'd switch to having a parameter named period_bold that emboldens the text, and switch period to simply be raw text with no styling. —Locke Cole • t • c 18:56, 17 October 2021 (UTC)
To editor Locke Cole: thank you very much for your appreciation! I think, tho', since there are two of us who recognize that the bold text serves a purpose because it is only seen when the |period= parameter is used and needs to catch the eye, and because there are only three other editors who join you in support above (and at least one, maybe two of those editors would be okay with my sandboxed changes), a larger group of editors is needed to garner consensus to go further than I've gone and actually change the default for the |period= parameter. I've done my best to provide an alternative solution by using the |period_plain= parameter. If that's not good enough, then we're done here until more editors chime in. Be sure to give WP:CANVASSING a good read before you start asking others to come and !vote. P.I. Ellsworth - ed. put'r there 21:25, 17 October 2021 (UTC)
User:Locke Cole: I think it makes sense for the period text to be bolded by default. As was mentioned above, reading all of the box's text isn't necessary if you've read it before, so bolding information which is variable and useful even to people who know what most of the template says is probably a good idea. Did you see my example with the line break? I think that helps to solve the actual problem – two pieces of bolded text right next to each other. It also delineates them better; "This is an archive" is one piece of information, and "Do not modify it; use the current talk page to start or restart discussions" is another. What do you think? DesertPipeline (talk) 21:29, 17 October 2021 (UTC)
As Locke Cole has decided to stop participating in the discussion, I'd like to clarify that my invitation for comment is open to everyone. I think that the line break, plus the period parameter bold-disabling parameter, are both good ideas for this template. What do others think? DesertPipeline (talk) 01:23, 18 October 2021 (UTC)

Disengaging

I'm going to follow Mango från yttre rymden's lead and disengage from this discussion. I can't believe this is what templates have turned in to, a club for the have's and have not's. Very disappointing. —Locke Cole • t • c 00:29, 18 October 2021 (UTC)

You will be missed. I LOVE the circus! P.I. Ellsworth - ed. put'r there 00:54, 18 October 2021 (UTC)
I love the personal attacks. I'm sorry you abuse your position to gain advantage during a discussion. At least this is an easy thing to point to if you ever decide you'd take a run at WP:RFA. —Locke Cole • t • c 05:42, 18 October 2021 (UTC)
Well, that ain't ever gonna happen (again)! Look Locke, may I call you Locke?, look... some editors take all this just a bit too seriously. So please try to gain some perspective and realize that a hunnert years from now, nobody's gonna give a crap about an obscure template on obscure archived talk pages, much less how the letters and words are typefaced. The practical thing is that this template's been running just fine for many years now just like it is. And it's now used on way over 100K pages. One of the first things TEs learn (sometimes the hard way) is to be very careful with this kind of template "to avoid major disruption and server load" as quoted from the {{high-use}} template on the /doc page. And to keep our sanity and avoid personal attacks, we also join the WP:DoF. I honestly don't mean anything by my above comments. They're just a way of making the day go by a little less drab for old codgers like myself. My sincere apologies to you for any perceived offense. You've been my sunshine! P.I. Ellsworth - ed. put'r there 08:24, 18 October 2021 (UTC)

Template-protected edit request on 3 October 2022

I had seen some page moves by new editors without moving archive pages, possibly because movesubpage right is available only to pagemovers & admins. I was thinking about categorising such pages. Thus, please add <includeonly>{{#if:{{is redirect|{{FULLBASEPAGENAME}}}} |[[Category:Archive pages whose parent page is a redirect]] |}}</includeonly> Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 19:26, 2 October 2022 (UTC)

@CX Zoom, you should first create Category:Archive pages whose parent page is a redirect. — Qwerfjkltalk 19:41, 2 October 2022 (UTC)
You can use {{FULLBASEPAGENAME}} or {{FULLROOTPAGENAME}} for simpler code — Martin (MSGJ · talk) 20:21, 2 October 2022 (UTC)
Thanks Qwerfjkl, Category:Archive pages whose parent page is a redirect created. @MSGJ: I did not know about this template earlier, feel free to change it if you think that's a simpler code. Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 07:42, 3 October 2022 (UTC)
Modified accordingly — Qwerfjkltalk 11:36, 3 October 2022 (UTC)
 Done * Pppery * it has begun... 00:00, 4 October 2022 (UTC)
@Pppery, can you add |talk=yes to {{is redirect}} per this VPT discussion. — Qwerfjkltalk 06:11, 6 October 2022 (UTC)
 Done * Pppery * it has begun... 13:24, 6 October 2022 (UTC)

Template-protected edit request on 23 October 2022

Please add a parameter to allow excluding Category:Archive pages whose parent page is a redirect. Animal lover |666| 07:41, 23 October 2022 (UTC)

@Animal lover 666: I had requested that categorisation a few days ago. Although I don't oppose the inclusion of an opt-out parameter, I can think of some edge-cases where the parent page of an opt-outed page is moved and results in not being categorised when it should have been ideally. —CX Zoom[he/him] (let's talk • {C•X}) 19:12, 23 October 2022 (UTC)
For the time being, I'm making it a WP:Hidden category, so it remains invisible to everyone unless someone opts-in to view them. —CX Zoom[he/him] (let's talk • {C•X}) 19:14, 23 October 2022 (UTC)
Have written a quick implementation in /sandbox, without comment on whether or not this is a good change. Also pinging @CX Zoom and @Pppery. -- Asartea Talk | Contribs 19:14, 23 October 2022 (UTC)
Can you point to an example of a page that should be excluded? * Pppery * it has begun... 19:22, 23 October 2022 (UTC)
The archive pages of Wikipedia talk:AutoWikiBrowser/Bugs. This page was apparently a real talk page that was redirected, not moved. Animal lover |666| 21:42, 23 October 2022 (UTC)

 Done since no one seems to have actually objected to the change. * Pppery * it has begun... 18:20, 27 October 2022 (UTC)

Remove some styles to improve mobile version

Please replace:

		style = args.style or 'width:80%;margin-left:auto;margin-right:auto',

With:

		style = args.style or '',

The inline styles are not necessary on desktop (tmbox already has styles to set it to 80% width), and cause this template to display at an unusually narrow width in the new version of mobile talk pages (visit e.g. [2] on your desktop and click "Learn more about this page" to see). Matma Rex talk 09:54, 20 January 2023 (UTC)

 Done * Pppery * it has begun... 00:15, 24 January 2023 (UTC)

Two of the usage examples are null

Hello,

  1. The third and fifth examples shown here do not render any changes to the output.
  2. The third one uses the style= parameter.
  3. The fifth one is supposed to blank the left image (image=none) and add an image on the right (imageright=).
  4. These are the examples that are linked from the template's "article" page.
Please fix or advise. PS: please refactor my question if it is rubbish. Thank you for keeping up the template department. Cheers! {{u|WikiWikiWayne}} {Talk} 00:52, 23 February 2023 (UTC)
Did this edit break Ash's {{Automatic archive navigator/Exam}} template by linking to a sandbox? Cheers! {{u|WikiWikiWayne}} {Talk} 01:52, 23 February 2023 (UTC)
This appears to be a documentation issue. {{Automatic archive navigator/Exam}} isn't actually used anywhere other than for examples that have broken sometime in the past 14 years. I've removed the link for now, but the documentation should probably be improved with some actually examples, but that's a bit annoying for this template since it relies on other archive subpages existing. . --Trialpears (talk) 12:49, 23 February 2023 (UTC)

Overly strict blurb

The "Do not edit the contents of this page." warning in the blurb seems overly strict, because when manually archiving Talk page sections, that's exactly what people may have to do. The intent probably was to discourage messing with existing already-archived discussions any further, but the phrasing used here is overly broad and technically would seem to prohibit necessary activity for manual archiving too. Perhaps something like this might be better: Please do not edit any already-archived content on this page. (This is not intended to prohibit manual archiving of additional content, including on this page if appropriate.) That's not very succinct though. Perhaps someone else can improve upon it. ReadOnlyAccount (talk) 04:46, 24 October 2023 (UTC)

Handling year-named archives

Would be good if this also auto-detected archives that are named for years, e.g. all those at Talk:The Walt Disney Company.  — SMcCandlish ☏ ¢ 😼  13:19, 11 December 2023 (UTC)

Should we add diff and histoffset parameters?

REMOVE
After a month of no further comments, there is clear consensus to remove the |diff= and |histOffset= parameters. (I am formally closing this to hopefully help the merge along.) HouseBlaster (talk · he/him) 02:57, 13 February 2024 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


{{Archive}} is being merged here now and has two parameters that this template doesn't hav, |diff= (~73 uses in this very unreliable search) and |histOffset= (~68 uses). These add a link to the original revision of the page and the appropriate part of the history respecivly. I could easily add these and carry them over without any issue, but I find these links completly useless. I want to keep unnecessary complexity at a minimum to keep the template easy to use and removing this in my view useless feature used by under 0.1% of transclusions seems reasonable. Pings to TfD participants and the 4 people who use this feature on their user talk pages and have edited in the past month. @SMcCandlish, Gonnym, Caeciliusinhorto, Anomie, RayneVanDunem, Nsgaeverine, and Anon126: --Trialpears (talk) 02:02, 17 December 2023 (UTC)

You can add a tracking category to find usages if the search isn't good enough. Regarding your question if the parameters are that underused, then either editors don't know about them and might be useful or they just aren't useful. If they aren't useful there is no reason to carry them over. Gonnym (talk) 07:46, 17 December 2023 (UTC)
I'm in favor of omitting them. They are not useful, for at least two reasons. No one needs to see the talk page in the exact state it was when the archive page was created, since that just shows the same threads, just in their original context (it provides no additional information). And archive pages are usually added-to over time until they get so long that a second (third, etc.) archive page is later created, so the two "snapshotting" parameters are not going to relate to the archive page's contents for very long in most cases and will just end up being confusing to anyone who tries to use them. In the weird case that someone does feel a need to look at the original talk page in the state it was in when the archive page was created (e.g. because the archive page was created by someone who later turned out to be a subtle vandal), this is what the page history feature of the website is for. Look at the dates and times of the archived discussions, and go back in the orignal talk page history to whatever date and time is of interest to you.  — SMcCandlish ☏ ¢ 😼  12:20, 17 December 2023 (UTC)
I have no objection to removing these parameters, as one of the (apparently very few) people who use them. I think they provide some convenience but I recognize that this may not be worth the added complexity. Anon126 (notify me of responses! / talk / contribs) 08:15, 23 December 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Automatic_archive_navigator/Archive_1&oldid=1235976565"