This page is an
archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page.
There seems to be a lot of support for this feature; I have therefore set up a separate specification page, and moved the discussion from the bot request page to here.
I have chosen the name "Article alerts" rather than "WikiProject News", because the latter sounds more like a WikiProject that deals with news services or the like. Still, it's not the ideal name because the feature would possibly include alerts for non-article pages (e.g. templates) as well. Comments are welcome. --
B. Wolterding (
talk)
09:28, 24 July 2008 (UTC)
I got the idea a while ago when updating the
Wikipedia:WikiProject Physics/Current activity page. It would be very useful to have a bot going around Wikipedia every day and update these lists automatically.
A useful parameter would be something to specify that the first X number of articles in each sections are to be transcluded so very active Wikiprojects can have a "Current Activity" section that's of reasonable length on their main page.
I was actually thinking a bit about a bot of that kind recently - at least with a part of that functionality (e.g. listing the current deletion nominations, listing the results would be somewhat more involved). It would certainly be a nice feature if someone wants to use it.
On the other hand, on a technical level, it would differ a lot from
what I am currently doing, and details need to be evaluated. The bot would probably need to run on the
tool server. Also, if this is supposed to be rolled out on a larger scale, i.e. for many wikiprojects, performance aspects might be much more tricky then they seem at first. Any hints/suggestions/experience?
So, first question would be, are there indeed some wikiprojects who would be interested in a bot like that? If so, and if others here think it's reasonable, I would see this, say, as a medium-term project for me, and try to look into it during the next months. Of course, if someone wishes to implement it on the short term, I don't want to stop him... --
B. Wolterding (
talk)
21:24, 16 July 2008 (UTC)
Hm. Use by a single WikiProject might be not enough to justify the programming and testing efforts, which will be considerable. But we're not in a hurry. I will post a notice to the relevant forums (Village pump, some others) to see whether someone else is interested. Perphaps, in this way, we can also collect some valuable input regarding the bot's functionality. Meanwhile let me summarize in my words what the bot would do:
It would update a page (one per WikiProject) that lists project-related articles which have entered certain workflows on Wikipedia, including:
Featured article nominations, featured article reassessments, and the same for Featured lists and Good articles,
Peer reviews.
Where possible, articles would also be listed when they have left one of these workflows, with results indicated (e.g. article deleted, article kept). However this might not be feasible in some of the cases above. The list would be updated once a day (to start with).
"Congratulating" nominators etc. might be a bit much for the time being, and doesn't seem to be so central to me.
Congratulating might not be central, since that person might not be the one who put the most efforts, but at least mentionning who nominated so people can reach him/her seems reasonable. But like you said, this is not central.
Headbomb {
ταλκ –
WP Physics:
PotW}
12:28, 22 July 2008 (UTC)
We've just had an editor on
WP:Anglicanism complain taht many of "his" Anglican articles are being afd'd and so on, so wider notificaiton to the project would probably be useful. I glance at AFD from time to time, but a more focused idea of articles of interest would be useful.
David Underdown (
talk)
14:30, 22 July 2008 (UTC)
Yes I agree. I see a huge benefit with such a bot. It would also make Peer Reviews easier to manage and keep track of (hopefully increasing their usage). --.:Alex:.15:13, 22 July 2008 (UTC)
There is already talk of adding functionality to the WP 1.0 bot to facilitate this task. If someone is planning to write this bot, please contact me so I can explain how WP 1.0 bot can make the task a lot easier for you. — Carl (
CBM ·
talk)
16:24, 22 July 2008 (UTC)
I had an idea for a "sentry bot" once that was similar in most respects for this. I like the idea, and I'm all for it.
TomStar81 (
Talk)
02:55, 23 July 2008 (UTC)
Agree. Would be very nice for
wp:ships to know when someone has nominated something project related for deletion or review. Has happened to us several times in the past where we were never aware of the nominations. --
Brad (
talk)
03:23, 23 July 2008 (UTC)
Can't speak for everyone at
Wikipedia:WikiProject Plants, but I like this idea. We tend to hear about such things in a manual way, but a bot would be less likely to miss things. Because the bot would only tell us about articles tagged with our wikiproject, I don't really see a problem with seeing irrelevant information, and the volume of information should also be manageable, I would think. I'll leave it to others to discuss what is feasible from a technical point of view.
Kingdon (
talk)
04:04, 23 July 2008 (UTC)
It would be useful to include happenings at
WikiProject Stub sorting on this as well, as there we've recently been discussing how to make WikiProjects at least aware of our activities, particularly when stub types connected to their scope are involved in proposals, discoveries and deletion.
SeveroTC07:47, 23 July 2008 (UTC)
I'm in the throws of reviving
WP:WikiProject Gymnastics, and this does seem like a good idea, especially for those projects with relatively low numbers of users. It might also help those out that haven't got sufficient volume for this like deletion sorting in their own right. Would be curious on how this'd work -- whether we could pick a root category that a project would be interested in, or whether it would require tagging on the talk page (I guess "both" is ideal) --
ratarsed (
talk)
11:15, 23 July 2008 (UTC)
My impression is that the plan is to make something like
Wikipedia:WikiProject Mathematics/Current activity for other wikiprojects. That table isn't hard to make, it just requires a list of the articles that are "in" the relevant project, and the contents of various maintenance categories.
WP 1.0 bot can help by providing an API to get the list of articles that are assessed by a wikiproject. That would greatly simplify the alert bot code, since it won't need to worry about the structure of the WP 1.0 categories, and won't have to spend the (long) time needed to download the lists of category contents to make the project lists. Since WP 1.0 bot already has all the project data, it's trivial to write a program to access it. I wrote one simple interface that you can currently access at
http://tools.kiwix.org/~oleg/cgi-bin/wp/project-list.cgi?project=Aesthetics%7CMathematics I can change the output format if the line-based format isn't convenient. — Carl (
CBM ·
talk)
12:21, 24 July 2008 (UTC)
By the way, you may notice that the math current activity only updates certain things every three days.
User:Jitse Niesen, who runs that bot, says that this is because it takes too long to download the contents of the corresponding categories. I haven't tried it myself now that the API is available, but it's always good to know what other people have already found. — Carl (
CBM ·
talk)
12:23, 24 July 2008 (UTC)
Well, the goal is in fact somewhat similar to
Wikipedia:WikiProject Mathematics/Current activity; but the technical approach would be quite different. As you remarked correctly, downloading all the needed category content via the API would be impractical; this method wouldn't scale. I am rather planning to work with database queries on the
toolserver. So the task of obtaining the category content, and correlating it, is not a big deal, it would be coded in a few SQL statements. (Whether that's really feasible has to be evaluated of course.)
Why I expect the bot to be somewhat complex is not because of the large categories. The complex part would rather be to gather details of the different workflows, which were usually not designed for automated evaluation - so one must expect some surprises. --
B. Wolterding (
talk)
15:40, 24 July 2008 (UTC)
I have tried using the toolserver database for that sort of thing, and I found that it was not reliable enough. Although the replication lag is usually small, it will sometimes have a lag of days or weeks, which makes any time-sensitive bot inoperable. The advantage of using the API is that you bypass that point of failure.
Using the API, it is possible to download a category contents in batches of 5000 sorted by when the articles were addded to the category in decreasing order. By doing that, it may be possible for you to make a list of changes without downloading the entire contents of the maintenance categories.— Carl (
CBM ·
talk)
15:44, 24 July 2008 (UTC)
One needs to test it I think. The replication lag history seems promising, lags of more than 100 seconds are rather exceptional events
[1]. But I'm not convinced that the API gives the right answer here. If this bot is (perspectively) to be used by a majority of wikiprojects, it might have 1.000.000 article-project assignments to handle (WikiProject Biography alone has 500.000); downloading these via HTTP and feeding them into a local database doesn't seem to be the right approach to me. I would first try to use the API only where necessary, e.g. where accessing the article content cannot be avoided. --
B. Wolterding (
talk)
16:04, 24 July 2008 (UTC)
Yes, I know there are a lot of assessed articles - that's why I suggested using WP 1.0 bot to get the lists on a per-project basis. You need that information anyway, in some form, to determine which projects to notify. You _can_ get it from the database (except when the lag is high), but it would save you work to just ask WP 1.0 bot to give you the list. — Carl (
CBM ·
talk)
16:20, 24 July 2008 (UTC)
I disagree slightly - downloading the WP 1.0 lists and parsing them would be extra work, compared with reading from a database, which I need anyway. And it doesn't give me a full equivalent (there are some projects which do not use assessments). Anyway, it might be a workaround solution in case that the database access doesn't work out; but I'd rather try the direct method first. --
B. Wolterding (
talk)
17:19, 24 July 2008 (UTC)
WP Saskatchewan
I am a bit pokey for the discussion, but we would appreciate notification via this type of bot for the WP SK newsletter, if it was going ahead. Was just going to try to modify
AlexNewArtBot today myself for the purpose of finding tagged SK articles, but knowing which articles are being improved via talk pages would also be enormously helpful!
SriMesh |
talk01:05, 28 July 2008 (UTC)
WP:COMICS
WikiProject Comics would also be interested in the features you could offer here. Thanks for your work in even looking into this, it would be a great feature.
HidingT08:08, 31 July 2008 (UTC)
PROD, FAR and GAR are on my list (see main page); actually PROD is the process I would first start with.
About the cleanup feature, I'm not quite so sure. The bot would certainly not correct the problem, or modify the article and/or talk page in any way; it's designed for reporting only. It might output a reminder notice ("please remember to change the article's assessment"). When are these changes to the assessments usually made - directly after the article is promoted, possibly by the same person that closes the GA process, or typically several days later, maybe by someone else? --
B. Wolterding (
talk)
16:13, 5 August 2008 (UTC)
Regarding the "category cross-check" feature (seeing whether Good Articles are really assessed as GA-Class by the project, and so forth), I have now integrated this into
User:B. Wolterding/Cleanup listings. While these are not so much up-to-date (usually updated once a month), they allow you to find "forgotten" incorrectly assessed articles that may have been around for an extended time. --
B. Wolterding (
talk)
11:39, 8 August 2008 (UTC)
I noticed a comment about that on the main side of this page. When an article is added to a category, a timestamp is recorded, which the API will return along with the category contents. I found that it's not hard to use that timestamp to get the revision info, including the user and edit summary. The api query parameters are:
This requires one query per article+category on the API, which is somewhat impractical. If you use the toolserver, you can probably get the data by just making a join against the revision table. — Carl (
CBM ·
talk)
03:20, 7 August 2008 (UTC)
Why, that's a good idea. Actually the toolserver does not host the page content, so the revision information is not available in the database I think (whereas the timestamp is). But since the information about the nominator is static, it needs to be retrieved only once when the article gets nominated, so an API call might be warranted in this case. --
B. Wolterding (
talk)
14:38, 7 August 2008 (UTC)
The
mw:Revision table is available, which has all the metadata. The only thing that isn't available is the actual page contents. It turns out the timestamp format is a little different between the
mw:categorylinks table and the revision table, so the query looks simething like this:
select page_title, cl_to, rev_timestamp, rev_user_text, rev_comment
from page join categorylinks on page_id = cl_from
join revision on cl_from = rev_page
and date_format(cl_timestamp, '%Y%m%d%H%i%s') = rev_timestamp
where page_namespace = 0 and page_title = 'Fern' limit 10;
This gives the following output:
| page_title | cl_to | rev_timestamp | rev_user_text | rev_comment
| Fern | All_articles_with_unsourced_statements | 20080314023116 | Thedjatclubrock | Reverted
edits by [[Special:Contributions/69.23.85.82|69.23.85.82]] ([[User talk:69.23.85.82|talk]]) to last version by Co
mpwhizii |
| Fern | Articles_with_unsourced_statements_since_April_2008 | 20080610153604 | Philip Trueman | Reverted
edits by [[Special:Contributions/75.144.179.201|75.144.179.201]] ([[User talk:75.144.179.201|talk]]) to last vers
ion by 68.84.66.102 |
| Fern | Articles_with_unsourced_statements_since_June_2007 | 20080314023116 | Thedjatclubrock | Reverted
edits by [[Special:Contributions/69.23.85.82|69.23.85.82]] ([[User talk:69.23.85.82|talk]]) to last version by Co
mpwhizii |
| Fern | Cleanup_from_January_2008 | 20080314023116 | Thedjatclubrock | Reverted
edits by [[Special:Contributions/69.23.85.82|69.23.85.82]] ([[User talk:69.23.85.82|talk]]) to last version by Co
mpwhizii |
| Fern | Pages_with_DOIs_broken_since_2008 | 20080626001428 | DOI bot | Citation
maintenance. Added: doi_brokendate. You can [[WP:DOI|use this bot]] yourself! Please [[User:DOI_bot/bugs|report
any bugs]]. |
| Fern | Pteridophyta | 20080806205047 | Gadfium | restore l
ink; see [[User_talk:EncycloPetey#Te_Ara_links]]
|
| Fern | Wikipedia_laundry_list_cleanup | 20080314023116 | Thedjatclubrock | Reverted
edits by [[Special:Contributions/69.23.85.82|69.23.85.82]] ([[User talk:69.23.85.82|talk]]) to last version by Co
mpwhizii |
7 rows in set (0.03 sec)
Well, all the better! Thanks for the information. (I don't have access to the tool server yet, so I can't see the data there - hopefully an account will eventually be created.) So, it definitely seems feasible to find out who nominated - I will update the main page accordingly. --
B. Wolterding (
talk)
15:51, 7 August 2008 (UTC)
There are some drawbacks - as you can see, the timestamp is reset if the page is removed from the category and then put back. But this is the best solution I know of, since there are no logs of categoryr membership changes.
I left a link on your toolserver request to the bot request archive, where a lot of people supported the concept of this bot. It does take a long time to get an account. The toolserver is run by
Wikimedia Deutschland, and they require that all users disclose their full name. However, they don't release a list of full names publicly. You'll have to decide if you're willing to go along with that. — Carl (
CBM ·
talk)
16:10, 7 August 2008 (UTC)
Thanks for your support. Unfortunately it seems you are right regarding the policies on the tool server. No, I'm definitely not going to disclose my real-life identity. Since, irrespective of our discussion above, I'm now lacking a server to run the bot on, it seems best if I repost this task on the bot request page. --
B. Wolterding (
talk)
12:00, 12 August 2008 (UTC)
The bot will always overwrite the entire page; one reason for that is that it does more than just adding entries, the changes may be quite complex. Anyway, there is a solution for your problem with the two templates: The next version of the bot will allow you to add a project-specific header to the page that will not be overwritten. This is already in use for
User:WolterBot and its 250 subscribers, and works fine there. --
B. Wolterding (
talk)
16:15, 25 September 2008 (UTC)
Hi there, we had a bot doing a very watered-downed version of this and it seems to have gone away. When this goes into the next stages would you keep us in mind? Thanks for the great work you've been doing.
§hep •
¡Talk to me!20:32, 29 September 2008 (UTC)
Could you list what are the output messages for the bot for each type of outputs? This way we could suggest and discuss improvements for them. You made a page with this discussion on, but I can't find it anymore.
AfD: Many articles that don't have their AfD discussion linked. This tends to be with articles that are redirected (AfD 30 Sep 2008 – Eoppa (talk) has been redirected to Egbert of Wessex), or have been deleted (AfD 28 Sep 2008 – Alexandrino Kirton (talk) has been deleted), but sometimes "regular entries" have that link missing too (AfD 29 Sep 2008 – Burial of Jennifer Rosanne States (talk) nominated for deletion by Tavix).
Yes, that's a known restriction (cf. specification); currently the discussion won't be linked if the article's title and the AfD page title don't match, in particular for bundle nominations. This is both for open and closed AfDs, regardless of their result. This restriction may be lifted in the future, but it involves a few additional technical steps, which I'm first testing for GA nominations, see below. --
B. Wolterding (
talk)
19:59, 24 October 2008 (UTC)
CfD: None have discussion linked
True, and I probably won't add them. The problem is that it's pretty hard to find out the correct discussion page automatically, since the CfD discussions are sorted as 1 page per day (not 1 page per CfD). The technical solutions I can think of at the moment would be rather unstable on the long term, so I think it's best to have the user move to the article, then click on the link provided there in the CfD tag. --
B. Wolterding (
talk)
19:59, 24 October 2008 (UTC)
GA Nom/Ressess: None have their GA candidacy/assessment linked
Yes, that's a known restriction (cf. specification). The next version of the bot will implement discussion links for GA nominations, hopefully this works out, can then also be implemented for reassessments and similarly for AfDs. --
B. Wolterding (
talk)
19:59, 24 October 2008 (UTC)
FAC/FAR: Language doesn't seem very uniformed when nominated is open/closed (also apply for the GA Nom and GA Reassess, and FL Nom and Reassess). Format should be something like *
2008-10-02 -
ARTICLE (
talk) is nominated by
USER. (See
discussion) *
2008-10-02 -
ARTICLE (
talk) is promoted/not promoted. (See
discussion).
PR: Might be better to phrase in a way the article appears before the review. Something like *
2008-10-02 -
ARTICLE (
talk) is nominated for peer review by
USER *
2008-10-02 -
ARTICLE (
talk)'s peer review is closed.
I'm not quite sure here; the problem is that there are two distinct "opening" messages, namely "Peer review requested" and "Peer review opened", how should this be rephrased? --
B. Wolterding (
talk)
19:59, 24 October 2008 (UTC)
I'll reply here instead of point by point (most are alright so they wouldn't need replies anyway). The "main" thing I'm looking for is a sort of uniformity. How about using tables (sortable)? This would be of limited utility to small projects, but the bigger projects would have a use for it. Consider the following (each would be in their own section, ISO dates are used for sortability):
Hm, an interesting suggestion! However, this would spoil a bit the possibility to transclude the alerts list somewhere else, for example as a "news ticker" in column format - the complex table layout would not easily be reformatted automatically. Any opinions on that? --
B. Wolterding (
talk)
17:09, 26 October 2008 (UTC)
Using includes and noincludes? Something like this:
Well, yes, of course the tables could be truncated on inclusion; I'm using similar things currently. But I was thinking of a different problem: See
User talk:B. Wolterding/Article alerts#Samples for an example of an alerts list transcluded as a "news ticker", in compact format. This "automatic reformatting" of the list works fine for plain text. But with the complex tables it might become much more difficult - table resizing is always a difficult issue, sometimes browser-dependent, multi-column formatting might run into problems, etc. And, while it would in principle be possible to render the output in two formats (one specifically for inclusion), I would rather avoid this to keep the implementation simple. --
B. Wolterding (
talk)
15:51, 27 October 2008 (UTC)
I originally planned it to run once a day; but the exact period is up to the bot operator of course. (Legoktm, what are your plans?) If performance allows, it could also be run more often, but that should perhaps be decided once a significant number of project uses the bot. --
B. Wolterding (
talk)
16:55, 16 October 2008 (UTC)
Sorry I didn't answer to your suggestions yet. Before the bot rolls out to more projects, I'd like to review the output and make any necessary changes. Then there will be a self-service subscription service much like for
User:WolterBot (this is however not in place right now). I'm quite busy at the moment, but hope I'll be able to do that over the next weeks. --
B. Wolterding (
talk)
16:57, 16 October 2008 (UTC)
Take as much time as you need, else you might forget there's a life outside wikipedia :p. Anyway I'm quite eager to see AAB in action. I think it'll not only make a very significant difference in AfDs/FACs/PRODs/... participation, but it'll make things much more easier to monitor for the Wikiprojects and it might even prevent future losts of interest in some wikiprojects.
Headbomb {
ταλκ –
WP Physics:
PotW}
08:10, 17 October 2008 (UTC)
That's a bit outside the current scope, since it seems that this doesn't correspond to a workflow - there's no "DYK process" that starts and ends at a certain time. Still, a good suggestion for possible future additions; will add it above to the "suggestions list". --
B. Wolterding (
talk)
19:22, 24 October 2008 (UTC)
Open for subscriptions
Hello,
ArticleAlertbot is open for subscriptions now. While some features and layout questions are still being discussed, I felt it is a good idea to make it available to a wider audience now.
Any project or work group can subscribe to the bot by simply placing a template,
User:ArticleAlertbot/Subscription, onto their main project page. If the name of your project banner doesn't match the name of your project page, be sure to specify the correct parameters in the template. This will create an "/Article alerts" subpage of your project page, to which updates (if any are necessary) will be made daily.
Please keep in mind that the bot's features and output format might change in the future. Any comments regarding bugs/change requests/new features can be left on this talk page. --
B. Wolterding (
talk)
09:12, 28 October 2008 (UTC)
Though I've commented above, I just thought I'd re-ask: Would you please consider having deletion discussions and "the rest" being two separate posts, which could then be posted to two separate locations. -
jc3709:19, 28 October 2008 (UTC)
Yes, I noticed that problem too... And in many cases, it's probably best not to have the headings in the TOC at all. Let me try the following variant: I replace the section headings with definition lists, "; Proposed deletion" and so forth. Perhaps that already settles the matter. --
B. Wolterding (
talk)
16:15, 30 October 2008 (UTC)
OK! But the change won't be there with the next edit, the next version of the bot will be ready by the end of the week or so. Will notify you once it's active. --
B. Wolterding (
talk)
17:56, 30 October 2008 (UTC)
Would it be explosive to include articles within a workspace that have been tagged for merging? I happen to think that would be really useful, just to solicit wider feedback more easily.
Randomran (
talk)
16:20, 30 October 2008 (UTC)
Yes and no - I don't think that merging would reasonably be included in the article alerts, since they are not so much "current activity"; some projects have a one-year backlog on merge proposals. This would flood the alerts list. However, you can get a list of merge proposals for your project by subscribing to
User:B. Wolterding/Cleanup listings. The feature is already implemented there. --
B. Wolterding (
talk)
16:25, 30 October 2008 (UTC)
Selection of workflows per project; multiple subscriptions
Feature to be implemented:
Add an option to the bot that restricts article alerts to a selected set of workflows, configurable per subscription.
This could be used to set up several subscriptions per project, e.g. one for deletion and one for featured articles. For each such subscription, the "archivetime" parameter can be set individually. Usage is optional, i.e., for projects that are currently subscribed, nothing will change. --
B. Wolterding (
talk)
17:46, 3 November 2008 (UTC)
Yes, you can separate them. To be precise, you have to set up one subscription per "group" of workflows, whatever you want to consider a group. Each subscription needs to go on a different subpage however. So, for example, create
Wikipedia:WikiProject Ohio/Deletion sorting and place onto that page: {{User:ArticleAlertbot/Subscription|banner=OH-Project|workflows=DEL|archivetime=30}}. This will yield an alerts list only for deletions. Any other combination of workflows is possible; see the
template documentation. --
B. Wolterding (
talk)
20:04, 14 November 2008 (UTC)
Inline discussions
As an option, discussion pages (such as AfD debates) should be transcluded into the article alerts page, rather than only being linked. This option will be configurable on a per-subscription basis (and switched off per default). The feature has the following restrictions:
It works only for some (not all) workflows, since not all have transcludable discussion pages. To be implemented for: AFD, Peer Review, GA review, GTC, all "featured content" workflows. May also be implemented for those GA nominations where the discussion page already exists (it's not created at the beginning of the workflow).
Discussions will be transcluded for active items only (not for closed ones).
To avoid that alert pages explode in length "by accident", transclusion will be limited to 20 discussions per page.
(Not all of these restrictions are strictly necessary - they're what I consider reasonable, feel free to comment.)
At the same time, the behavior of the "/Article alerts" page under transclusion is changed. Currently, transclusion will show an abbreviated list (max. 10 per section). In the future, optionally the complete alerts list, including all inline discussions where applicable, will be transcluded. The default behavior is however not changed. --
B. Wolterding (
talk)
21:47, 4 December 2008 (UTC) (with later edits)
In general, I agree that different archive time frames for individual WikiProjects may be useful. On the other hand, I would like to avoid writing a separate archive page: First, not to double the number of revisions generated; second, to keep things simple. Also, a kind of archive is already available through the page history.
As a simpler alternative, would it suffice if the projects just specify in the subscription template for how long they want to keep their events on the list? (For example, using something like {{Article alerts subscription|archivetime=30}} on the project page, for keeping the archived items for a month.) I don't want to boost the number of these configuration parameters either, but this particular one seems warranted. --
B. Wolterding (
talk)
17:05, 11 August 2008 (UTC)
Currently, at
Wikipedia:WikiProject Comics/Notice board, we have a sub-page archival system of these (similar to CfD's logs), which allows archival, while keeping the text united with the text's history.
Now I can tweak it in several different ways, but my main question is whether the sectioned output of the bot can be placed separately on separate pages, or if the sections must be on the same page. -
jc3701:02, 22 September 2008 (UTC)
All sections will always be written to the same page. Since the entire report is bot-generated and typically not longer than 10kb, splitting it into multiple pages wouldn't make much sense. However, for mixing the report with manually added content, you can transclude the entire bot-generated page into any location you choose. --
B. Wolterding (
talk)
13:24, 22 September 2008 (UTC)
It's a question of archiving the information. So, for example, if all the AfD discussions links were on a single page, then it wouldn't be difficult to archive, by merely moving the relevant line "down" on the page. (On the other side of noinclude tags.) And then the AfD list can be transcluded to the noticeboard, while only showing the most current discussions.
Sorry for the late answer, I'm quite busy at the moment. The archiving functionality is in fact present - old entries will be "moved down" by the bot, depending on date, and automatically enter a "noinclude" section. (This is currently not visible since the bot has run only for a few times.) Currently they're kept there for 5 days, which is quite short, but suitable for testing. Later the "archive period" will be 14 days, but can be prolonged on a per-project level, so you can keep them there for several months if you like. This should work fine for medium-term archiving; it's not really intended for long-time archiving (~years) since entries might get lost occasionally when the bot code changes. If you really need long-time archiving, I suggest the page history. --
B. Wolterding (
talk)
16:22, 25 September 2008 (UTC)
Does it archive by separate sections (the same sections it displays)?
And even if your could split the results in "half" for separate pages: "XfD", and "everything else".
I was wondering if there might be a workaround. Is there a way to suppress what sections it displays/archives on a page? Then I could just have it done to two separate pages, with one page suppressing the "XfD" sections, and another page suppressing "everything else but XfD" sections.
XfD is a fairly big deal, and is likely going to be the most active. (That is, until you add RM/merges/splits : ) -
jc3717:36, 25 September 2008 (UTC)
It archives per section (e.g., AfD, CfD, PROD, GA nominations), old entries will just be moved down as new ones get added, entries within each section are sorted by date.
For suppressing some sections, no, there's currently no such option. But, frankly, I don't quite see the problem that you try to find a workaround for. The concern is (as far as I understand) that the page could become too long, say longer than 100k. But at this time, that seems unlikely to happen. Most projects have no more than 10 or 20 current entries overall; if this amount is archived each week, there's quite a bit of time before the page would overflow. (The exception I see at the moment is
WP:WPBIO, but
that list exists more for testing purposes anyway, I don't think that a long archive of it would be used by anybody. The currently long CfD list for WP Comics seems to be a one-time event, would you agree?) So, what I would suggest is that we wait until the test phase has passed; then we should have a better feeling regarding which problems could occur in a long-time run. --
B. Wolterding (
talk)
16:46, 28 September 2008 (UTC)
No, the concern is adaptability of presentation (and the archiving thereof), ease of use, etc.
Now please don't misunderstand, I think that this is a great tool.
But grouping dissimilar things together, without the ability to customise presentation can be problematic.
And in particular the deletion discussions should be split to a separate "posting" than the rest.
Let me see if I can give you another example besides the WikiProject noticeboard.
And I would suppose that there are other examples.
But all that aside for a moment, is there a coding reason why you're shying away from this being two separate posts (potentially to two separate targets) - "deletion discussions" and "article review"? -
jc3721:43, 9 October 2008 (UTC)
←The "coding reason" is effort: It would be technically possible to separate the output for individual workflows onto individual pages (rather than sections), just as many many other formatting options would be possible. But the more options I implement, the higher the effort in coding and maintenance. The goal is to program one (maintainable) solution that fits the needs of most WikiProjects. So, the question is: Is there a good use case for the extension you describe; does a relevant number of projects want to use it. I'm still skeptical. But, not to discuss too long, consider the following specification.
Add an option to the bot that restricts article alerts to a selected set of workflows, configurable per subscription.
(This could be used to set up several subscriptions per project, e.g. one for deletion and one for featured articles.)
So, with the above would there then be multiple pages updated by the bot for one project. Article alerts/FA, Article alerts/Afd ect? Maybe I'm reading this wrong though.
§hep •
¡Talk to me!21:31, 28 October 2008 (UTC)
Yes, although the pages would be named a bit differently. Basically, you could (optionally) set up subscriptions like {{User:ArticleAlertbot/Subscription|banner=MyProjectBanner|workflows=PROD,AFD}}, that would, in this example, generate alert lists for
WP:PROD and
WP:AFD only. By setting up multiple subscriptions of this type for the same project, on different pages, one would obtain separate lists for deletion, FA, GA, etc. In particular, the "archivetime" could be set differently for each subscription, if this is wanted. --
B. Wolterding (
talk)
12:46, 29 October 2008 (UTC)
(to bw) - Fair enough. Thank you. From a situation which arose recently, I would guess that at least the video game Wikiproject would be interested. And based on the talk page, Middle Earth should be too. I'll ask each (and others).
I could see that working nicely. Although IMO it would be best to have a full subscription setup, then separate pages along with the base page. It would make different types of transclusions viable for sure, but that would increase the bots edits per day by more than a bit. If you decide to roll this feature out ever, WikiProject Ohio has interest in the functionality.
§hep •
¡Talk to me!20:00, 29 October 2008 (UTC)
(Now I'll have to see if I can figure out the syntax. You may have a few questions from me soon : ) -
jc3711:59, 17 November 2008 (UTC)
First question: In looking over the documentation, it seems that the bot automatically writes to a specifically-named /Article alerts subpage of a project. I notice that it's allowed to have more than one request at a project. Is it possible for each such request be posted to a different subpage (for use of transclusion, for example)? -
jc3714:02, 17 November 2008 (UTC)
The problem seems to arise because "Economy for Ohio" had its second FAC nomination, where the discussion is on a different page than usual. Will review that. --
B. Wolterding (
talk)
16:41, 2 November 2008 (UTC)
←This problem is fixed now, after a code change. I saw two examples for these moves at
Wikipedia:WikiProject Biography/Article alerts, where the bot now "followed" the move. I still don't know when these moves occur - I saw them sometimes also for first nominations, but not always. Anyway, the bot will now get around this obstacle. --
B. Wolterding (
talk)
10:20, 17 November 2008 (UTC)
Referring:
This alerts page. If it's documented I must have looked it over, if this is, sorry! I was wondering if it would be possible for the template call to support multiple cats? A taskforce I do a little work with, Ohio State Highways, doesn't have a parent cat just "X"-Class articles categories. Without going through the process of letting the main project modify their banner, can I enter multiple cats for the bot to check?
§hep •
¡Talk to me!19:21, 6 November 2008 (UTC)
That's what I was thinking, I wanted to avoid that. Oh well, I'll see what they let me do. If I put multiple subscriptions on the same project page what happens?
§hep •
¡Talk to me!18:55, 7 November 2008 (UTC)
The bot will read only one. (It reads them from a category, and each page can be in a category only once I think.) You can set up several subpages and set up a subscription on each; but I'm not sure whether this is what you want. --
B. Wolterding (
talk)
19:04, 7 November 2008 (UTC)
That's the one that needs changed! I've been digging through the subtemplates and must have skipped it. If you have time over the weekend, or next week, or next month any help would be appreciated! Thanks.
§hep •
¡Talk to me!19:20, 7 November 2008 (UTC)
Not the bot's fault on this one. Denododge transcluded the article alerts subscription into the banner. I'll fix it and let him know what's up.
§hep •
¡Talk to me!22:01, 10 November 2008 (UTC)
Thanks for fixing this, Stepshep. The article talk pages still appear in ‹The
templateCategory link is being
considered for merging.›Category:ArticleAlertbot subscriptions, but this seems to be a cache problem. In this context, I'm not sure whether it is a good idea to transclude even the article alerts pages (rather than the subscriptions) in a project banner. For larger projects, the alerts page might update daily, and that would cause the server to re-evaluate templates on thousands of talk pages if I understand it correctly. Anybody who has experience in that respect? --
B. Wolterding (
talk)
15:56, 11 November 2008 (UTC)
I took the article alerts out of the banner, since it's causing problems. In my edit summary I directed anyone curious to this discussion.
§hep •
¡Talk to me!04:11, 12 November 2008 (UTC)
It is possible to transclude the article alert lists into multiple other pages if preferred. When doing so, however please be sure to transclude the bot-generated page (ending with "/Article alerts"), not the page with the subscription template on it. Otherwise, not the alerts as such but rather the subscription will be transcluded, which is probably not what you want.
Stepshep is right - in particular, the tag needs to specify "wgcat=WikiProject Saskatchewan articles", not "wgcat=Saskatchewan". The category needs to contain the talk pages of your articles (it's filled by the project banner, typically). I just
corrected the subscription tag, since the bot isn't very good at detecting this kind of configuration problems. I admit this is a bit tricky, perhaps the documentation should be expanded. --
B. Wolterding (
talk)
12:12, 15 December 2008 (UTC)
Should it be {{User:ArticleAlertbot/Subscription|wgcat=Wikipedia:WikiProject Saskatchewan articles}} or {{User:ArticleAlertbot/Subscription|wgcat=WikiProject Saskatchewan articles}} ? The banner uses Wikipedia:WikiProject Saskatchewan. I ask as the robot has still not picked up any error tagged articles :-( Kind Regards.
SriMesh |
talk03:29, 24 December 2008 (UTC)
wgcat just tells the bot what category to look in. It's like putting [[Category:wgcat]] in this case
Category:WikiProject Saskatchewan articles. Are there any articles that have the project banner and that are currently undergoing a supported workflow? It could just be that there's nothing to report. But that's just speculation on my part.
§hep •
¡Talk to me!03:34, 24 December 2008 (UTC)
Well, then, OK, I have nominated an article into DYK
Wade Regehr which does have a SK banner, then I will put an article into peer review and GA to test this thingie, then I will know. Thank you for the heads up about nothing happening.
SriMesh |
talk19:58, 25 December 2008 (UTC)
Just as a note: ArticleAlertbot is currently not running due to ongoing maintenance work on the toolserver
[3]. As of now, the database server there is still down. The last bot run was on Dec 30; I hope that the issue will be resolved soon. --
B. Wolterding (
talk)
16:12, 2 January 2009 (UTC)
The server is now up again, and the bot run on Jan 5 was successful. However, the replication lag on the toolserver is still quite high (it has to catch up with all the edits during the downtime), so the bot output may still be somewhat out of date. --
B. Wolterding (
talk)
00:33, 5 January 2009 (UTC)
Subscription parameter request
In WikiProject Louisville and WikiProject Kentucky, we display (hidden until show) our article alerts in various project templates. And so this produces a lot of links to pages referenced in the alerts. I have received a complaint from a user who did a prod on an article covered by WikiProject Kentucky that too many pages were linking to his user page. I am thinking that a way to alleviate this would be to provide a subscription parameter that lets us not display the "by {user}" portion of each alert. I'm thinking that for our purposes, that part of the alert isn't terribly important anyway. Thanks for your consideration.
Stevie is the man!Talk •
Work19:27, 4 January 2009 (UTC)
Actually, the problem you report is only the "tip of the iceberg", and I strongly suggest that you do not transclude the alerts list into your project banner. Namely, not only the "What links here" list of the user pages is flooded with entries, but also the same list for the actual articles. Worse, the transclusion means that, each time the alerts list is changes - usually daily -, the MediaWiki software has to re-generate each page in which the list is transcluded, which can be several thousands. I am convinced that this can generate a performance issue if used on a larger scale (even if I have not yet received specific complaints about that).
In short: Please do not transclude the alerts into the project banner. Instead, you may provide a link to the alerts list within the project banner. This serves almost the same purpose, but avoids the issues above.
In fact, since this is not the first time the problem appears, I should probably change the bot so that such transclusions of alerts lists into talk namespaces are prevented in the first place. I will keep that on my to do list. --
B. Wolterding (
talk)
20:22, 5 January 2009 (UTC)
I understand your position, but I don't like the inconvenience this approach causes. How about creating link-less alerts with a new subscription parameter?
Stevie is the man!Talk •
Work21:05, 5 January 2009 (UTC)
I don't agree that this is a significant issue, as pages are not regenerated any more frequently because the contents of an included template changes. There would only be a problem if a changed included template forced a purge upon the change, and that doesn't happen.
Stevie is the man!Talk •
Work03:09, 7 January 2009 (UTC)
That looks useful, but then again we have
limits. I've been thinking on this and was wondering if it would be possible to have the alerts detect if they were on a Talk: page and switch the content to a link if they were?
§hep •
¡Talk to me!21:07, 5 January 2009 (UTC)
Yes, I think you're on the right track there, but I think it's the reverse -- if they're on a talk page, and perhaps further if they are contained within a project banner, remove the links that appear in the alerts.
Stevie is the man!Talk •
Work21:11, 5 January 2009 (UTC)
I was thinking about wrapping the entire bot output into "{{#ifeq:{{NAMESPACE}}|Talk|ERROR|...}}", but I didn't try that yet. --
B. Wolterding (
talk)
23:20, 6 January 2009 (UTC)
←It is way too complicated to wrap every wikilink like {{#ifeq: {{NAMESPACE}} | Talk | User:Example | [[User:Example]]}} just to be able to transclude it. LegoKontribsTalkM07:46, 7 January 2009 (UTC)
Still what Bert said above still applies: "Worse, the transclusion means that, each time the alerts list is changes - usually daily -, the MediaWiki software has to re-generate each page in which the list is transcluded, which can be several thousands. I am convinced that this can generate a performance issue if used on a larger scale (even if I have not yet received specific complaints about that)." LegoKontribsTalkM06:13, 8 January 2009 (UTC)
Is there any Wikipedia documentation that explains this? It is my impression that MediaWiki software regenerates each page on a regular basis, whether something transcluded on it has changed or not, so how can there be any special effect from placing article alerts in a project template?
Stevie is the man!Talk •
Work16:39, 8 January 2009 (UTC)
OK, so until a sysadmin tells us that there is a significant performance issue with this aspect of embedding once-a-day changing information in project templates, we're good.
Stevie is the man!Talk •
Work20:06, 9 January 2009 (UTC)
I can't imagine how any limits are hit by the inclusion of article alerts into a project template. These alert lists are generally short, from what I've seen, and the alerts expire, so the lists never seem to grow past a certain point. I think a mountain is being made out of a molehill on this.
Stevie is the man!Talk •
Work21:26, 9 January 2009 (UTC)
To explain this in a bit more detail: Whenever a template is changed, MediaWiki has to update the cached form of every page that transcludes this template (even if this transclusion is indirect, i.e. via several steps of transclusion). Thus, if the bot updates the article alerts page, MediaWiki needs to update every page that transcludes the article alerts page. This is not bad as long as we're talking about 3 or 4 pages.
However, if you transclude the alerts into your project banner, this means that each edit to the alerts (by the bot, daily) will require every talk page assigned to the project to be updated. Depending on the project in question, this can be hundreds or even tens of thousands of pages. As explained in
WP:HRT#Rationale, this should be avoided for performance reasons.
When you edit as a single user, performance aspects on Wikipedia are nothing you should typically worry about. However, with bot edits one needs to be sensible; and the question at hand, in my opinion, quite obviously raises performance issues. And I'm not going to wait until a developer blocks the bot. That being said, I will invite some discussions at the
bot owner's noticeboard, perhaps we can get a clearer picture with more people involved. --
B. Wolterding (
talk)
00:33, 12 January 2009 (UTC)
As noted above, this is a problem with the toolserver database (not specifically with the bot) - the data is just a bit out of date. This should be fixed during the next days. --
B. Wolterding (
talk)
20:11, 5 January 2009 (UTC)
Yes, it seems that this has happened to all pages. Very strange indeed. There is a functionality in the bot that adds content to pages, rather than replacing it, but I'm completely clueless as to why this has been triggered. Will have a look at the logs. --
B. Wolterding (
talk)
16:48, 12 December 2008 (UTC)
Just wait until this night. I expect that the bot will now overwrite the entire page, it has done so all the time before, and there has been no configuration change that I'm aware of. If it misbehaves again, some manual action may be required. --
B. Wolterding (
talk)
16:53, 12 December 2008 (UTC)
It seems that the problem didn't reoccur in the last run. I'm still unsure why it occurred in the first place; the code hasn't changed. Let's wait whether we see the problem again. --
B. Wolterding (
talk)
15:34, 13 December 2008 (UTC)
True, your edit to the talk page was somewhat later
[4]. It seems that this falsely triggered a category timestamp update - they don't seem to be so accurate after all in MediaWiki... I'll ask on the VP for general experience with that. --
B. Wolterding (
talk)
21:35, 29 December 2008 (UTC)
No, it wasn't your fault... MediaWiki handles these timestamps internally, and apparantly it's a bit inconsistent in doing that; but the user has no influence on when the timestamp is updated (as far as I'm aware). --
B. Wolterding (
talk)
22:33, 29 December 2008 (UTC)
I first notice use of this bot when someone began using it at
WP:CITIES. I would appreciate if you would fix it so that it prints the Featured article candidates and Featured article reviews above the listings for GAs and GARs. Featured articles are the highest quality articles, and the highest review process we have -- as such, if this bot is listing them on wikiproject pages, FA/FARs should be listed first.
Also, is there a way to customize this bot to tailor it to specific wikiprojects. For example, I am not interested in having Requests for Comments listed in the same category in our wikiproject as the other review processes, since it is NOT a review process itself. We handle requests for comments on the talk page and announcements, so it's completely useless (and actually inappropriate) to list them with review processes.
Dr. Cash (
talk)
21:22, 19 January 2009 (UTC)
Yes you can customize what you want to show. See the subection on this main page (
here), titled Subscription. I will disagree with you though,
RFCs are review processes.
§hep •
Talk00:16, 20 January 2009 (UTC)
If I customize the order of what I want to show (e.g. 'workflows=FEAT, GOOD', will that also solve the problem of putting FA before GA?).
Dr. Cash (
talk)
22:12, 21 January 2009 (UTC)
No, but you could set one page to do workflows GOOD, and another subpage to do workflows FEAT and then transclude the featured /Article alerts above the good /Article alerts. My words aren't so good, I'll show you what I mean.
§hep •
Talk22:40, 22 January 2009 (UTC)
The order of workflows can indeed not be changed on a per-project basis. I can change it globally if that is wanted. (Anybody who insists on GA before FA? It was more of a random choice by me.) --
B. Wolterding (
talk)
15:48, 25 January 2009 (UTC)
If all it was was a random choice by you, it was a rather poor one. The order of article review priorities has always been FA > A > GA > B > C > Start > Stub. True, one can argue the GA vs. A deal, but FA is without a dispute, Wikipedia's highest level of quality, and therefore should be listed first in the order of precedence. I fail to see what else there is to debate about this.
Dr. Cash (
talk)
23:28, 5 February 2009 (UTC)
Usually one day. (It has actually been generated now, see
Wikipedia:WikiProject Pharmacology/Article alerts.) The problem probably was that you did not add the subscription template to your main project page, but rather to a transcluded subpage. This can cause a number of problems. (The alert were first created in the wrong place; Legoktm corrected that on Feb 2, but apparently it took some more time for the transclusion to be updated.) --
B. Wolterding (
talk)
11:49, 6 February 2009 (UTC)
Ok, thanks. I see it now. It might be useful to add things like this situation to the documentation on subscribing, since there may be other wikiproject pages set up like this.
Dr. Cash (
talk)
19:13, 6 February 2009 (UTC)
I recently discovered this service, and fell in love with it immediately. One request though: Is it possible to add another view which transcludes the actual discussions onto the alerts page? For instance, on
Wikipedia:WikiProject Anime and manga/Peer review, it is customary to transclude the discussions to allow easy review thereof.
Ps. I believe that this would only be applicable to "open" items, with the normal summary being used for "closed" items.
Well, yet another conditional formatting option... on the other hand, your idea seems persuasive; this might be useful at least for alert list that are not too long. I'll look into that. However, just as a caveat: This will not work for all workflows, just for some. E.g. AfD and peer review discussions can be transcluded, but e.g. for CfD this is not possible. --
B. Wolterding (
talk)
13:01, 2 December 2008 (UTC)
Thank you. Having done this manually in the past, I believe this is possible for PR, FA, FAR, FL, FLR, GAR (but not GA, as the page is created by the reviewer), AFD. maybe GT/FT. The most likely use is AFD, though (deletion sorting).
G.A.Stalk16:57, 2 December 2008 (UTC)
I'm not sure if the language is the same, but before using this bot, WP:OH used
Parent5446 Bot (no inactive). It transcluded just discussions for a few things. An example of what it used to look like is
here, there are also a few subpages of the bot account. I hope this proves a little helpful.
§hep •
¡Talk to me!23:54, 2 December 2008 (UTC)
I have a question about this: What should happen if the alert page (/Article alerts) itself is transcluded? At the moment, transclusion of "/Article alerts" produces an abbreviated version of the list, limited to 10 entries per section. This is used e.g. for displaying a kind of news ticker (
see here for an example). Now if the alert page transcludes the discussions, and another page transcludes the alerts page, what should happen? Recursively transcluding all discussions will break the newsticker format. On the other hand, I could think of some applications where it is precisely intended to transclude the complete alerts page without abbreviaton and including the discussions. Could you give an example of where you are going to use this feature? That may provide some insight. --
B. Wolterding (
talk)
12:22, 3 December 2008 (UTC)
The most useful use would be if the bot can maintain a section like
WP:ANIME/D#Anime and manga, which rapidly changes, and may see a lot of action on one day; in this case it is crucial that all active entries are visable from
WP:ANIME/D. The bot can automate a lot of the work associated with the list's maintenance, even if some work is still done by hand, i.e. archiving.
Wikipedia:WikiProject Anime and manga/Peer review works in a similar fashion, but became too troublesome to maintain lately.. Regards,
G.A.Stalk21:43, 3 December 2008 (UTC)
I have now implemented this at least for AfD; other workflows are then rather easy to add. Please have a look at the test page,
here and
here. Is this the way you intended the discussions to be shown? --
B. Wolterding (
talk)
00:18, 9 December 2008 (UTC)
That looks good, though I'm not the requester; would it be possible to make the discussions use something like {{hidden}} so they don't take up so much space?
§hep •
¡Talk to me!01:10, 9 December 2008 (UTC)
It seems to work as intended, though a good/better idea for the display might be as follow (per Stepshep's suggestion, modified a bit so active discussions shows (should be optional?), but completed discussions not). Note that I combined the news entry with the header, as this makes the news entry more distinctive, and more natural. I also removed "(see discussion)", as the transclusion serves the same purpose.
<div class="NavFrame" style="text-align:left; border:0px"><div class="NavHead">8 Dec 2008 – [[13 Nichi wa Kin'youbi?]] ([[Talk:13 Nichi wa Kin'youbi?|talk]]) nominated for deletion by [[User:Mikeblas|Mikeblas]].</div><div class="NavContent" style="display:yes; text-align:left;">
{{Wikipedia:Articles for deletion/13 Nichi wa Kin'youbi?}}
</div></div>
<div class="NavFrame collapsed" style="text-align:left; border:0px"><div class="NavHead">8 Dec 2008 – [[Talon (Static Shock)]] ([[Talk:Talon (Static Shock)|talk]]) has been redirected to [[Static Shock]].</div><div class="NavContent" style="text-align:left;">
{{Wikipedia:Articles for deletion/Talon (Static Shock)|discussion}}
</div></div>
Yes, that seems reasonable. Although the resulting page might grow quite large if all discussions are transcluded (whether hidden or not) - but let's give it a try. --
B. Wolterding (
talk)
11:11, 10 December 2008 (UTC)
I do not really believe that size will be such an issue, the project can just turn the transclusion off, or limit the workflows.
G.A.Stalk11:59, 10 December 2008 (UTC)
If the transclusion is done via a template (e.g. The bot only populates the fields in {{AFDAlert|date=8 Dec 2008|article=Talon (Static Shock)|action=redirected|target=Static Shock]|discussion=Wikipedia:Articles for deletion/Talon (Static Shock)|show={{{parameter (all/active/none/off)}}}}}), this will be highly customisable without requiring additional coding for the bot for each later change.
G.A.Stalk21:25, 10 December 2008 (UTC)
I have prepared another version for rollout now, should go live the next days. It contains the expand/collapse feature as well as transclusions for most other workflows (but excluding GA nominations). Regarding the customization by template, I used that in the previous version but it's becoming more complicated now - since the article's title is passed, I'd need to add special handling for the case when the title contains an equals sign, pipe character, and possibly more. Will look into that later. Collapsing all sections is definitely possible as an option (though not yet implemented, but it's easy to add). --
B. Wolterding (
talk)
16:39, 11 December 2008 (UTC)
Thanks! I do not believe that articles can contain pipe signs. The equal sign complicates things somewhat, but parameters would only work correctly if you transclude items (unless you start messing around with defaults for the parameters).
G.A.Stalk18:23, 11 December 2008 (UTC)
Sorry for the late reply, I was busy for some time. No, it seems that Legoktm has not yet rolled out the change yet. It's not yet active. I'll look into that. --
B. Wolterding (
talk)
13:35, 26 December 2008 (UTC)
It seems that Legoktm is on a wikibreak, so the feature will not be live this year I think. I'll post some test output later. (Should have done that before, probably, rather than try to test it on the live system...) --
B. Wolterding (
talk)
14:15, 29 December 2008 (UTC)
Here's some test output to review before the change goes live:
(1) with inactive sections collapsed,
(2) with all section collapsed. Note that this output is based on test data which is outdated, incomplete, inaccurate, and partially made-up; e.g. articles may be reported as "deleted" although they have been kept; the only purpose is to demonstrate the show/hide functionality and discussion transclusion. --
B. Wolterding (
talk)
21:29, 29 December 2008 (UTC)
Oh yes, very nice:) Thank you for all your hard work. No worries about the late reply, even I have been very inactive these last few weeks.
G.A.Stalk14:12, 2 January 2009 (UTC)
This feature has now (finally) reached the live bot. See
Wikipedia:ArticleAlertbot test page for an example. (Note: This is the variant "show active sections and collapse closed ones"; the variant "collapse all sections" is available as well.) I will document the subscription parameter shortly. --
B. Wolterding (
talk)
00:48, 2 February 2009 (UTC)
Can you maybe change "<div class="NavFrame" style="text-align:left; border:0px">" to <div class="NavFrame" style="text-align:left; border:0px; padding:0px"> to improve readability in the collapsed view?
G.A.Stalk12:26, 6 February 2009 (UTC)
From a user perspective, yes that would make sense. I left it out because it's not so easy, on the technical side, to find out where to link to for the RFC. The RFC template doesn't tell you. With some more advanced analysis of the page text it should be possible though. --
B. Wolterding (
talk)
00:44, 12 January 2009 (UTC)
This page is an
archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page.