The article https://da.wikipedia.org/wiki/Henrik,_Prinsgemalen has a
large number of sections, so it shows a table of contents. That works
fine, except one of the headings includes a ref, and the entire ref is
shown in the TOC. Is that on purpose? Is it a new thing? Can it be
changed? Could the note perhaps even be invisible in the TOC?
Where can I read more about this?
Regards,
Ole
--
http://palnatoke.org * @palnatoke * +4522934588
[ cross-posted to MediaWiki-i18n, Wikimedia-L and Wikitech-L ]
Dear Wikimedians,
The 2000th article that was written using the ContentTranslation extension
was published today.
Article #2000 was translated from English to Greek, and it's about Škocjan
Caves, a UNESCO World Heritage site in Slovenia.
Original: https://en.wikipedia.org/wiki/%C5%A0kocjan_Caves
Translated:
https://el.wikipedia.org/wiki/%CE%A3%CF%80%CE%AE%CE%BB%CE%B1%CE%B9%CE%B1_%C…
In case you're wondering what ContentTranslation is, here's a brief
summary: ContentTranslation is an extension that helps Wikipedia editors to
create articles quickly and easily by translating them from other
languages. It's being developed by the Language Engineering team. Its
design started in the summer of 2013 and its coding started in early 2014.
You can find more info at https://www.mediawiki.org/wiki/CX as well as in
the following blog posts:
* http://blog.wikimedia.org/2015/01/10/content-translation-beta-coming-soon/
* http://blog.wikimedia.org/2015/01/20/try-content-translation/
*
http://blog.wikimedia.org/2015/04/06/content-translation-improved-my-edits/
* http://blog.wikimedia.org/2015/04/08/the-new-content-translation-tool/
Some more data about ContentTranslation:
* Our first deployment was in mid-January to Catalan, Spanish, Portuguese,
Esperanto, Norwegian Bokmal, Danish, Indonesian and Malay. Now we support
43 languages, and this number is growing every week as we extend the
deployment (a special thank-you to the Ops and Release Engineering people,
who continuously and tirelessly support our deployment effort).
* In all the Wikipedias in which ContentTranslation is deployed, it is
currently defined as a Beta feature, which means that it is only available
to logged-in users who opted into it in the preferences.
* The 1000th article was written on April 10th, so it took much less to get
to 2000 than to 1000.
* The language into which the most articles were translated is Catalan:
762. The Catalan Wikipedia community always had a strong inclination to
translation, it was the first one that volunteered to test the tool in labs
in the summer of 2014 and provided a lot of useful feedback, and it also
has good machine translation support thanks to the Freely-licensed Apertium
engine.
* The second most popular target language is Spanish. It started slowly in
the first couple of months, but it's quickly growing since March.
* Other target languages that are quickly growing lately are French,
Portuguese and Ukrainian.
* The language from which the largest number of articles is translated is
English. It is followed by Spanish, from which a lot of articles are
translated to the closely related Portuguese and Catalan.
* The total number of people who published at least one translated article
into any language is 663.
* Of more than 2000 articles that were created, about 60 were deleted, so
we have a reason to think that the quality of the created articles is
pretty OK.
* In Catalan we see that ContentTranslation has some influence on the
number of articles created per day - it was usually between 60 and 90
before 2015, and in January and February it was over a 100. It's too early
to say how does it influence other languages, but we are optimistic ;)
* A community discussion about enabling the tool in the French Wikipedia
ended with 50 "votes" in support of the tool and 0 "votes" against it ;)
Some of our plans for the coming months are:
* Enabling more languages, including big ones like English, Russian and
Italian, as well as right-to-left languages.
* Improving the support for links.
* Creating support for smart suggestions of articles to translate, as well
as "task lists" for translation projects.
* Starting to get the tool out of beta status :)
I'd like to thank all the Wikimedia volunteers around the planet who are
participating in this effort by translating articles, translating the
extension's user interface, testing the tool, assisting other wikipedians
to translate, organizing translation workshops, reporting useful bugs,
submitting patches, and generally proving day after day what an incredible
community they are - hard-working, massively-multilingual, helpful,
patient, creative and talented.
Thank you - we have a lot more to achieve together \o/
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi Jane,
Thanks for trying ContentTranslation and providing feedback. Replies inline.
> I decided to translate a short article from Spanish to English
Currently the extension is configured for translation *from* English, but
not *to* English. This will probably be changed soon to allow translation
to English, but there will be a proper separate announcement about this.
> Then I tried to enable it for my 'Dutch userpage and
> got the extension up and running for Spanish-Dutch but couldn't find which
> link was the "from" link and the "to" link (a couple of tries and I got
the
> dashboard up and running).
The easiest ways to open the dashboard are:
1. Hovering over the Contributions link at the top personal bar and
clicking "Translations".
2. Opening the article that you want to translate and finding the language
into which you want to translate in the interlanguage links list. (It's
guessed automatically; for example, it's suposed to appear there if you
selected it in ULS.)
> Then I found myself in the Visual editor
It's not *the* VisualEditor, but *a* visual editor - a very simple WYSIWYG
editor. (It's possible that in the future it will be *the* VisualEditor,
but there's no solid plan for it yet.) There are several reasons for doing
it this way, see
https://www.mediawiki.org/wiki/Content_translation/Documentation/FAQ .
> and tried to wikify some text with no luck.
It doesn't support wiki syntax, as explained above. It supports simple
formatting and adding links (the links support is being rewritten right now
to be more stable and intuitive). Because it is not supposed to be a
full-fledged article editing environment, it only provides the most basic
formatting tools. For full-fledged wikification you can use the wikitext
editor or the VisualEditor, whichever you wish.
> I then clicked on one
> of the reference links and lost my work.
This is definitely a bug! Usually references work pretty well. Sorry about
that. Which article was it?
> I restarted the page and saved
> some basics, but was disappointed that there was no translation of the
> infobox or the image, which was what I was hoping for.
We don't support infoboxes yet. It's very challenging technically, so for
now we just ignore them, but we hope to have support for them in the
future. Currently, ContentTranslation is mostly for the articles' prose,
links, categories and images.
It is supposed to support images. In fact, in the real-life demos that I'm
doing it's the feature that experienced Wikipedians usually love the most.
Unfortunately, it cannot support an image that is a part of an infobox.
> Thanks for all of your work on this, because I do believe translating
> existing content is a direction that I personally want to take in the
> Wikiverse in general.
Thank you very much again for the testing and the feedback! We'll do our
best to address the bugs.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
2015-06-05 12:41 GMT+03:00 Jane Darnell <jane023(a)gmail.com>:
> Amir,
> This tool is great in theory and sounds wonderful but I am personally
> having some trouble putting it into practice.The short video was VERY
> helpful, but I am afraid I still ran into some problems on my second
> attempt at a translation. Here is a roundup of links:
>
> https://upload.wikimedia.org/wikipedia/commons/e/ee/Content_Translation_Scr…
>
> I decided to translate a short article from Spanish to English but since my
> Spanish is almost zero I first tried to change the translation interface to
> English but no luck. Then I tried to enable it for my 'Dutch userpage and
> got the extension up and running for Spanish-Dutch but couldn't find which
> link was the "from" link and the "to" link (a couple of tries and I got the
> dashboard up and running). Then I found myself in the Visual editor
> (yikes!) and tried to wikify some text with no luck. I then clicked on one
> of the reference links and lost my work. I restarted the page and saved
> some basics, but was disappointed that there was no translation of the
> infobox or the image, which was what I was hoping for.
>
> Here's the original:
>
> https://es.wikipedia.org/wiki/La_sala_del_concejo_del_ayuntamiento_de_%C3%8…
> Here's the result (all I got was the Wikidata item link, lead sentence and
> the category)
> https://nl.wikipedia.org/wiki/Raadskamer_in_het_stadhuis_van_Amsterdam
>
> Wikimagic added the Dutch infobox already, but shouldn't this be possible
> to do from the dashboard?
>
> Thanks for all of your work on this, because I do believe translating
> existing content is a direction that I personally want to take in the
> Wikiverse in general.
> Jane
>
> Thanks,
> Jane
>
> On Thu, Apr 30, 2015 at 3:23 PM, Amir E. Aharoni <
> amir.aharoni(a)mail.huji.ac.il> wrote:
>
> > [ cross-posted to MediaWiki-i18n, Wikimedia-L and Wikitech-L ]
> >
> > Dear Wikimedians,
> >
> > The 2000th article that was written using the ContentTranslation
> extension
> > was published today.
> >
> > Article #2000 was translated from English to Greek, and it's about
> Škocjan
> > Caves, a UNESCO World Heritage site in Slovenia.
> >
> > Original: https://en.wikipedia.org/wiki/%C5%A0kocjan_Caves
> > Translated:
> >
> >
> https://el.wikipedia.org/wiki/%CE%A3%CF%80%CE%AE%CE%BB%CE%B1%CE%B9%CE%B1_%C…
> >
> > In case you're wondering what ContentTranslation is, here's a brief
> > summary: ContentTranslation is an extension that helps Wikipedia editors
> to
> > create articles quickly and easily by translating them from other
> > languages. It's being developed by the Language Engineering team. Its
> > design started in the summer of 2013 and its coding started in early
> 2014.
> > You can find more info at https://www.mediawiki.org/wiki/CX as well as
> in
> > the following blog posts:
> > *
> >
> http://blog.wikimedia.org/2015/01/10/content-translation-beta-coming-soon/
> > * http://blog.wikimedia.org/2015/01/20/try-content-translation/
> > *
> >
> http://blog.wikimedia.org/2015/04/06/content-translation-improved-my-edits/
> > * http://blog.wikimedia.org/2015/04/08/the-new-content-translation-tool/
> >
> > Some more data about ContentTranslation:
> > * Our first deployment was in mid-January to Catalan, Spanish,
> Portuguese,
> > Esperanto, Norwegian Bokmal, Danish, Indonesian and Malay. Now we support
> > 43 languages, and this number is growing every week as we extend the
> > deployment (a special thank-you to the Ops and Release Engineering
> people,
> > who continuously and tirelessly support our deployment effort).
> > * In all the Wikipedias in which ContentTranslation is deployed, it is
> > currently defined as a Beta feature, which means that it is only
> available
> > to logged-in users who opted into it in the preferences.
> > * The 1000th article was written on April 10th, so it took much less to
> get
> > to 2000 than to 1000.
> > * The language into which the most articles were translated is Catalan:
> > 762. The Catalan Wikipedia community always had a strong inclination to
> > translation, it was the first one that volunteered to test the tool in
> labs
> > in the summer of 2014 and provided a lot of useful feedback, and it also
> > has good machine translation support thanks to the Freely-licensed
> Apertium
> > engine.
> > * The second most popular target language is Spanish. It started slowly
> in
> > the first couple of months, but it's quickly growing since March.
> > * Other target languages that are quickly growing lately are French,
> > Portuguese and Ukrainian.
> > * The language from which the largest number of articles is translated is
> > English. It is followed by Spanish, from which a lot of articles are
> > translated to the closely related Portuguese and Catalan.
> > * The total number of people who published at least one translated
> article
> > into any language is 663.
> > * Of more than 2000 articles that were created, about 60 were deleted, so
> > we have a reason to think that the quality of the created articles is
> > pretty OK.
> > * In Catalan we see that ContentTranslation has some influence on the
> > number of articles created per day - it was usually between 60 and 90
> > before 2015, and in January and February it was over a 100. It's too
> early
> > to say how does it influence other languages, but we are optimistic ;)
> > * A community discussion about enabling the tool in the French Wikipedia
> > ended with 50 "votes" in support of the tool and 0 "votes" against it ;)
> >
> > Some of our plans for the coming months are:
> > * Enabling more languages, including big ones like English, Russian and
> > Italian, as well as right-to-left languages.
> > * Improving the support for links.
> > * Creating support for smart suggestions of articles to translate, as
> well
> > as "task lists" for translation projects.
> > * Starting to get the tool out of beta status :)
> >
> > I'd like to thank all the Wikimedia volunteers around the planet who are
> > participating in this effort by translating articles, translating the
> > extension's user interface, testing the tool, assisting other wikipedians
> > to translate, organizing translation workshops, reporting useful bugs,
> > submitting patches, and generally proving day after day what an
> incredible
> > community they are - hard-working, massively-multilingual, helpful,
> > patient, creative and talented.
> >
> > Thank you - we have a lot more to achieve together \o/
> >
> >
> > --
> > Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> > http://aharoni.wordpress.com
> > “We're living in pieces,
> > I want to live in peace.” – T. Moore
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
Hi,
Gerrit needs to be restarted today at 18 UTC for a Java security update.
This will only take a brief amount of time (up to a few minutes), but it's
disruptive to ongoing comments/actions, so please refrain from using it
around that time.
I'll send a note to #wikimedia-operations once the restart is done.
Cheers,
Moritz
Many user scripts and gadgets, such as Twinkle, UserMessages, etc., need
to post on various talk pages.
With the development of Flow, there are now two possible types of talk
pages to deal with (not counting LQT, which this solution does not
handle), old-style and Flow. User talk pages are already starting to
use Flow on a very limited opt-in basis (I think the number is still
less than I have fingers).
Now, you can use MessagePoster to post to a page without knowing this
information ahead of time. The documentation is at
https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.messagePoster.…
, and you can see an example of how it's used at
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/977f7ad8ade23a7ce5326a9…
.
Feel free to reply, or ask on #wikimedia-collaboration, if you have any
questions.
Matt Flaschen
Hello,
The next office hour of the Wikimedia Language Engineering team (now part
of Editing) is scheduled for next Wednesday, June 10th at 14:30 UTC.
However, this time instead of only IRC we are hosting it as an online
discussion over Hangout/Youtube. Given the limitation of Google Hangouts,
there will be limited seats for joining into the Hangout. Hence, do let us
know (on the event page
<https://plus.google.com/u/0/events/cuunke6rbmqpetvslv6jlakbhnc>) if you
would like to participate on the Hangout. The IRC channel #wikimedia-office
and the Q&A channel for the youtube broadcast will also be open for
interactions during the session.
Our last online round-table session was held a few months back with the
editors of the Catalan Wikipedia. You can watch the recording here:
https://www.youtube.com/watch?v=vHu3vdlE1X8 .
Please read below for the event details and do let us know if you have any
questions.
Thank you
Runa
== Details ==
# *Event*: Wikimedia Language Engineering office hour session
# *When*: June 10th, 2015 (Wednesday) at 14:30 UTC (check local time
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150610T1430)
# *Where*: https://plus.google.com/u/0/events/cuunke6rbmqpetvslv6jlakbhnc
and on IRC #wikimedia-office (Freenode)
# *Agenda*: Content Translation
<https://www.mediawiki.org/wiki/Content_translation> updates and open Q & A
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Hi People Interested in Gather,
Given the reorg and the traffic being driven to beta, we need to revisit
Gather's Q4 goals:
TLDR: Continue working on gather to finish MVP features (end of the month,
max), not pushing to stable unless we see 2x the number of logged-in edits
on beta (or >10x current state).
Before the serious stuff:
Top 5 best collections since Monday:
https://en.m.wikipedia.org/wiki/Special:Gather/by/Johnrenfrohttps://en.m.wikipedia.org/wiki/Special:Gather/id/3454/Philadelphia_watchhttps://en.m.wikipedia.org/wiki/Special:Gather/id/3401/engineeringhttps://en.m.wikipedia.org/wiki/Special:Gather/id/3532/Mental_Healthhttps://en.m.wikipedia.org/wiki/Special:Gather/id/3132/Libertarianismo
Okay, now the goals. Please feel free to comment in email or in this google
doc
<https://docs.google.com/a/wikimedia.org/document/d/1DK1pa3PEpIbiON0Bj6BrhGA…>
Thanks,
Jon
Given the reorg and an improvement made to beta, we need to revisit
Gather's goals
Pushing to Stable
Given that we can now test Gather numbers in beta, the original goal of
launching on stable to test adoption is no longer valid. It is expensive
in terms of future maintenance and commitments to launch features to
stable, so we only want to do so after we have proven success, if possible.
Target numbers
Originally, the benchmarks for success on stable that were agreed on were
low (10k creators a month on stable, and 1k shares). Given the current
beta numbers, it looks like we will blow the first number out of the
water. Share has been deprioritized given current usage patterns.
However, given that we now have 4 engineers in charge of the entire web,
the standards for what we work on have to be more rigorous. We cannot
allocate multiple engineers to an experimental product unless it shows
promise of impacting greater numbers
1. Goal
1.
New Goal:
1.
Round out Gather hypothesis (criteria below)
2.
By end of June know whether or not we want to push Gather to stable
1. Next Eng+PM Steps (to round out hypothesis)
1.
Improve onboarding (a few tasks)
2.
Surface collections publicly (this is a big missing feature)
3.
Qualitative and quantitative research
2. Criteria for passing to stable:
We don’t have a great way to measure success of Gather based on usage by a
proportion of users or logged in users. However, we can compare to
something similar like edits. In terms of pure value to WP, we can
consider a collection to be like a low-value edit.
-
There are 2x ‘good’ collections made as there are total logged-in
edits/month
-
in May there were 2,180 edits by logged in users (2,694 logged out).
-
At current rates this suggests ~4,500 collections per month is our
target.
-
‘good’ here, means >1 collection--it’s not a perfect definition, but
it’s a strong proxy.
-
Our current rate of ‘good’ collections is roughly 250 a month, so we
will need to increase the number by almost 20x.
-
It might be worth exploring % of those 2,180 edits that are reverted
and adjusting down accordingly
OR
-
Views of collections or where collection is the referrer > .5% of total
pageviews
-
Currently, the views of collections are minimal.
-
If very few people create collections, but they drive a significant
boost in page views, say .5% of total PVs (not an end goal, but also not
bad for an MVP introducing a new use case), then the feature is a success.
1. What if we don’t pass to stable:
Lets burn that bridge when we get to it :) . Seriously though, until we get
some qualitative data back from our readers, we will not be able to make
important calls on the feature as is. There are a few great alternatives I
can think of right off the bat:
-
Keep code in beta and work on Gather opportunistically or as qualitative
data dictates
-
One example might be to make collections private by default and
launch as bookmarker for readers (primary current use-case)
-
Promote as beta feature on desktop
-
Use codebase as start of multiple watchlists (some good work started
here by JRobson)
-
Codebase is fairly generic list table that has some basic and
interesting features built in that could be used for a number of other ends
1. Validation and why we choose this criteria:
Qualitative questions to answer:
Why aren't more people using Gather? (correctly)
Why aren't people returning to use Gather more
Success metric questions to answer (that we can’t already):
What % of logged in users use Gather
What % of users who visit > 1 page use Gather
What is our denominator
Status
Measure logins and signup funnel directed from Gather, what is % success
rate?
This is not instrumented
Measure % of sessions with more than 1 pageview
Working on this
Measure % of sessions with logged in users
Cannot get this
What is our baseline? Logged in edits is probably the best thing to
measure against.
I'm joining in disappointment too. Extreme coupling to an young platform
like wikidata created a lot of trouble for making anything with the
project, and kill all momentum and made it look bad.
I feel like this kind of micro-contributions are the only effective way we
are going to be able to engage mobile users in improving wikipedia, and the
micro contributions itself as infrastructure could've been something really
empowering.
We should've designed and tested lots of different micro-contributions
experiments and mechanisms and measured results, without worrying about
where the underlying data will end up (maybe wikipedia, maybe wikidata,
maybe other projects). With how the project was managed we only have data
for a Question - Yes/No/MultipleAnswer type of micro-contribution, which
shouldn't be enough to judge the whole underlying idea.
Now there's a lot of skepticism towards the idea in any of its forms :(
I would love to see a *lessons learned* (not just from the data but from
the struggles of the project), we should get the most of it while it is
still fresh on our memories.
On Tue, Jun 2, 2015 at 4:13 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> Totally; as I think my email made clear, I was aware that the limiting
> factor here was the sheer cost of building out the infrastructure. The
> core question, though, was what the project would be replaced with -
> what those "highest return-on-investment" projects were.
>
> On 1 June 2015 at 20:45, Jon Katz <jkatz(a)wikimedia.org> wrote:
> > Hi Oliver,
> > Thanks for sharing your disappointment. I do not think you are alone in
> > wanting to see wikigrok continue and grow. I would clarify that the
> > 'success rates' you allude to were for reader engagement and accuracy,
> not
> > in actually improving our projects by filling in important gaps in
> wikidata.
> > A great deal of work would be required to build out in order for this
> > project to have a scalable impact on wikidata.
> >
> > I am not saying that casual contributions are going away, simply that we
> are
> > going to recognize our resource limitations and evaluate opportunities
> for
> > them based on highest return-on-investment. We currently have 5
> developers
> > working on readership for the entire web (due to some temporary leaves)
> and
> > there might be smaller wins using casual contributions that work towards
> our
> > end goal, but don't require the heavy upfront investment. This doesn't
> mean
> > we don't take on big thorny problems, just that we take a step back and
> see
> > if there are ways to subdivide them into smaller projects along the way.
> >
> > Best,
> >
> > Jon
> >
> > [1]
> >
> https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
> >
> > On Mon, Jun 1, 2015 at 12:05 PM, Oliver Keyes <okeyes(a)wikimedia.org>
> wrote:
> >>
> >> I'm personally incredibly disappointed; this was the most successful
> >> intervention I'd seen anyone try in a long while, if ever, and the
> >> results blow me away. My question would be "what interventions with
> >> similarly high success rates are going to be worked on instead?" - I
> >> assume that we're not working on them because we can achieve the same
> >> outcome through easier-to-implement interventions. I would be
> >> interested to hear what those interventions are.
> >>
> >> On 1 June 2015 at 14:57, Jon Katz <jkatz(a)wikimedia.org> wrote:
> >> > Hi,
> >> >
> >> > TLDR: Wikigrok proved that readers are interested in and capable of
> >> > making
> >> > casual, mobile contributions to Wikipedia. We are putting continued
> >> > development of the 'Wikigrok' casual contribution feature on hold
> until
> >> > we
> >> > have a plan for optimally harnessing this interest/capability.
> >> >
> >> > Background
> >> > Given the growth of mobile traffic on wikipedia and the challenges
> >> > inherent
> >> > to traditional editing on a mobile device, Wikigrok was proposed as a
> >> > way to
> >> > test if regular wikipedia readers would be interested in making
> smaller,
> >> > more casual contributions to wikimedia projects while reading
> Wikipedia
> >> > on a
> >> > mobile device.
> >> >
> >> > Results
> >> > By early 2015, the results were in: readers were relatively interested
> >> > in
> >> > engaging with the feature[1]. Some oft-quoted comparisons include:
> >> >
> >> > 3x the number of unique responders as mobile editors during test
> period
> >> > (4.5K editors, 12.3K WikiGrokkers), even with WG on sample of
> articles &
> >> > users
> >> > 1.5x better clickthrough than 2014 Fundraising full-screen mobile
> banner
> >> >
> >> > (I actually do not have references for these, as they are borrowed
> >> > quotes)
> >> > Furthermore, we found that the quality of responses was rather high
> >> > [2,3].
> >> >
> >> > Future
> >> > The original thought was to use these responses to fill in gaps in
> >> > Wikidata
> >> > and our initial test results (2 weeks worth) were successfully ported
> >> > over
> >> > in late April [4]. However, in order to production-ize the system, we
> >> > would
> >> > have to:
> >> >
> >> > scale and develop queries against the new wikidata query service
> >> > create an article parser to identify potential multiple choice answers
> >> > for
> >> > each question
> >> > create a system for attributing aggregated results to the specific
> >> > contributors (per Wikidata bot request discussion[5])
> >> >
> >> > None of these are unsurpassable, but we have learned a great deal and,
> >> > at
> >> > this stage, we believe that further effort should be devoted to
> >> > evaluating
> >> > areas of need and fit before we commit additional efforts to
> >> > specifically
> >> > porting information into Wikidata.
> >> >
> >> > Please feel free to reach out if you have any questions or concerns
> >> > about
> >> > this decision.
> >> > Best,
> >> >
> >> > Jon
> >> >
> >> > [1] https://meta.wikimedia.org/wiki/Research:WikiGrok/Test2
> >> > [2] Quality of responses, version A:
> >> >
> >> >
> https://www.wikidata.org/wiki/File:All_Campagins,_Scatterplot,_version_(a).…
> >> > [3] Quality of responses, version B:
> >> >
> >> >
> https://www.wikidata.org/wiki/File:All_Campaigns,_Scatterplot,_version_(b).…
> >> > [4]
> >> >
> https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500
> >> > [5]
> >> >
> >> >
> https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
> >> >
> >> >
> >> > _______________________________________________
> >> > Mobile-l mailing list
> >> > Mobile-l(a)lists.wikimedia.org
> >> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >> >
> >>
> >>
> >>
> >> --
> >> Oliver Keyes
> >> Research Analyst
> >> Wikimedia Foundation
> >
> >
>
>
>
> --
> Oliver Keyes
> Research Analyst
> Wikimedia Foundation
>
> _______________________________________________
> reading-wmf mailing list
> reading-wmf(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
This is something that the pywiki devs need to fix in compat. Please dont
give me shit about moving to core. I have yet to have it not fatally error
out in less than 10 minutes of using it. There are still a lot of features
that core doesnt have, or that are poorly implemented.
On Tue, Jun 2, 2015 at 8:27 PM, Pine W <wiki.pine(a)gmail.com> wrote:
> Forwarding because of the significance of the change for bots. My
> understanding is that this affects all wikis, so please get this
> information out to relevant bot operators on all wikis. Translated messages
> may be very much appreciated.
>
> Pine
> ---------- Forwarded message ----------
> From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org>
> Date: Jun 2, 2015 1:43 PM
> Subject: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for
> action=query will change at the end of this month
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>, <
> mediawiki-api-announce(a)lists.wikimedia.org>
> Cc:
>
> As has been announced several times (most recently at
> https://lists.wikimedia.org/pipermail/wikitech-l/2015-April/081559.html),
> the default continuation mode for action=query requests to api.php will be
> changing to be easier for new coders to use correctly.
>
> *The date is now set:* we intend to merge the change to ride the deployment
> train at the end of June. That should be 1.26wmf12, to be deployed to test
> wikis on June 30, non-Wikipedias on July 1, and Wikipedias on July 2.
>
> If your bot or script is receiving the warning about this upcoming change
> (as seen here
> <https://www.mediawiki.org/w/api.php?action=query&list=allpages>, for
> example), it's time to fix your code!
>
> - The simple solution is to simply include the "rawcontinue" parameter
> with your request to continue receiving the raw continuation data (
> example
> <
>
> https://www.mediawiki.org/w/api.php?action=query&list=allpages&rawcontinue=1
> >).
> No other code changes should be necessary.
> - Or you could update your code to use the simplified continuation
> documented at
> https://www.mediawiki.org/wiki/API:Query#Continuing_queries
> (example
> <
> https://www.mediawiki.org/w/api.php?action=query&list=allpages&continue=
> >),
> which is much easier for clients to implement correctly.
>
> Either of the above solutions may be tested immediately, you'll know it
> works because you stop seeing the warning.
>
> I've compiled a list of bots that have hit the deprecation warning more
> than 10000 times over the course of the week May 23–29. If you are
> responsible for any of these bots, please fix them. If you know who is,
> please make sure they've seen this notification. Thanks.
>
> AAlertBot
> AboHeidiBot
> AbshirBot
> Acebot
> Ameenbot
> ArnauBot
> Beau.bot
> Begemot-Bot
> BeneBot*
> BeriBot
> BOT-Superzerocool
> CalakBot
> CamelBot
> CandalBot
> CategorizationBot
> CatWatchBot
> ClueBot_III
> ClueBot_NG
> CobainBot
> CorenSearchBot
> Cyberbot_I
> Cyberbot_II
> DanmicholoBot
> DeltaQuadBot
> Dexbot
> Dibot
> EdinBot
> ElphiBot
> ErfgoedBot
> Faebot
> Fatemibot
> FawikiPatroller
> HAL
> HasteurBot
> HerculeBot
> Hexabot
> HRoestBot
> IluvatarBot
> Invadibot
> Irclogbot
> Irfan-bot
> Jimmy-abot
> JYBot
> Krdbot
> Legobot
> Lowercase_sigmabot_III
> MahdiBot
> MalarzBOT
> MastiBot
> Merge_bot
> NaggoBot
> NasirkhanBot
> NirvanaBot
> Obaid-bot
> PatruBOT
> PBot
> Phe-bot
> Rezabot
> RMCD_bot
> Shuaib-bot
> SineBot
> SteinsplitterBot
> SvickBOT
> TaxonBot
> Theo's_Little_Bot
> W2Bot
> WLE-SpainBot
> Xqbot
> YaCBot
> ZedlikBot
> ZkBot
>
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> Wikimedia Foundation
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>