Last modified: 2013-07-30 01:21:20 UTC
It is very hard to find all active campaigns for a wiki (the combination of project and language), because Special:CentralNotice does not show all languages or/and projects for each campaigns, for example it has sometimes Multiple (372) or Multiple (10). Having a filter to find all campaigns for a project, a language or a combination of project and language would be very fine. Thanks.
Isn't that what http://meta.wikimedia.org/wiki/Special:BannerAllocation does?
(In reply to comment #1) > Isn't that what http://meta.wikimedia.org/wiki/Special:BannerAllocation does? That looks good, I have never tested all the tabs are shown on the special pages. Thanks. But you have to choose an item in all boxes. If possible it is nice to have a way, to set a box to "all" to have the following searches: * project, language and country together * project and language together (with country = all) * project and country together (with language = all) * language and country together (with project = all) * project alone (with language and country = all) * language alone (with project and country = all) * country alone (with project and language = all)
This sounds like a good idea, but is potentially a nightmare to implement. The problem is that if you search for allocation across all Wikipedias, for example, you could get 89,280 different results (372 languages x 240 countries). Obviously we don't want to output 89,280 separate tables. If you have any ideas for how to deal with this, let me know.
89280 are many possible entrys. But I have not any ideas to solve that problem at the moment.
(In reply to comment #3) > This sounds like a good idea, but is potentially a nightmare to implement. The > problem is that if you search for allocation across all Wikipedias, for > example, you could get 89,280 different results (372 languages x 240 > countries). Obviously we don't want to output 89,280 separate tables. If you > have any ideas for how to deal with this, let me know. I don't understand this. As I see it, you'd have three drop-downs, all with a particular filter type, and one option of "all" (very similar to the current setup). If there are a lot of results, you can paginate, right? That's what you'd do with a large data set in nearly any other context. Set a limit and paginate through the results with an offset. I think pagination might be easier to implement if BannerAllocation used GET instead of POST. Not really sure why it's currently using POST. Probably the subject of a separate bug, though.
(In reply to comment #5) > I think pagination might be easier to implement if BannerAllocation used GET > instead of POST. Not really sure why it's currently using POST. Probably the > subject of a separate bug, though. I filed bug 30271 to track the GET/POST issue.
A combination of things such as not grouping things on the main page and having Global Allocation should have solved this. Closing unless we have more things to add.
