Sat, Jul 27
OCR failure is not universal. For details, please see this post in English Wikisource:
Is it possible for me to see the stages of work on this problem? I ask because it's working again, but don't know if the fix is permanent.
Thu, Jul 25
Used it on English Wikisource at 04:53, 25 July 2019 (UTC) and it worked. But, now it's dead again. What was done at the indicated date and time to make it work?
Tue, Jul 23
I should have mentioned that I only use the source editor.
Sun, Jul 21
Jun 27 2019
Jun 26 2019
It was resolved within a few minutes. If I can't close, then please close it. ty.
It also affects the rendering of the GUI. With each scroll down the page, the "Save" button appears on the middle of the page/display.
Jun 1 2019
@Phe, The same request as Jan.Kamenicek's above. Is it possible to implement the OCR locally?
Mar 27 2019
I tested it when logged out and everything worked, so I looked in both the common.js and common.css. There were copied css settings from another editor, one of which had a max-height setting for the main textarea dimensions. After removing it, everything is as it should be.
Mar 25 2019
Please close this report. It is repaired.
@Aklapper. It works when logged out AND the header/footer rows are 3 lines!!! So, deleted all my Wikipedia related cookies, logged back in and the problem returned. Will remove my common.js & common.css and see what happens. If it's still not working, the problem might be my preferences \edit or the \gadgets.
Mar 24 2019
Using Firefox 66.01 in Windows 10, and Firefox 66.0 in Linux Mint 19.1, as well, the latest Vivaldi-snapshot in both Windows and Linux. The problem is the same in both browsers. Also uploaded this image at Wikisource with explanation. https://en.wikisource.org/wiki/File:T219048.jpg
Mar 23 2019
Mar 11 2019
I also received two automated emails, the numbers are different but I am sure that they are related to this bug.
Jan 11 2019
Everything is fine. Thank you. Please close this report.
The bug is corrected and the ruler displays correctly in the footer. Thanks to all.
Jan 8 2019
Thanks to both of you. I saw the <hr> auto issue, and I have no problem waiting for the "visibility" issue to be resolved however long it takes.
Jan 7 2019
Jan 6 2019
AKlapper, thanks for your instructions. Will do so with future bug reports.
@Aklapper, I must have used a simple bug report form because the fields indicated in the tutorial did not exist.
Jan 5 2019
Nov 4 2018
Aug 24 2018
@Aklapper, this issue occurs on the French Wikisource as well, which means that it occurs on every site that uses the Proofread extension. Now that I work in a language and a website that is less familiar, it requires previewing the work more often that before and thus the number of appended empty lines increases.
Apr 6 2018
@Klapper, Thanks. I don't need and expect instant resolution. I was just curious about the process. For me the inner sanctum of Wikimedia's technical process is a complete mystery. It's sort of a netherworld. :-)
Mar 30 2018
@Aklapper, Just asking what is the status of this issue? Thanks
Mar 16 2018
This is the editor I am using https://www.mediawiki.org/wiki/Extension:WikiEditor
Mar 6 2018
@Aklapper, I am using the "Extension WikiEditor" 2010, Desktop, "This can be seen when "Enable enhanced editing toolbar" is enabled in Special:Preferences. as mentioned in my previous comment."
Mar 5 2018
@Tpt, I am using the Editor which has the Advanced, Special characters, Help, and Proofread tools, dropdown lists on the top bar. In Preferences/Edit the [Enable enhanced editing toolbar] is checked off.
@Billinghurst, I checked both the main and the author namespaces. No additional lines created when using Preview.
Mar 4 2018
Oct 27 2017
Thanks again for following it up. Now the question remains if it is doable within the Alt-Shift key assignments scheme. The timetable of implementation is less important.
Oct 26 2017
Sep 1 2017
P.S. I am only referring to the desktop.
As an ignorant, I would think that hiding or disabling the radio button would be simple.
I write this to help those who were stuck in Minerva in the Page namespace, where access to the user Preferences is not available. I had a bookmark to the Contributions page where the Minerva user preferences menu worked and thus I was able to switch back to Vector default.
Aug 30 2017
Aug 22 2017
After reading the conversation of T173598, I recommend that the Minerva skin name should include identification of sorts to know whether the conversations are about the desktop 'D' or the mobile 'M' version. After all, the issues are different.
Desktop, Special pages | Version | Installed skins lists Minerva as "A responsive mobile first skin." When I looked for this on my mobile, Minerva is not listed as one of the available skins.
May 5 2017
In that case please close this ticket.
As requested by billinghurst, I disabled all gadgets and scripts in my userspace. Also, removed the contents of common.css, but I still get the following
May 4 2017
This was not a gadget problem. I'm still testing my work environment and will post the results here tomorrow.
Don't think its the gadgets because I cleared all gadget settings, cleared the common.js and common.css code and the page load began to function normally. Then began rebuilding my work environment with the gadgets and re-selected my preferences and this did not affect page load speed which remained normal good. I am now restoring snippets of code to locate the cause of the problem.
These are the three warnings in the console when I tried to edit some pages without scripts of common.js and without gadgets.
Apr 20 2017
**MarkTraceur & Zppix, That's exactly what I could use if possible. When I prepare files for upload, I have ready all the necessary info required by the Wizard, except the new (book) category. Having the ability to define a non-existing category before the upload would save several steps afterwards. I realize that a new category also requires a relation to another category, so this must also be specified when creating. Below is a list from which I work. Some categories exist because I created them after the upload.
Apr 19 2017
Oct 31 2016
Please close this ticket. With purging of the caches the images are displayed properly.
Oct 30 2016
Also need some clarification on the bewildering variety of cache clearing options, which does what?:
- There is an option middle of the buttons, on the top right of Index pages: https://en.wikisource.org/wiki/Index:Popular_Science_Monthly_Volume_55.djvu. I assume this purges the Commons djvu repository, but I am not sure.
- Gadget: A "*" tab or a "Purge" option within the actions-tab, which purges the page's cache when followed. This adds a purge and a Hard purge control, whatever that means.
- Gadget: Clock and Purge. A clock in the personal toolbar that shows the current time in UTC and be clicked to purge the page.
- Clear one's browser cache.
Just looked at the page and it is OK. But, I disabled my gadgets yesterday. Please keep the ticket open for 24 hours, and let me see if it still be OK as I continue working, with and without the gadgets.
loading in edit mode, the console of web developer generates the following code in Chrome
Oct 29 2016
loading in edit mode the web developer generates the following in Firefox:
Oct 6 2016
I repaired the problem by deleting all the cookies and logins. Please close this ticket.
@Aklapper: This is the page of the above indicated image: https://en.wikisource.org/w/index.php?title=Page:Popular_Science_Monthly_Volume_54.djvu/668&action=edit
I set preferences edit from 4 (minimum) and to 23 rows up and it does not alter the window size at all. The main textarea height is frozen at 275 pixels. I use Firefox for production but also Chrome/Chromium to check and compare. In this case both browsers are frozen.
Oct 5 2016
Jul 12 2016
Mea culpa. It was not done with malice. But, there should be a mechanism
for IT staff to see a user's settings. I would like to know why it isn't
so? Also, if this feature is so important, why allow a user to turn it off
or on? Furthermore, as far as I understand it, this feature is unique to
Jul 11 2016
@MZMcBride. The password given was a temporary password for 15 minutes or so, and is no longer valid. But since you brought it up, I suggest that Mediawiki programmers/technicians should have access to our editing options and gadget settings for test purposes.
Thanks Danny_B. You are right. It was not checked before I removed all the gadgets, as I kept an screenshot of my gadget selection. Now everything works.
Same issue and solution as https://phabricator.wikimedia.org/T139908. It works now.
I suspect that the problem may be with my global login. I have ~95 wikisites attached to my global login. Suggest that I change my password, email it to you to be used for a predetermined time (15 minutes?). Login with my username and see if it's reproducible.
Danny, no offense intended, but I am not User:He7d3r. And, please read the bug report. I have no global, or any user .js or .css and NEVER had Global settings!!! Purged my cache more often than the Spanish inquisition burned the Aztecs and the Jews. . . . and why is this a low priority? I am willing to bet that someone else will notice the problem sooner or later in other Wikisource projects, just as my last bug reported, popped up in other Wikisource projects.
Jul 1 2016
Thanks for forcing me to learn/use the developer's tools. I hope the info was helpful. For me it's a 1000% improvement over my ignorance from when I posted the first bug report. The question is, were the identical issues at the German Wikisource, which resolved their issues?
Let's be clear. My yesterday's comment, reflected the state of the editor then. Now, it seems OK. It must have been patched between now @ 21:10 UTC and 2016-06-30 6:00 UTC.
@Krinkle Here is the requested info, in the order you asked
Jun 30 2016
Nothing changed on english Wikisource, the same problems existed as of 2016-06-30 6:00 UTC.
Jun 29 2016
Was this issue investigated? Is there any additional info missing, which would help to have this issue resolved?
Jun 26 2016
Is there any way to merge this with [Maniphest] T138554? it's about the same issue.
Unchecked all gadgets, cleared my common.js and common.css, but to no avail. The problem is the same. The text layout switches from horizontal on the bottom view, to side by side, and loosing the enhanced editing bar. I always use the vector skin, but also tried with the monobook skin but the problem is the same.
Jun 25 2016
Just to comment to AKlapper and Tpt: I don't know in which time zone/country you both reside, but I need some sleep on occasion. Before this bug report, I didn't know that you wanted the output of Firefox's web web console. This is the contents of the web console when I click to preview the edit changes THE FIRST TIME! on this page:https://en.wikisource.org/w/index.php?title=Page:Popular_Science_Monthly_Volume_48.djvu/869&action=edit
This bug report was changed and some of my comments and the participants were removed.
Also forgot to repeat that there is no problem in Chrome. Only in Firefox. Please read my posts.
Image of one of the changes: https://en.wikisource.org/wiki/File:Change_of_edit_layout.jpg
22nd of June correlates the day when the problems began. Just curious, what made you mention this date as opposed to the 21?
Jun 24 2016
Regarding the error posted at https://en.wikisource.org/wiki/Wikisource:Scriptorium/Help#Strange_happenings_when_using_.27Show_preview.27,
May 31 2016
The very reason it was posted here first, was because there wasn't anyone available at enWS at the moment to fix it. I have difficulty to believe that such minor issue created such a major storm. After all, I was convinced that Mediawiki staff of programmers were here to help.
May 30 2016
any link is a good example [https://en.wikisource.org/wiki/Popular_Science_Monthly/Volume_1/May_1872/The_Study_of_Sociology_I]
May 5 2016
matmarex, thanks for the link, I already corrected it. The category problem seemed to be related to HotCat and the two fixed (built in) categories of
Apr 22 2016
Will I be able to substitute this with something that sets the page width in the Page: namespace of Wikisource? This happens to be an important component in my proofreading. my css: https://en.wikisource.org/wiki/User:Ineuw/common.css
Mar 28 2016
Mea culpa. I abandoned that link because cannot access it without the (expired) tokens. This is my mistake for not not noticing the tokens in the link. Please consider this issue resolved.
Mar 25 2016
Just tried Internet Archive link, and the authorization works.
Mar 20 2016
My apologies for the lack of detailed info, which I will provide below including the links and how to reproduce.
The same OAuth authorization screen shows up on Wikipedia, Commons, Wikisource and Internet Archive.
Mar 19 2016
Just tried it from Wikipedia and Wikisource and it works. If there is a problem again, I will post it here with URL etc.
Mar 13 2016
Wikipedia to transfer tagged (copyright qualified) images to the Commons
Wikisource to transfer copyright qualified images to the Commons