MediaWiki talk:Gadget-ocr.js

Competing scripts

Fyi @Helder.wiki: - they've come up with something similar to this just a day or two ago on old Wikisource...

• https://wikisource.org/wiki/MediaWiki:Hocr.js

I don't know if that new script is destined to replace this one or compliment it. -- George Orwell III (talk) 21:21, 23 August 2014 (UTC)

@George Orwell III: I'm not sure what that script does. It does not seem to have anything to interact with editor toolbars for example, so it is likely for something else. Helder 21:30, 23 August 2014 (UTC)

@Helder.wiki: Understood. I only mention it because something? [function do_hocr()] is indeed called run from this script. -- George Orwell III (talk) 21:48, 23 August 2014 (UTC)

@George Orwell III: The function do_hocr is defined on line 66 of MediaWiki:OCR.js, not on oldwikisource:MediaWiki:Hocr.js. Helder 21:53, 23 August 2014 (UTC)

OK OK OK; I'll stop pestering you about it. -- George Orwell III (talk) 21:57, 23 August 2014 (UTC)

Guys, I hope this is useful. I just happened to have kept the announcement email sent out on the wikisource-l mailing list. Regrettably I did not save Phe's follow-up message where he clarified this script is intended to be complementary to OCR.js, and most certainly not a replacement. I hope this survives a cut-and-paste:

Hi, I have setup a new OCR service on tools.wmflabs.org, it provides
through some javascript hosted on wikisource.org location data of words
for djvu/pdf Index:. It can be used by adding 

mw.loader.load('//wikisource.org/w/index.php?title=MediaWiki:Hocr.js&action=raw&ctype=text/javascript&dontcountme=s');

to your site wide MediaWiki:Common.js or to your own User Common.js, the script
works in Page: namespace, in edit or view mode. There is no user interface
except double click on a word should highlight the words on the scan. I found
it very useful for encyclopedia when it can be time consuming to retrieve the
possition of words on the image.

As the ocr and profread text are always different, the location of word is
often shifted by one or more word, location provided is only approximate.

-- Phe _______________________________________________ Wikisource-l mailing list 

If you've already seen this then appropriate… (you know.) AuFCL (talk) 22:52, 23 August 2014 (UTC)

Follow-up: Thread starts here; Phe's clarification here. AuFCL (talk) 22:58, 23 August 2014 (UTC)

OCR button no longer generated under IE11

@Helder.wiki: With the latest changes, the OCR button is no longer generated for me. Win 8.1 / IE 11. -- George Orwell III (talk) 21:57, 23 August 2014 (UTC)

please be advised, I rebuild the WikiEditor toolbar in my vector.js file. -- George Orwell III (talk) 22:08, 23 August 2014 (UTC)

@George Orwell III: it is working fine on IE11 / Windows 7. Are there any errors in the console? Helder 23:02, 23 August 2014 (UTC)

@Helder - nothing but the usual & 'JQMIGRATE: Logging is active'. No sign of the button in DOM explorer nor debugger (then again, I just went from IE8/XP to IE11/8.1 less than 10 days ago so I might not be working any of these F12 tools "properly" anymore). -- George Orwell III (talk) 23:18, 23 August 2014 (UTC)

It is working in other browsers? What if you are not logged in? Have you cleared your cache? Helder 23:31, 23 August 2014 (UTC)

I can't test any other browsers at the moment but I did clear my cache with no change.

When I'm not logged in, the button is generated however. So I tried adding the button manually to my vector.js file - the button now comes up (of course). Clicking on it however does nothing since I have no idea how to make it call the right "stuff" in a callback situation.

I wouldn't go crazy trying to figure this out - I rarely used the button & only maintain its presence to aid in troubleshooting for others when that comes up. Still, I'd like to have it behave at some point as designed regardless. -- George Orwell III (talk) 23:48, 23 August 2014 (UTC)

Obviously I came here through the other thread am not at all up to speed, but if it helps the OCR button is visible and performs a semi-reasonable action for me using Firefox 31.0 under Linux. Oh, and the only logged status is ("JQMIGRATE: Logging is active" load.php:150). AuFCL (talk) 00:50, 24 August 2014 (UTC)

@AuFCL semi-reasonable in which sense? Helder 01:01, 24 August 2014 (UTC)

Many pardons for slow response (got distracted elesewhere); I meant "as far as I can tell the OCR button performed its function as best I expected it to do." (On a sample size of exactly one.) Looks like the whole issue has become moot in any case per G.O._III's revelations below. AuFCL (talk) 02:10, 24 August 2014 (UTC)

Still have the same results post my-change-linked-below? -- George Orwell III (talk) 02:15, 24 August 2014 (UTC)

All still good on F/F as at about four minutes ago. AuFCL (talk) 02:38, 24 August 2014 (UTC)

Helder -- George Orwell III (talk) 01:39, 24 August 2014 (UTC)

NEW; See this edit to the MediaWiki:OCR.js file. Viola! OCR button generation is restored and working. Now what? As you can see from the edit history that followed that diff, I had no luck mirroring your changes in a similar situation on Wikipedia.

Please note: I always disable the "show edit toolbar" option in my User prefs to insure the old toolbar is separate from the enhanced toolbar in preparation for the day the "betatoolbar" (e.g. WikiEditor) becomes the new standard and default toolbar. — George Orwell III (talk) 02:03, 24 August 2014 (UTC)

@George Orwell III: the option "⧼tog-showtoolbar⧽" is supposed to disable every edit toolbar (classical and enhanced), so your change actually unfix my fix for that on page namespace. In order to use the enhanced toolbar you should enable both preferences. See e.g. w:Wikipedia:Village pump (technical)/Archive 125#Cite menu on toolbar missing! and en:Wikipedia:RefToolbar#Versions. Helder 02:34, 24 August 2014 (UTC)

Er... Bug 30795 - "Show edit toolbar" preference is confusing. Helder 02:45, 24 August 2014 (UTC)

Sorry, if that was true I shouldn't have any toolbar at all - regardless of what is my vector.js or not - and that is just not the case. If that is really is the case, the User pref to enable the enhanced toolbar should not be manually selectable until "show edit toolbar" is enabled first. The same should be true of enhanced dialogs - the enabling the enhanced toolbar should be a required before dialogs becomes selectable; that is not the case either (they just won't work in that case is all). Right now, the choices are pretty much independent of each other and that makes my settings - as invalid as you may think they are - a valid set of choices simply because it is possible to have that combination selected. Therefore, IMHO, you should make it 'showtoolbar' || 'usebetatoolbar' (or something similar) or equivalent to that instead. The fact that its been debated since 2011-2012 only reinforces the reality of the situation at hand.

All that nonsense aside, let's get back to why are we common.js loading a button that only works in a single namespace to begin with in addition to the fact that not all users want it activated even in those instances. Personally I think OCR should be part of the Proofread tools menu and "based" in the extension itself but I'd be happy if we can stop loading it until at least the page namespace is detected or in-play. Better still, have it load only in edit mode and execute only if clicked. -- George Orwell III (talk) 03:00, 24 August 2014 (UTC)

@George Orwell III: I was wrong. At some point in the last few months I forgot what was the default behavior of the four combinations of the two preferences related to editing toolbars . Now that I looked into this again, and tested in a clean installation of MediaWiki + WikiEditor (without any JS code interfering with the default behavior), I see that in order to add the OCR button exactly in the same circumstances that there is a toolbar, and to use load the correct module every time (and not load modules unnecessarily), this is what need to be done:

1. "Enable the editing toolbar" + "⧼tog-showtoolbar⧽": The enhanced toolbar is shown, so we should load the module "ext.wikiEditor.toolbar" and use it to add the OCR buton
2. "Enable the editing toolbar": Same as above.
   • This is the case I implemented the tests incorrectly (in a few other scripts too, I think - I'll check/fix them soon).
3. "⧼tog-showtoolbar⧽": The classic toolbar is shown, so we should load the module "mediawiki.action.edit" and use it to add the OCR buton
4. Both disabled: No toolbar is shown, so we should not load any module, and not try to add any button

If in the default behavior of these preferences change in the future, then we can update the logic in the scripts to match the new behavior. Helder 18:48, 24 August 2014 (UTC)

@George Orwell III: This change should make it behave as described above. Could you double-check that the new version works as intended? Helder 19:35, 24 August 2014 (UTC)

@Helder, all works as before - still have OCR button generated in Page: namespace. Thank you!!

Still feel this approach of loading the OCR.js file thru Common.js is not optimal however and eventually we'll need a better solution (especially since a good number of folks can't utilize it [old browsers] or plain old just don't want it to begin with). -- George Orwell III (talk) 20:53, 24 August 2014 (UTC)

@George Orwell III: Thanks for checking! BTW: after talking with Tpt and Phe on IRC, I moved the OCR button to the "Proofread tools" submenu, in the oldwikisource version. Helder 21:15, 24 August 2014 (UTC)

@Helder, I think you should do that here as well. The "space savings" on the face of the toolbar could cut down on the amount of opt-outs. -- George Orwell III (talk) 23:15, 24 August 2014 (UTC)

Original command to disable script once loaded

self.proofreadpage_disable_ocr = true;