> That's a very good idea.
NO! NO! NO!
It is suggesting new users to behave like bots! Just click and go on?
Why to read the small-lettering texts? Just click the GGB (Great Green
Button).
In Polish language Wikisource we have VERY BAD experience with directing
new users to the final validation process: they can't carefully compare
the text in both windows word-by-word. They just read both texts (and
maybe one only?) and click validate & next.
Later we found a lot of unnoticed OCR-related mistakes like:
- missing last paragraph
- missing a line
- typos like m->rn, in->m, ę->ą, o->n, etc.
Even 5-10 mistakes per a GREEN page (whan it was based on poor scans/poor
OCR). In our opinion people need to LEARN how to compare texts. And it is
easier to learn when there are more mistakes to notice when there is only
a few of them.
If you want to decrease quality or you believe you have perfect OCR
software, plese do it for specified Wikisource subdomains, not as general
tool.
plwikisource highly discourage such a tool.
Ankry
> A big green button "validate" at the end of the displayed wikitext content
> of the page may fit the need. It would open a confirmation popup with an
> explanation message the first k times the user click on it in order to
> make sure new contributors use it well (with k something like 3 or 5).
>
> What do you think about it? I'll have some free time in a few weeks to
> implement a such thing directly into the ProofreadPage extension.
>
> Thomas
>
>
>> Le 10 ao?t 2015 ? 14:31, Alex Brollo <alex.brollo(a)gmail.com> a écrit :
>>
>> Ok; imagine that while opening a level 3 page, an ajax query uploads
>> quietly the raw code of the page; as soon as you click the "Big Green
>> Button" the script could edit the code and send it to the server - in
>> milliseconds - and immediately could click the next page button.
>>
>> If a review of page in view mode is all what is needed to validate it,
>> there's no reason to enter in edit mode when there's nothing to fix.
>>
>> Alex
>>
>> 2015-08-10 18:14 GMT+02:00 Andrea Zanni <zanni.andrea84(a)gmail.com>:
>> The Big Validate Button is a good idea,
>> but I also would like a better navigation experience, as it is pretty
>> slow and cumbersome to got on the top of the page to click a tiny arrow,
>> wait for the new page, click edit, etc.
>>
>> Aubrey
>>
>>
>> On Mon, Aug 10, 2015 at 4:29 PM, Alex Brollo <alex.brollo(a)gmail.com>
>> wrote:
>> If this is true, then to add a big button "Validate" to edit by ajax the
>> code of the page (the header section only needs to be changed if there's
>> no error to fix into the txt) should be a banal task for a good
>> programmer.
>>
>> Perhaps Andrea is asking for much more, but this could be a first step.
>>
>> Alex
>>
>>
>>
>> 2015-08-10 14:47 GMT+01:00 Nicolas VIGNERON
>> <vigneron.nicolas(a)gmail.com>:
>> 2015-08-10 15:37 GMT+02:00 Alex Brollo <alex.brollo(a)gmail.com>:
>> >
>> > First point is:
>> > is it a safe practice to validate a page without reviewing its raw
>> code?
>>
>> Probably yes.
>> Obviously, it's safer to check the raw code but it's unrealistic to
>> expect the raw code to be review for all page. Anyway, the pages doesn't
>> contain a lot of code (and most pages does'nt contain code at all), so
>> it doesn't seems to be crucial to me.
>> Plus : when VisualEditor will be on WS, less and less people will
>> actually see the raw wikicode.
>>
>> > A second point: is it a safe practice to validate a page without
>> carefully reviewing its transclusion into ns0?
>>
>> Definitively yes.
>> When can a transclusion can go wrong? In all cases I can think of, the
>> problem come from templates, css classes or general stuff like that. It
>> should be fixed generally and it shouldn't block the page validation
>> since it have nothing to do the the page itself (but maybe I'm missing
>> an obvious example here).
>>
>> > Alex
>>
>> Cdlt, ~nicolas
>>
>> _______________________________________________
>> Wikisource-l mailing list
>> Wikisource-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
It is clear from this discussion that we have very different practices in the various language subdomains. My experience is that oftentimes on the English Wikisource you just have to mark paragraph breaks and remove line breaks and extra spaces around punctuation marks, and you can already save the page as "Proofread". More often than not the validator will have nothing to correct, since the OCR was already perfect, which is unsurprising given that OCR software (or any software, for that matter) is generally designed for the English language, with little regard to languages that use additional letters or diacritics (not to talk about writing systems other than the Latin alphabet).
On the Italian Wikisource the blue button means "Completely transcribed but not formatted" (not "Problematic"), while the yellow button means "Completely transcribed and formatted". So in theory an inexperienced user could choose to just transcribe a page and let it be formatted by someone else. In practice this rarely happens and the workflow for most pages is similar to the English Wikisource's usual practice, although Italian-language texts, especially medieval or Renaissance ones, tend to have more OCR errors.
It looks like on the Polish Wikisource they use the red (or blue?) button, not the yellow one, upon creation, while still proofreading the text of the page. So they end up doing three proofreadings overall, which has the obvious benefit of higher accuracy, especially since they seem to have bad OCR support, with the added difficulty that some of the words with typos happen to be real words and therefore not spotted by spellcheckers.
It would be nice to know if other Wikisources take even different approaches. And maybe we could make an attempt to unify them? Taking everyone's issues and concerns into account, that is.
Regarding the initial topic of this thread: Pressing the edit button, checking for errors, marking the page as validated, saving, and going on to the page was not a problem for me as a beginner (though since the font in text boxes is not very pleasant to the eye, I would begin checking for errors in view mode and enter the edit mode only upon spotting the first error). Rather, it allowed me to learn the markup little by little (like paragraph breaks, the use of <poem> for lines of verse, or the purpose of colons at the beginning of a line).
Erasmo Barresi
> Date: Wed, 12 Aug 2015 11:11:00 +0200
> From: Andrea Zanni <zanni.andrea84(a)gmail.com>
> To: "discussion list for Wikisource, the free library"
> <wikisource-l(a)lists.wikimedia.org>
> Subject: Re: [Wikisource-l] Better way to validate pages
> Message-ID:
> <CAC=VxyaZfHuxZNZFjYCKfA0+1D4EkCPyRKZf5cm1EbS_T+hmzw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I read a lot of misunderstanding here,
> probably due to the fact that none of us are native speaker.
>
> @Wiera Lee: please, please, please, don't shout.
> This is a civil discussion. What Alex did is just a button that you double
> click and you go directly in the Edit mode. Nothing more, and only I have
> it. It's *definitely not a final decision of any kind*.
> So the message you sent earlier is simply not true. So we can restart a
> nice conversation :-D
>
> @Lugusto thanks for sharing your experience.
> I probably said the wrong "color", in this discussion: green.
>
> That is not necesseraly what I really want (of course I thought about
> validation at the beginning of the thread).
> What I really really want is
> * a simpler life for our readers
> * a way to harness/tap/exploit the simple fact that a lot of users DO read
> our books, but never correct anything.
>
> What I really want is a very very quick way, for a user, to correct a typo
> WHEN she sees it.
>
> Maybe we could do a BIG YELLOW BUTTON (meaning 75%), or maybe we can simply
> find *another* way for a user to signal the simple fact that we correct a
> typo or similar.
> My fear is that Wikisource is way to complicated, and a lot of people read
> our texts, and they could help us but we are too complicated to let them.
> Can we try to solve this?
>
> Aubrey
>
>
>
> On Wed, Aug 12, 2015 at 8:58 AM, Nicolas VIGNERON <
> vigneron.nicolas(a)gmail.com> wrote:
>
> > 2015-08-12 7:00 GMT+02:00 Alex Brollo <alex.brollo(a)gmail.com>:
> >
> >> Please don't presume that such a controversial tool hase been implemented
> >> anywhere ..... "running" only means that che code can run; presently only
> >> *one* user (Aubrey) can click it, just to test it.
> >>
> >> Alex
> >>
> >
> > I asked on the frws scriptorium, if the community wants to test it on frws
> > (
> > https://fr.wikisource.org/wiki/Wikisource:Scriptorium/Ao%C3%BBt_2015#Big_gr…
> > ). I'll ask on brws too (but I'll be away).
> >
> > *You* (dear reader on this mail) can ask *your* community if *you* want
> > this tool or not and how. Nothing has been decided and certainly not in
> > your place.
> >
> > @Luiz : there is some very good ideas in your mail. If the code works for
> > green, surely it could be adapt easily for yellow.
> > You have a contention on orthographyon ptws? Can you provide the links?
> > (I'd like to know more as the only convention on frws is to do as the text
> > does)
> >
> > Cdlt, ~nicolas
> >
> > _______________________________________________
> > Wikisource-l mailing list
> > Wikisource-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikisource-l
> >
> >
If you wish to add the "Big Validate Button" in a specific Wikisource, it
is your choice. But the Polish language Wikisource will definitely refuse
to use such a tool. So it should never become a general tool.
We have VERY BAD experience with new users making the final validation
process. Noticing an OCR error omited in previous stages is often a
problem for a user unexperienced in work with OCR-based texts. In general,
they just read both texts, do not compare them word-by-word so they often
cannot notice mistakes like: missing paragraph, missing line of text,
wrong word and also aften miss a typo (eg. missing letter).
Our OCR tetxs are full of OCR-specific "typos", like
m instead of in
rn instead of m
1 instead of l
l instead of 1
l instead of ł
ą instead of ę
i instead of !
, instead of .
. instead of ,
wrong capitalization
missing or extra diacritic marks
In most cases such "typos" are impossible to eliminate using
dictionary-based tests as both "words" (OCR-created and the correct one)
exist in the OCR dictionary.
Another disadvantage of directing new users to the validation process
(especially without even viewing the code) is that they might NEVER learn
how to format texts (or even fix broken formatting) as they might never
need to use it!
It does not matter whether it is low-level template-based formatting
process or using VE (however, it is likely that wrong formatting enetered
using VE might be difficult to fix while also using VE).
In plwikisource we prefer to direct new users to start work with simple
texts, when little formatting is required (eg. short stories, novels,
simple poetry) entering them (basing on pre-formatted OCR) or to do the
first Proofread stage (red -> yellow) than direct them to final
validation.
Maybe OCR in other languages is much better or you do not care for final
text quality - but it definitely should be a choice.
Ankry
> Date: Mon, 10 Aug 2015 18:14:20 +0200
> Andrea Zanni wrote:
>
> The Big Validate Button is a good idea,
> but I also would like a better navigation experience, as it is pretty slow
> and cumbersome to got on the top of the page to click a tiny arrow, wait
> for the new page, click edit, etc.
>
> Aubrey
>
>
> On Mon, Aug 10, 2015 at 4:29 PM, Alex Brollo <alex.brollo(a)gmail.com>
> wrote:
>
>> If this is true, then to add a big button "Validate" to edit by ajax the
>> code of the page (the header section only needs to be changed if there's
>> no
>> error to fix into the txt) should be a banal task for a good programmer.
>>
>> Perhaps Andrea is asking for much more, but this could be a first step.
>>
>> Alex
>>
>>
>>
>> 2015-08-10 14:47 GMT+01:00 Nicolas VIGNERON
>> <vigneron.nicolas(a)gmail.com>:
>>
>>> 2015-08-10 15:37 GMT+02:00 Alex Brollo <alex.brollo(a)gmail.com>:
>>> >
>>> > First point is:
>>> > is it a safe practice to validate a page without reviewing its raw
>>> code?
>>>
>>> Probably yes.
>>> Obviously, it's safer to check the raw code but it's unrealistic to
>>> expect the raw code to be review for all page. Anyway, the pages
>>> doesn't
>>> contain a lot of code (and most pages does'nt contain code at all), so
>>> it
>>> doesn't seems to be crucial to me.
>>> Plus : when VisualEditor will be on WS, less and less people will
>>> actually see the raw wikicode.
>>>
>>> > A second point: is it a safe practice to validate a page without
>>> carefully reviewing its transclusion into ns0?
>>>
>>> Definitively yes.
>>> When can a transclusion can go wrong? In all cases I can think of, the
>>> problem come from templates, css classes or general stuff like that. It
>>> should be fixed generally and it shouldn't block the page validation
>>> since
>>> it have nothing to do the the page itself (but maybe I'm missing an
>>> obvious
>>> example here).
>>>
>>> > Alex
>>>
>>> Cdlt, ~nicolas
>>>
>>> _______________________________________________
>>> Wikisource-l mailing list
>>> Wikisource-l(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
As you all probably do,
I sometimes go and proofread/validate pages in Wikisource.
The validation (going from a 75% to a 100% level) is probably the simplest
of Wikisource tasks, and it's especially fit to teach fist to WS beginners.
When we do (in it.ws) the Proofreading contest, validated pages count in
thousands.
The point is:
as of today, the procedure is pretty cumbersome.
It's easy to read one text on the right column, and on the left column.
What is not easy is to navigate through the pages:
* our indexes are not easily findable, nor understandable
* the arrows for navigating are small
* for validating or proofreading a page, I have to click on Edit, and then
proofread, click on the right radiobutton, then save.
I was wondering if some of your communities has tried to ease the
procedure,
and make life more easy (and *QUICK*) for beginners and experts alike.
For me, I usually go to the Index Page, open in different tabs different
pages, then start reading.
But I'm sure we could come up with a different, easier procedure, when a
user *just reads, occasionaly edit and save the page as he progresses*. A
quicker, easier way to flip pages and reading.
Aubrey
Have the organizers asked Quim Gil (qgil(a)wikimedia.org) at the Foundation
for support from the development team and from the tool labs if we want to
have people with us that could fix some of the problems easily while we're
at it? The foundation would surely be gald to support such an event with
their teams...
Ernest Boucher, Wikimédia Canada (ca.wikimedia.org)
Wikisource: Projet Québec Canada (jecontribue.ca)
Following reports of gadgets being broken and javascript errors I have had
to do some editing on enWS at
https://en.wikisource.org/wiki/MediaWiki:Gadgets-definition
and to note that I did similar at Meta.
I have basically made every gadget utilise ResourceLoader. Whether it is
right or wrong, it has stopped the errors.
I am told that the OCR tool button and the horizontal layout button have
disappeared, and I think that might be for the new toolbar, I have no issue
in the old toolbar. More info will come if anything comes to light.
Regards, Billinghurst
Really note the effects of inaction...
I see affected will be
arWS gadget
bsWS monobook
deWS gadget + script
faWS monobook + gadget
frWS monobook
hews monobook + gadget
idWS 3 gadgets
mkWS gadget
saWS gadget
srWS monobook + script
trWS monobook
viWS gadget
yiWS script
Regards Billinghurst
---------- Forwarded message ---------
From: Bartosz Dziewoński <matma.rex(a)gmail.com>
Date: Thu, 6 Aug 2015 10:10
Subject: Re: [Wikitech-ambassadors] [BREAKING CHANGE] Use of
"document.write" no longer supported
To: wikitech-l Wikimedia List <wikitech-l(a)lists.wikimedia.org>,
wikitech-ambassadors Wikimedia List <
wikitech-ambassadors(a)lists.wikimedia.org>, Krinkle <krinklemail(a)gmail.com>
I think this announcement is missing one important tidbit:
If you have `document.write(…)` anywhere in your user JavaScript, **you
will get a blank page** on all pages of your wiki *, including the user
JavaScript page you'd have to edit to fix it, until you disable JavaScript
in your browser or ask an administrator to fix it for you.
If you have `document.write(…)` anywhere in the site JavaScript, **all
users** will **get a blank page** on all pages of the wiki *, including
anonymous readers, including all administrators who could fix it, until
one of them disables JavaScript in their browser, and finds and fixes the
broken script.
* Except for Special:Preferences and password-related pages, where user
and site JavaScript is disabled for security reasons.
On Thu, 06 Aug 2015 01:24:03 +0200, Krinkle <krinklemail(a)gmail.com> wrote:
> TL:DR; Double-check your wiki's site scripts and your personal scripts
> to ensure "document.write" is no longer used.
>
> Hey all,
>
> We have strongly discouraged for many years the use of synchronous
> "document.write()" to inject additional HTML into the output stream.
> Across MediaWiki core, extensions, and gadgets this hasn't worked since
> 2012.
> With two legacy exceptions: the 'site' and 'user' modules. We always
> found a way
> to continue support for those. But this is now going to be removed.
>
> In upcoming ResourceLoader upgrades and performance improvements, we will
> cease support for synchronous document-write, in the site and user
> modules.
> Use of document-write requires MediaWiki to instruct the browser to
> pause its
> rendering before the browser may proceed to parse and display a page to
> users.
>
> Even though most scripts don't use this feature, the mere fact that we
> support it
> is causing a measurable impact on page load performance.
>
> Starting in 1.26wmf17 (released to wikis this week), ResourceLoader will
> be
> fully asynchronous. This change is already live on the Beta Cluster. [1]
> This means it is no longer possible for the site and user scripts to,
> with
> document-write, pause the browser execution and insert additional HTML in
> the initial output stream.
>
> Removing an API does not necessarily mean removing a capability. If you
> encounter any issues or can't find a simple upgrade path for an existing
> script, please reach out on the mailing list. Below is summary of a few
> typical use cases:
>
> 1. Loading scripts.
>
> Instead of `document.write("<script src=url></script>");`
> use `mw.loader.load(url);` instead.
>
> 2. Loading stylesheets.
>
> Instead of `document.write("<link rel=stylesheet href=url/>");`
> use `mw.loader.load(url, "text/css");` instead.
>
> 3. Creating elements.
>
> Instead of `document.write("<div>....</div>");`, use:
>
> var nodes = $.parseHTML("<div>..</div>"); $('body').append(nodes);
>
> Or something like:
>
> $("<div>").attr({ "id": "foo" }).appendTo("body");
>
>
> Please take some time to look through your wiki's site scripts
> (MediaWiki:Common.js,
> MediaWiki:Vector.js, etc.) and make sure document-write is no longer
> used.
> You can also use the search engine. For example:
>
> https://nl.wikipedia.org/w/index.php?search=document.write&ns8=1
> https://commons.wikimedia.org/w/index.php?search=document.write&ns8=1
>
> Search results from mwgrep on all public wikis:
> https://phabricator.wikimedia.org/P1832
>
> Check out the migration page for other deprecations and common issues
> you may encounter:
> https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)
>
> == Further reading ==
>
> The ResourceLoader improvements that led to this change are tracked under
> https://phabricator.wikimedia.org/T107399.
>
> Refer to the following workboards for other tasks in this area:
>
https://phabricator.wikimedia.org/tag/mediawiki-resourceloader/board/?order…
>
https://phabricator.wikimedia.org/tag/performance-team/board/?order=priority
>
> Now that the site and user modules are primary citizens in the
> ResourceLoader landscape,
> their states can be tracked with mw.loader. This solves long-outstanding
> issues such as
> https://phabricator.wikimedia.org/T106736 which sometimes caused
> malfunctions
> in Common.js to affect user gadgets, VisualEditor, and other site tools.
>
> — Krinkle
>
> [1] http://en.wikipedia.beta.wmflabs.org/
>
>
> _______________________________________________
> Wikitech-ambassadors mailing list
> Wikitech-ambassadors(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
--
Bartosz Dziewoński
_______________________________________________
Wikitech-ambassadors mailing list
Wikitech-ambassadors(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
---------- Forwarded message ---------
From: Krinkle <krinklemail(a)gmail.com>
Date: Thu, 6 Aug 2015 09:24
Subject: [Wikitech-ambassadors] [BREAKING CHANGE] Use of "document.write"
no longer supported
To: wikitech-l Wikimedia List <wikitech-l(a)lists.wikimedia.org>,
wikitech-ambassadors Wikimedia List <
wikitech-ambassadors(a)lists.wikimedia.org>
TL:DR; Double-check your wiki's site scripts and your personal scripts
to ensure "document.write" is no longer used.
Hey all,
We have strongly discouraged for many years the use of synchronous
"document.write()" to inject additional HTML into the output stream.
Across MediaWiki core, extensions, and gadgets this hasn't worked since
2012.
With two legacy exceptions: the 'site' and 'user' modules. We always found
a way
to continue support for those. But this is now going to be removed.
In upcoming ResourceLoader upgrades and performance improvements, we will
cease support for synchronous document-write, in the site and user modules.
Use of document-write requires MediaWiki to instruct the browser to pause
its
rendering before the browser may proceed to parse and display a page to
users.
Even though most scripts don't use this feature, the mere fact that we
support it
is causing a measurable impact on page load performance.
Starting in 1.26wmf17 (released to wikis this week), ResourceLoader will be
fully asynchronous. This change is already live on the Beta Cluster. [1]
This means it is no longer possible for the site and user scripts to, with
document-write, pause the browser execution and insert additional HTML in
the initial output stream.
Removing an API does not necessarily mean removing a capability. If you
encounter any issues or can't find a simple upgrade path for an existing
script, please reach out on the mailing list. Below is summary of a few
typical use cases:
1. Loading scripts.
Instead of `document.write("<script src=url></script>");`
use `mw.loader.load(url);` instead.
2. Loading stylesheets.
Instead of `document.write("<link rel=stylesheet href=url/>");`
use `mw.loader.load(url, "text/css");` instead.
3. Creating elements.
Instead of `document.write("<div>....</div>");`, use:
var nodes = $.parseHTML("<div>..</div>"); $('body').append(nodes);
Or something like:
$("<div>").attr({ "id": "foo" }).appendTo("body");
Please take some time to look through your wiki's site scripts
(MediaWiki:Common.js,
MediaWiki:Vector.js, etc.) and make sure document-write is no longer used.
You can also use the search engine. For example:
https://nl.wikipedia.org/w/index.php?search=document.write&ns8=1https://commons.wikimedia.org/w/index.php?search=document.write&ns8=1
Search results from mwgrep on all public wikis:
https://phabricator.wikimedia.org/P1832
Check out the migration page for other deprecations and common issues you
may encounter:
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)
== Further reading ==
The ResourceLoader improvements that led to this change are tracked under
https://phabricator.wikimedia.org/T107399.
Refer to the following workboards for other tasks in this area:
https://phabricator.wikimedia.org/tag/mediawiki-resourceloader/board/?order…https://phabricator.wikimedia.org/tag/performance-team/board/?order=priority
Now that the site and user modules are primary citizens in the
ResourceLoader landscape,
their states can be tracked with mw.loader. This solves long-outstanding
issues such as
https://phabricator.wikimedia.org/T106736 which sometimes caused
malfunctions
in Common.js to affect user gadgets, VisualEditor, and other site tools.
— Krinkle
[1] http://en.wikipedia.beta.wmflabs.org/
_______________________________________________
Wikitech-ambassadors mailing list
Wikitech-ambassadors(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
I know that some may already do this, however, I worked out how to update
English Wikisource's call of the images of authors for the template, and
already we have added an extra 2k+ of images without manual effort (if
categorisation is to be believed).
You can see my efforts in [[s:en:Template:Author]] if you are looking to do
something similar.
I hope that makes sense. :-)
Regards, Billinghurst