Last modified: 2013-09-21 11:56:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T56309, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 54309 - Character selection moved too low in new mw software version
Character selection moved too low in new mw software version
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Unprioritized major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-19 08:26 UTC by ineuw
Modified: 2013-09-21 11:56 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Character selection moved too low in new mw software version (144.09 KB, image/jpeg)
2013-09-19 08:26 UTC, ineuw
Details
Screen shot of language character selection below the edit area (96.78 KB, image/jpeg)
2013-09-20 16:24 UTC, ineuw
Details

Description ineuw 2013-09-19 08:26:16 UTC
Created attachment 13322 [details]
Character selection moved too low in new mw software version

The character set selection at the bottom of the Page namespace in edit mode was moved so far below the edit window that it's impossible to see the original text to be reproduced. This was not so in the previous mw software version.

Please see the attached image and Bugzilla #54308
Comment 1 Sam Reed (reedy) 2013-09-19 08:30:11 UTC
Which version are you currently using? Which previous version?
Comment 2 ineuw 2013-09-19 09:34:16 UTC
I tried both versions for extended periods of time. Both with or without image buttons, currently I am using the latest iteration with captioned parameters, having removed the older version a few hours ago since it made no difference. Please see the history of my common.js.

If you notice, the custom edit toolbar should be AFTER the two standard toolbars. Instead it is inserted between the two. A phenomena which began some months ago.

There are numerous and extensive Wikisource posts over the past years regarding the toolbar problem.
Comment 3 Andre Klapper 2013-09-19 10:52:33 UTC
(In reply to comment #2)
> If you notice, the custom edit toolbar should be AFTER the two standard
> toolbars. Instead it is inserted between the two.

Where on the image that you attached in this report can a custom edit toolbar be seen? I get exactly the same image (without your custom.css/.js file copied).

And comment 0 refered to character set selection, not to some custom edit toolbar? How is this related?

I'd love to know where exactly the character set selection was before it "so far below"...
Comment 4 ineuw 2013-09-19 11:35:20 UTC
Something in the space below the TEXTAREA was increased. Perhaps it was done by someone at Wikisource, I have no idea. The attached screenshot is made in full screen mode. (F11), and I still can't access the original text.
Comment 5 ineuw 2013-09-20 12:52:34 UTC
Andre, If I posted the wrong image to the wrong bug report, I apologize.

After re-reading your comment above, the character selector below "wpTextbox1" would have been an alternate means of inserting Greek, Hebrew, or Arabic characters. That is how the issue is related. Previous to version 1.21, I was able to see both the selected character set, the "wpTextbox1", as well as the bottom line of the scanned text to assemble the foreign text. Unfortunately, I no longer have access to the older software to prove my point, which I could have measured with a pixel ruler and compare. My point is simply being that these changes prevent me from editing. Please compare my previous and current rate of editing.
Comment 6 Andre Klapper 2013-09-20 14:23:26 UTC
(In reply to comment #5)
> After re-reading your comment above, the character selector below
> "wpTextbox1"
> would have been an alternate means of inserting Greek, Hebrew, or Arabic
> characters. That is how the issue is related. Previous to version 1.21

1.21 was deployed in October 2012. Also see https://en.wikisource.org/w/index.php?title=Special:Version

I'm still lost here. Do you mean that the "specialchars" div was above the "mw-edittools-section" div?
Comment 7 ineuw 2013-09-20 16:24:33 UTC
As far as the exact version number, the changes occurred towards the end of August 2013. Perhaps there was a minor change in August? 

As for the language character selector: Please look at this attached image. 

"Character selection way too low to see original text 2.jpg"

Taken of this page: 

https://en.wikisource.org/w/index.php?title=Page:Palestine_Exploration_Fund_-_Quarterly_Statement_for_1894.djvu/81&action=edit

The special character selection was forced lower because the <div>EditOptions and div.editTools-text padding/margins must have been increased.
Comment 8 ineuw 2013-09-20 16:24:42 UTC
Created attachment 13333 [details]
Screen shot of language character selection below the edit area
Comment 9 ineuw 2013-09-21 04:04:02 UTC
Found the version change and the date of this bug issue. It appeared after the implementation of mw:MediaWiki 1.22/wmf13, on or about August 17, 2013.
Comment 10 Michael M. 2013-09-21 07:20:20 UTC
Sorry for moving again, the special characters *are* managed by that extension, but their position is determined in core (showEditTools() in EditPage.php) nevertheless.

IMHO the edit tools should just be swapped with showTosSummary(), but I'm not going to start a bikeshed about THE right position of the edit tools.
Comment 11 ineuw 2013-09-21 11:56:23 UTC
Michael M. It is by pure chance, while following a link in an unrelated quest, that I discovered what EditTools is and where it originates in Wikisource.

https://en.wikisource.org/wiki/MediaWiki:Edittools

Thanks for the enlightenment and knowledge liberates. I don't wish you, or anyone else to move it etc. This is another issue that should be considered closed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links