Sun, Jul 12
I apologize for this late reply because I am not in the habit of ignoring posts addressed to me. The character-insert is accessible at all times. My only issue is that it doesn't stay on top (above the edit window), as how I set it in my vector.js.
May 9 2020
May 8 2020
The Global preferences were not set up correctly, and the setting didn't cascade to the local preference. The second checkbox was unchecked, the purpose of which I don't understand. Why some of the the Global references have a pair of checkboxes. I searched Mediawiki for an explanation but found nothing. In my case, the left checkbox was selected and the right wasn't. This is indicated in the attached image.
Apr 29 2020
Disabled Global preferences and the preview is working properly.
Apr 28 2020
@Aklapper If I am correct, perhaps the title of this ticket should be changed to something like "Link between Global preferences and Local preferences is broken"?
IneuwPublic has no global account on Wikimedia and the User Preferences Preview display is selected, which works.
You and I have taken exactly the same steps, in the same sequence and as you can see in the attached photo. The photos were taken hours ago and doublchecked them now. I noticed that the global preview is checked and the user preview is blank.
Apr 27 2020
I assume that it has to do with "global" because I am always logged in automatically on every visited wiki website and the same problem persists.
Apr 26 2020
The Preference options in my second account IneuwPublic differ from the Ineuw account in that there are no global account settings.
Apr 21 2020
@Aklapper "Enabling "Horizontal layout when editing in the Page: namespace" on https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-editing :)"
Apr 16 2020
Just started using it in English Wikisource and its working.
Apr 15 2020
@Aklapper Please clarify what is missing in the description? I know that it happens in FF 75.0 which I am using now, but I started the problem data collection when FF was version 74.
Inserted image in description, of the page layout with the issue.
Apr 14 2020
There are other issues following the above steps, but it's possible that if this is corrected, the other issues may be corrected.
Apr 13 2020
I have all the information on the steps to take to replicate the problem, but there are at least one other problem discovered while using the same steps. I would like to create a new bug report for one issue and have this bug report re-titled or annulled please.
Mar 25 2020
@Aklapper, thanks for the reply and the info.
Mar 15 2020
After experimenting, the font size returns to the user defined size when the page is refreshed, but this process must be repeated for every page.
Dec 29 2019
The problem is the syntax highlighter. After disabling it, the layout corrected itself.
Sep 27 2019
Neither Phe's OCR in my user space nor the Gadget OCR work on some volumes. You can test this:
Sep 4 2019
What is the current state of this task?? None of the substitutes (like Google OCR) come near in quality of character recognition.
Jul 27 2019
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.
Jul 25 2019
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?
Jul 23 2019
I should have mentioned that I only use the source editor.
Jul 21 2019
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: