User Details
- User Since
- Oct 22 2015, 7:57 PM (413 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Vladis13 [ Global Accounts ]
Aug 13 2023
The bot made 4 new items, seems to work. I close the issue, reopen if the problem is not solved. Thanks for the answer.
Aug 12 2023
ID is not returned in about 20-30% of cases, as I noticed.
Aug 5 2023
Aug 1 2023
Let me answer the complexities listed in the T275319#7947012.
Jul 31 2023
You call it a personal attack, although I only repeated your words "just your opinion". In addition, you reproach me personally with the rule of the Russian Wikisource, based on the policy of the Terms of Use of Wikimedia Foundation. Yes, this is all a personal attack, only yours.
It is obvious from your words that you have not read the discussion and arguments above. Including that all the users who spoke here from different language projects of Wikisource spoke in favor of expanding the limit. Due to big problems in splitting of pages for editors and usability for readers.
The expansion of the limit will not cause any technical problems.
Your opinion is the only your opinion as a Wikipedia user. This topic doesn't concern you at all.
Jun 2 2023
I provided a link to the error.
This was an issue well before 2018.
Jun 1 2023
May 7 2023
Oct 24 2022
Sep 26 2022
Now the script says "intersection" even when I use only one category:
pwb.py category -site:wikisource:ru -cat:"Дистрикт Галиция" remove -from:"Дивизия СС «Галичина»" -simulate Retrieving intersection of generators. Retrieving 4 pages from wikisource:ru.
Sep 21 2022
How to remove pages from a category by generator? The only way is to use the replace.py script with the -regex argument?
pwb.py replace -family:wikisource -lang:ru -cat:"ОУН-УПА" -regex '\[\[Категория:Украина\]\]\n?' ''
There is also confusion with the name of the argument.
The script (by page generator) execute for each page the remove -from:category_name command. In human terms, this means: remove this page from the category.
But it turns out that it completely clears the category, removing all pages, with one command without restrictions and the ability to filter the process. Then this command should be called as "clear category".
But the script already has a clean command, which has no description. What it does? Is this a duplicate of remove?
Hm. The category.py help at https://doc.wikimedia.org/pywikibot/stable/scripts/main.html#module-scripts.category also says "This script supports use of pywikibot.pagegenerators arguments."
All of these scripts are based on pywikibot.pagegenerators and pywikibot.bot, and use common generator arguments.
If this script is somehow strange, could you remove the list of generator commands from the script's help (pwb.py category -help) and from its page https://www.mediawiki.org/wiki/Manual:Pywikibot/category.py#Generators_and_filters_available ?
How to disable -always for other bulk edit commands?
I use the remove command, examples are given here T318239.
Jun 3 2022
@Samwilson About listing participants. Personally, I do not look at such lists in e-book files at all, and skip the title pages when I read them.
Moreover, usually the users who performed OCR, importing and proofreading indicate themselves under meaningless pseudonyms. In this case, a link to the wikipage with its edit history is sufficient.
Thanks, I added class="ws-noexport" in the tag of this image of the page layout, so now its uploader is excluded from the list.
Jun 2 2022
The database schema do not require modification. The database text column is of type binary MEDIUMBLOB, GZIPed diffs are written there. The MEDIUMBLOB type can store up to 16Mb of data per entry, i.e. this is the diff size limit for any page edit (revision).
The number of page edits is not limited, all diffs are collected together only when the page is rendered. If we recall the words of the documentation "The compression ratio achieved on Wikimedia sites nears 98%." (DB doc), then it can be argued that the current database schema can store pages of infinite size.
May 21 2022
May 7 2022
Jan 13 2022
Seems, yes. Thank you very much!
I checked the places where the bug could appear. It was massive, if the bug remained somewhere I didn't notice, I'll let you know.
Jan 12 2022
@Ladsgroup, I closed it up there, was 2 weeks of the poll. All administrators, bureaucrat and active users voted. Consensus.
Dec 29 2021
Here is the community consensus.
Dec 24 2021
It seems to me that this option should not cause side problems. All important transclusions are on the users watchlists.
Nov 23 2021
@Tacsipacsi, thanks. But you answered an old example from 2019. At the time, I fixed it, bypassing the problem by moving all inclusions to Template NS. Several times I moved the page through different namespaces, tried patrolling and bouncing back, changed the settings for page stabilization and transclusions in different ways... it didn't help.
Nov 19 2021
We probably have 30% of the entire Wikisource (!!!) with warnings that pages need to be patrolled, or it will appear after any editing of the page. Because our main template for texts in Main NS is dependent with json settings and modules in the Mediawiki NS that can be edited.
Sep 25 2021
Jun 16 2021
May 13 2021
Sure, calendar algorithms, like Julian day as well as Unix time are beyond the scope of ISO.
It seems to be correct to keep the date as given in the printed source (let it be Julian "44-03-15" BC), without the Gregorian conversion variations. E. g. Wikidata birthdays: d:Q1048, d:Q5592. Will the date format have a code (like "J") about the calendar being used? Current #time supports codes for multiple calendars, excluding Julian.
Is the date format will has a mark to indicate which the calendar used? As a kind of wiki extension to the EDTF format. Like, Julian date "J44-03-15".
Or will need to keep specifying an additional tag about the date calendar? Like a string description in the text next to the date, an additional parameter in templates, a switch / qualifier in the Wikidata properties.
May 10 2021
The community of Python language hasn't heard of EDTF either. stackoverflow, docs.python.org, supported format-codes. The size of this community is almost larger than that of Javascript and Php (on which the Wiki is written). Pywikibot is written in Python.
So, can be sure that the generally programming languages will not adopt the standard in the coming years.
Apr 9 2021
Thanks you.
Was Pwb 3.0.dev0 (this version number did not change until this year for several years, although Pwb itself was regularly updated, probably it was a bug) → 6.0.1
PyMySQL 0.9.3 → 1.0.2
Python 3.7.
I updated pywikibot and pymysql and it worked.
I think, need to add check for the version of pymysql to pywikibot/data/mysql.py, and revert the code for support version <1.0.0. Or at least a notification that bots developers need to update pymysql.
Feb 14 2021
Dec 9 2020
By the whois, the domain was paid until 2023, maybe the hosting too. It is a pity that its admins have not responding for about a year, there is no way to fix the site or find out the situation.
Dec 8 2020
On Wikidata and https://en.wikisource.org/wiki/Help:Wikilivres written that the Wikilivres.org was closed in August 2019.
Sep 19 2020
And this page was created by bureaucrat of ruWikisource today. https://ru.wikisource.org/wiki/%D0%91%D0%A1%D0%AD1/%D0%91%D0%B5%D0%BB%D0%BE%D1%80%D1%83%D1%81%D1%81%D0%B8%D1%8F How you can see, this also have the mark "unreviewed pages" with link to a page in NS Project that which technically can't be reviewed.
Aug 16 2020
@Aklapper, yes this still wanted, But I don't understand why you write to me. Because I am not its developer, I have not even seen its code, and moreover, I have not used PHP for 5 years having switched to Python, and don't write MW-extentions.
The author abandoned support of the extension 3 years ago. This is all the information I can help.
Apr 18 2020
Enabled. Although seems that the extension don't work ... But there is no time for testing and no support, and formally this is another task.
Mar 24 2020
Mar 23 2020
Seems, it's a bug in code. How can resolve or get around this issue?
Which code show the revision requirement for this NS?
@Reedy, could you resolve this bug or disable the revision requirement for these NS?
Mar 22 2020
T226054 The problem is that FlaggedRevs is already included in MediaWiki and you need to confirm revisions on a mass of pages. But this is not possible because the confirmation button is disabled. Can to approve this message from one page, but it will appear again and again, since Mediawiki pages cannot be patrolled.
During the year there was no solution to this problem.
Also with NS MediaWiki.
I am administrator and created the MediaWiki:Encyclopedias_settings.json and MediaWiki:Wikiprojects settings.json pages, which are included in most ruWikisource pages of Main NS. Now, after edits on pages (seems, only new users' edits), appear the requirement to review these MediaWiki pages, but this imposible to do. Can to remove this message from one page, but it will appear again and again, since Mediawiki pages cannot be patrolled.
Feb 28 2020
Feb 27 2020
Feb 26 2020
Jan 15 2020
The hotfix works on broken Russian Wikisource images. https://ru.wikisource.org/wiki/%D0%A1%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0:%D0%95%D0%B2%D1%82%D0%B8%D0%B4%D0%B5%D0%BC_(%D0%9F%D0%BB%D0%B0%D1%82%D0%BE%D0%BD,_1878).pdf/57, https://ru.wikisource.org/w/index.php?title=%D0%A1%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0:%D0%A2%D0%B8%D0%BC%D0%B5%D0%B9_%D0%B8_%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%B9_(%D0%9F%D0%BB%D0%B0%D1%82%D0%BE%D0%BD,_%D0%9C%D0%B0%D0%BB%D0%B5%D0%B2%D0%B0%D0%BD%D1%81%D0%BA%D0%B8%D0%B9).pdf/308
Jan 14 2020
Nov 27 2019
As far as I understand, this extension is not active and abandoned, because the author did not saw interest of community. I don't understand why my suggestion to call interest of community to it caused your questions.
Nov 25 2019
@freephile, could you add your extention on https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2020/Wikisource?
Aug 12 2019
I removed Wikipedia from the commit, remains only Wikisources there.
Aug 11 2019
It do, I think. This problem was not until was disabled FlaggedRevs for NS "Wikisourse". And there don't using [[{{LOCALDAY}}. {{LOCALMONTHNAME}}]] [[{{LOCALYEAR}}]] {{#time}} unlike T119366.
Also, the unupdated version shows as stabilized: https://ru.wikisource.org/w/index.php?title=Заглавная_страница&stable=1. I tried to disable stabilisation for Main page, but problem still, because a transcludion can' be reviewed, as I wrote in this task.
Aug 10 2019
On the Main page of https://ru.wikisource.org for unlogged readers still showing old News. It doesn't updating. (They placed in NS "Wikisource" and can't be revieved for show.) What to do?
Jun 26 2019
This var_dump($wgFlaggedRevsNamespaces) have #6 (NS File), seems it now work (an example is above in post). Update: hm... I update page and it again shown links to not reviewed NS File: https://ru.wikisource.org/w/index.php?title=ИЭС/Раджа&oldid=3672630&diff=cur
Jun 25 2019
I reopen the task. Unfortantelly, it is not resolved.
Jun 20 2019
Jun 19 2019
Jun 18 2019
How large performance issues can will? Will it a noticeable? From that link it not clear. AFAIU, the webfonts downloads once then caching for alltime.
Jun 14 2019
Jun 5 2019
Thank you!