In T217730#5041173, @Mbch331 wrote:

I don't see the links to other wiki's on Wikimaniawiki. Also checked nlwiki and there I see a link to Wikimaniawiki.

Working for me
https://www.wikidata.org/w/index.php?title=Q7605021&diff=prev&oldid=888844922
https://www.wikidata.org/w/index.php?title=Q5622198&diff=prev&oldid=888844164

I will rephrase that. It works when done as the converted hex text, though not as unicode text. It would be most useful to not have to do a conversion.

@Aklapper Are we able to reopen this or do I need to do a new bug report

Can I flag this one again to the community. We are back facing issues at meta for spamblacklist. The above workarounds are not working, and I believe that I have followed the stated conventions. Thanks.

There are some links above which have custom policy, though I am unaware of any private tasks that were mentioned at that time.

Other bits:

• In all cases, I think a list of migrated pages should be generated per namespace and stored on wiki in Wikimania:Migration/YYYY/Namespace
• WD linking is not initiated at this point, though I don't see that it is going to be an issue as we have a standard implementation, with the additional content wikis. There is no existing WD configuration that would need to be amended for this migration. All uncharted!
• I am guessing that we would update the interwiki maps to relink to wmania:YYYY:$1 respectively. Guessing that internal mapping

'''Category pages'''

This is the area that could be most problematic, as it has the biggest overlap, though my light cruising through the wikis doesn't show a high use of the project namespaces. It would be useful to generate a report to see what exists needs to be managed. I would think that we could just move Wikimania:pagename to wikimania:pagename/YYYY and we can manipulate from there.

Mediawiki: ns pages

translations pages

help pages

'''User pages''' should be unique per user since the update for SUL, presuming that username overlaps where resolved for closed wikis when SUL migration occurred.

Templates and modules are each going to need to be merged into the one namespace for each so that they function with imported pages.

Content pages for each wikimania 2005 -> 2018

I would like to have a better understanding of the likelihood of the what and when for the migration of these wikis into wikimaniawiki, so the ongoing design can be considered and look to be consulted.

Just wondered where this is currently sitting. I truly (for the 1000+th time) could do with the ability to search both Special:Log/spamblacklist, Special:DeletedContributions and Special:Abuselog by IP range. Where we have spambot activity, it is next to impossible to identify where the spambots are happening by any reasonable functionality than browser search.

In T215433#4934224, @Billinghurst wrote:

If on wiki, we should do in the Project:/Wikimania: namespace.

As a general comment. We will have three active content namespace to manage

• Wikimania:/Project: mechanics of operating the wiki
• Main (ns:0) which will be enduring
• 2019: for all specific WMSE WM content; though it may have some parent components in main; or may simply be redirects to 2019:

If on wiki, we should do in the Project:/Wikimania: namespace.

it is just a matter of shuffling, so it is easy to reposition if/when we change our minds

Import rights done @Trizek

In T214704#4921490, @Billinghurst wrote:

In T214704#4921454, @Eric_Luth_WMSE wrote:

@Billinghurst 's proposal seems reasonable. Such a structure is something along the lines of what I envisioned.

rights requested https://meta.wikimedia.org/wiki/special:diff/18837115/prev

'crats assigned

In T215031#4921397, @Peachey88 wrote:

Each year will have a namespace (2019s already exists) on the new wiki, so it can still work that, instead of (Main NS):2019/Schedule it would just be 2019:Schedule the namespaces that people will need to be careful will be Template, File, Category etc.

From memory, I have also read that the search system has been set to default to the 2019 namespace as well.

In T214704#4921454, @Eric_Luth_WMSE wrote:

@Billinghurst 's proposal seems reasonable. Such a structure is something along the lines of what I envisioned.

In T214704#4921394, @Eric_Luth_WMSE wrote:

@Billinghurst It would be great if the WMSE employees had admin rights in order to do smaller tasks until the next host organization takes over, but my goal is that the main work is carried out by volunteers. Thus, I'd like to delegate as much as possible. In the case that there's crucial tasks that no volunteers want to do, we do have capacity at the office.

In T215031#4921038, @Trizek wrote:

Don't forget to import translations if you import things that were marked for translation.

In T214704#4921041, @Trizek wrote:

In T214704#4916708, @Billinghurst wrote:

I would suggest that any admin rights can be managed through this ticket for the foreseeable future [...]

Excellent idea. As I can work on translations, I'm looking for translation admin rights (I have them on Meta). If possible, I would request sysop rights, which is always convenient to have when you work on translations (I have those rights on fr.wp).

In T215031#4920987, @Harej wrote:

WikiConference North America does “Year/Pagename” e.g. “2018/Schedule” along with per-year templates that strip out the year prefix in the displayed page title and add a year-specific tagline. We have done five of these conferences now and this system has worked well for us.

The one thing that has been tumbling over in my mind is now that there is one wiki for many years, there will need to be the hierarchy to cover many years. In previous wikis, they could do it all one level down from root, and not have to worry about next year, that is no longer the case.

volunteers and head label back

I can just roll it back if you don't like it, that is easy.

Imported common.js
imported common.css and removed megaheader components

I am no css expert either, though know the basics

Can I start off with asking for full import rights, so I can import translated labels for Commons gadgets. Doing them all by hand (with my typing) will just introduce errors.

Questions. Looking at WM2018, I am wondering whether as some basics, whether you wish to have the following brought over

I can talk about stewardry processes from a previous life, they are looking for a process to know that an authority process has been undertaken. I would suggest that initially some names are put forward to be crats and approved here on phab. I would suggest that any admin rights can be managed through this ticket for the foreseeable future, and that they are set time limited (up to one year). The rights process for a permanent wikimaniawiki can be developed as things progress.

@Eric_Luth_WMSE We are going to need to work on rights pretty soon at least for allowing for translation admins. Probably best if the wiki can get bureaucrat(s) so that can be assigned locally; otherwise we can just lay them on the stewards through meta as long as you line up an approval process that sits outs outside of standard wikis

I have imported wm2018, rem'd the lines leaving

Current sidebar from wm2018 is

You always have a means to over-complicate what should be kept simple. Anyway, none of what you are talking about belongs in proofreadpage. If you wish to discuss that at English Wikisource, then go for it. None of it belongs in phabricator.

It is not a function of transclusion, this solely is part of English Wikisource's page numbering javascript, there is nothing for a phabricator ticket.

Have you tried writing it into the help pages for the extension? A parenthesis shouldn't be considered a page number, and the instructions are specific about what are available page numbering styles
https://wikisource.org/wiki/Wikisource:ProofreadPage
Why would you be adding some decorative aspect? If there was any part to be added, it would be better added to the page numbering style anyway.

This is completely part of the javascript page numbering functionality, and how it hides page numbers when they are squashed together preventing overlap, as that they don't fit in the same space. Simply use the exclude functionality of <pages> to omit the first blank page so it doesn't obscure the subsequent page number.

@Daimona <shrug> I am just nuff nuff spam handler and typical end user who needs some abilities to better handle the abusefilter/log which has become a morass. I talk about desires in tools that allow me to work efficiently; and to better and more effectively protect our wikis. I generally put up with the inefficiencies in the system, however, when I get to the point of "f*** it" and am throwing my hands up (again) that this is wearing me down, then I will speak up.

Is it possible to look at something other than a binary solution (off/on). For those of us who do the unheralded work in the background — spambots, vandals, LTA — having something to make our life easier would be most helpful; most especially at meta for the global filters where the spambot hits drown out others. Is there an intermediate measure other than at a point of call generation. Is it possible that this could be updated hourly, of six hourly?

@Mahitgar for you at mrwiki

Will this be a cheap or an expensive call? Trying to work out where it should be placed in the coding sequence?

@WhatamIdoing

@Leaderboard

This is not an issue. Metawiki is perfectly able to decide its filters and how to use them. This user is not listening to the fact that we don't wish to undertake their suggestions. Non-issue.

This month is truly a good indicator of how we could make abuse filters useful instead of clagged with superfluous, duplicated hits.

@Whatamidoing-WMF a local example of our recent conversation

Emended possibly reference to admins "locking themselves out". Locks are imposed by stewards and are global, blocks by admins are local to the wiki. Presuming that the ability for stewards to LOCK themselves is still present.

I tell you what I find truly infuriating about this implementation

In T112715#4755586, @WalterKlossew wrote:

I created a proposal on Community Wishlist Survey for URL shortener for Wikimedia wikis.

@Addshore As I mentioned above, whilst I a having some issues with WD directly, I am having greater issues with WEF framework tool's lookups. As I create items and do the lookup for matching terms it is finding items successfully, though the rendering of the name into the visible for selection is regularly not occurring. If it was anything but the lookup I could say I had caching issues, however, the lookup will be fresh name every time.

I regularly use the WEF Framework gadget, and over the last several days I am seeing this problem come and go.

In T113450#4502922, @JAnD wrote:

Bot still does not by default marks as botedit

pwb.py touch -family:wikisource -start:Page:!

https://cs.wikisource.org/w/index.php?limit=50&title=Speciální%3APříspěvky&contribs=user&target=JAnDbot&namespace=&tagfilter=&start=2018-08-14&end=2018-08-14

It doesn't read that way. And nearly always mirroring is not 'always mirroring'

Can you please point to the community consensus for this change. I do not believe that this change should take place without a community consensus.

I have no knowledge of which is the best way to fix it, I suspect all pages is gross overkill rather than targeting the Index: ns.

similarly any Page: namespace edit kills the page status colouration

null edit kills the page status colouration for anonymous logins. Purge will bring it back.

yes
https://en.wikisource.org/wiki/Index:The_empire_and_the_century.djvu

In T59198#4420208, @Candalua wrote:

In T59198#4418053, @Billinghurst wrote:

Thanks, though not certain that we have it right.

To note that what we seem to have achieved is to support the display of the number of pages to be moved from proofread -> validated, rather than the total number of pages remaining to be validated.

There seems to be a misunderstanding. To "validate" a page means exactly to move it from "proofread" to "validated" status. And this is what has been done, as this is what was asked. A possible application can be: I want to launch a "validation of the month" contest, and I need a list of books with lots of pages ready to be validated.

Now what you are asking is a different thing, that I would call "total number of pages remaining to be proofread and/or validated", i.e. pages where some kind of work (transcription, formatting, validation...) needs to be done. This looks easy to do, so I'll see if I can add a further option using your formula.

I'm not sure if it's possible to exclude books with 0 of such pages, but I'll look into it.

confirming that this is working in the wild, thanks all for their work.

Thanks, though not certain that we have it right.

For anonymous user, index pages that I view randomly the pages show without page status in anonymous, though are showing with page status as logged-in user. If I purge (and wait) doesn't matter whether I am logged -in or anonymous to purge, then the Index: pages do update and remain updated.

In T199288#4414827, @Tpt wrote:

As a logged-in user, it will also show normally/as expected.

It's interesting. As a logged-in user they whee not shown to me but if I try to edit the page and ask for a preview it works.

It looks like a cache problem.

Is -summary global? It is not listed at https://www.mediawiki.org/wiki/Manual:Pywikibot/Global_Options How does one know which of the options are global? I will try that, thanks.

Please see T198470 for the task being managed

ahem. You may not wish to do the task, that does not make it unnecessary or yours to close. Thanks for that unilateral decision.

touch is an edit, and as there has been underlying change in the schema that WS pages it will in essence be an edit. FWIW the interaction of ProofreadPage and Mediawiki has had changes in the page interaction. Also Wikisource transcription processes will often have pages not edited for that many years, so please not be hasty about the age of a page, there are more uses than just Wikipedias.