May 25 2022
I found the issue that caused this problem and wanted to bring it to your attention. The main namespace display style control also appears in the user's namespace. https://en.wikisource.org/wiki/File:User_ineuw_sandbox1.jpg.
May 22 2022
One of the things we discussed but wasn't implemented was the ability to remember zoom and pan position across pages. Implementing scroll and pan remembering across pages would effectively nullify any of the current issues wrt to scrolling to specific areas of pages since you should be able to pan the page once per every Index: page and then not have to adjust pages until you encountered (say) a text page.
I believe that you are under a misconception. Remembering zoom position and size between pages is irrelevant. Editing is better served by the current default reset of each new page opened for editing. Default magnification and the top of the page where editing always begins. Magnification is great for a closeup look, scrolling is far easier than sliding a djvu image 4 - 5 times to get to the text below an image (even when the djvu is minimized). There is no vertical real-estate to speed this up. Doing this thousands of times ends with me complaining here.
Thanks for the reply, it's much appreciated. So far the problem is corrected FF v100+, as you mentioned. Posting here was my last resort, because this offset became an issue with an earlier version using the Linux Mint Edition of Firefox. https://github.com/linuxmint/cinnamon/issues/10776.
May 14 2022
You are assuming and pontificating. I happen to look at the sandbox9 occasionally if it is still aligned, but I closed it before purging the djvu page. Then, I reopened it on a hunch. If you would have taken the trouble to check the other closed sandboxes, you may have noticed that all of them are off. Shall I send you more photos?
May 13 2022
May 12 2022
This issue is best solved by the use of Autokey in Linux and Autohotkey in Windows 10, and not by adding application based shortcuts. This allows any user to assign whatever they want and need. Sometimes, when I edit in French Wikisource, I simply use another keyboard definition definition file. Using the same key combinations but the scripts which are activated by user assigned key, in French.
May 11 2022
@Soda, The new system is very good for text only pages, BUT, I can give you a 1,000 examples I am working on currently. Please attempt and edit a page with images and text. https://en.wikisource.org/wiki/Page:Africa_by_%C3%89lis%C3%A9e_Reclus,_Volume_3.djvu/590. Images are surrounded by text and navigating around an image without scrolling doubles my time of proofreading a page. This may sound crazy but I see results in my recent contributions on WS.
Mar 20 2022
Is there a chance for the image scrolling to be restored?
Jan 10 2022
The image scroll feature doesn't exist. Is there a plan to revive it?
Dec 13 2021
"It doesn't need to exist to edit the page. A red link always takes you directly to the edit form. All you have to do is click on it."
Dec 12 2021
Are you referring to this link on the patch demo? because it's no longer exists for testing [[Page:Shen_of_the_Sea.pdf/45]]
Dec 11 2021
@Inductiveload, I apologize for the delayed reply. I get no emails from this site, even though it's properly configured.
Dec 6 2021
Thanks for the reply. As far as I understand the information in 'patchdemo' is that the order of mouse scroll behaviour would be:
Dec 5 2021
@Inductiveload, I am not blind to the shortage of developers, but from my viewpoint, I am also aware that Wikipedia offers an excellent opportunity for honing and refining programming skills.
Dec 1 2021
@Inductiveload, none of the above suggestions scroll the content. Were there any problems with the previous arrangement? If not, these changes may entertain and occupy the developers, but don't nothing to help editors. Please don't break something that works. Can I disable the magnifier on the pages I want to work and get back scrolling until this is sorted out and functioning?
Of course not. I am heading there. . . . and thanks
Nov 30 2021
I understand the position you're in, but there has to be a better way to test software. Is there a way for me to block magnification in my vector.js, and restore to just scrolling until the problem resolves itself?
Nov 19 2021
Please keep away from two handed actions (mouse + keyboard) whenever possible.
Nov 9 2020
Jul 12 2020
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.