Wikisource-l

wikisource-l@lists.wikimedia.org

2 participants
1306 discussions

Re: [Wikisource-l] Better way to validate pages
by Erasmo Barresi 18 Aug '15

18 Aug '15

Hum... why should these "button validations" count less, so that four or five of them are needed to change the page status? Certainly not because "the code is not being checked", since the code stays unchecked no matter how many "button validations" are done. Possibly it would be better if the button(s) opened a flyout telling users what to do: create an account if they do not have one yet, then click edit, [correct what's wrong,] change the page status and save. I think it is better that new users begin to take part in the main editing workflow rather than operating on a separate one that is designed for them. Whether to make the _next_ page appear after saving is entirely another question, and one to which I would answer "yes". This cannot be done for the very last page of an index, of course. Erasmo > Date: Fri, 14 Aug 2015 15:46:31 +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=VxyZZG0vNpOhkqN52bqYS-48U0PVopax9PuPoWpqRd_8-0g(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Fri, Aug 14, 2015 at 2:06 PM, zdzislaw <zdzislaw.wiki(a)gmail.com> wrote: > > > In the view mode of the yellow Pages (sic! :-)), we can add the "Thin (but > > long) Green Button" (TGB) described: "I read and carefully compared the > > contents with the scan - there's no mistakes." :) Users who "DO read our > > books" (and they do not want / do not have time / skills... to edit) click > > on this button and simply go to the view mode of the next page. Such a > > click would be counted (extra field in the mw database), but did not cause > > an immediate change of the Page status. If for a given page will be counted > > three??, four?? such clicks (this amount would have to have the ability to > > configure for each WS - community could determine their "quality threshold" > > - for "one click" it will became into BGB), then the Page status would > > change automatically from "yellow" to "green". Of course, it would be also > > configurable, to whom show TGB (ip, registered, autopotrolled ...). > > Such a solution would have be implemented directly in the proofread > > extension. > > "TGB" would allow adjustment of the level of "quality" and would be > > acceptable by most the community. If it is true that " a lot of users DO > > read our books," even for 5-4 "clicks" the status would change quickly. > > > > > I do like this approach, and I'd love to see some tests. > I really believe that is good to do tests and experiments, as we are > sometimes convinced by things that are not really proven. > > A 3 step validation passage as you suggest could maybe be easy enough for > new users and casual readers, and we could gain some validations we could > not have had otherwise. > > > I also would like to repeat my question about the Visual Editor: are we > close tho that or nobody is working on it? > > Aubrey

3 3

Re: [Wikisource-l] Better way to validate pages
by ankry＠mif.pg.gda.pl 14 Aug '15

14 Aug '15

> 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

8 27

Re: [Wikisource-l] Better way to validate pages
by Erasmo Barresi 14 Aug '15

14 Aug '15

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 > > > >

1 0

Re: [Wikisource-l] Better way to validate pages
by ankry＠mif.pg.gda.pl 11 Aug '15

11 Aug '15

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

2 1

Better way to validate pages
by Andrea Zanni 11 Aug '15

11 Aug '15

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

5 8

Re: [Wikisource-l] Wikisource Conference, Wien, November 20-22
by Ernest Boucher 10 Aug '15

10 Aug '15

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)

2 1

Gadgets broken around the place & js errors
by billinghurst 09 Aug '15

09 Aug '15

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

2 2

Fwd: [Wikitech-ambassadors] [BREAKING CHANGE] Use of "document.write" no longer supported
by billinghurst 06 Aug '15

06 Aug '15

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

1 0

Fwd: [Wikitech-ambassadors] [BREAKING CHANGE] Use of "document.write" no longer supported
by billinghurst 06 Aug '15

06 Aug '15

---------- 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=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

1 0

Calling images from wikidata for author pages
by billinghurst 05 Aug '15

05 Aug '15

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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Wikisource-l