Re: [Wikitech-l] Contributing to Wikimedia as Web Developer and Systems Administrator
Hi, I would like to know the project ideas being proposed for Gsoc 2014 so that I can start working on the project of my interest and discuss the idea with the mentor. Thanks On Sat, Jan 18, 2014 at 11:55 PM, Quim Gil q...@wikimedia.org wrote: Hi Nitin, On 01/18/2014 12:55 AM, Nitin Agarwal wrote: I would like to Wikimedia as Web Developer and Systems Administrator projects. I have gone through the https://www.mediawiki.org/wiki/Starter_kitand installed and configured mediawiki on my machine running at localhost. Very good! The next step is to choose a first bug to work on. Check https://www.mediawiki.org/wiki/Annoying_little_bugs If you have doubts about a specific bug you can ask directly in the bug report. If you are interested in GSoC then a good strategy is to select a project, and focus all your attention there. Find the related easy bugs and fix them while meeting the regular contributors in that area. Thank you for your interest in contributing to Wikimedia. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- *Nitin Agarwal* Website : www.nitinagarwal.in Github : *https://github.com/NitinAgarwal https://github.com/NitinAgarwal*IRC : nitinagarwal3006 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Reasonator use in Wikipedias
Hoi,
The mail I send is meant to be a warning in advance. If you are interested
in the Reasonator, it is in continuous development and information is
provided on an almost daily basis. When you have read it, you may
understand the potential it has. It will help you understand why it can
have a place as a stand in for an article in a Wikipedia and also why it
can beat the quality of information of most stubs.
There are many ways to skin a cat. The most obvious one is to add a
{{Reasonator}} template as a place holder in a Wikipedia. Another is to
capture a not found or a red link and insert Reasonator info. What I am
trying to do is to give a sense of direction. I am not indicating how it
will be done for sure.
When the English Wikipedia community makes a decision, it is what the
English Wikipedia community thinks best for itself. No problem in that. It
would only become a problem when it is inferred to be a decision for every
Wikipedia community.
The he Media Viewer is very similar to the situation at hand with Wikidata
and Reasonator. Wikidata data can be used on every Wikipedia and to some
extend this is done on many if not most Wikipedias (including en.wp). Like
with Media, it can be confusing that the information is actually not on
that local project. It is also not that obvious that Wikidata is not
necessarily interested in the policies that are dreamt up locally. The
alternative is NOT having central storage of images or NOT having central
data storage. Both are not really an option.
I like the fact that you come up with some suggestions however, your
proposal does not consider disambiguation. At this stage we are improving
the information that is provided by Reasonator; the latest iteration has
de-cluttered complicated pages like the one for Shakespeare a lot while
adding to the information that is made available.
Quality information is provided by the Reasonator, the biggest problem I
see is that we do not have info-boxes of high quality available when an
article is being written.
Thanks,
GerardM
On 21 January 2014 20:07, Ryan Kaldari rkald...@wikimedia.org wrote:
Can you explain how such a {{Reasonator}} template would actually work. You
say that it would be a stand-in until the article was actually written, but
how would it know when the article is actually written? Is there a way to
access the target article's state via Lua?
From a community perspective, linking to external sites from body content
is normally frowned upon (on en.wiki at least), even if the link is to a
sister project. There are two main reasons for this:
1. It discourages the creation of new articles via redlinks
2. It can be confusing for readers to be sent to other sites while surfing
Wikipedia content. (This is one of reasons why the WMF Multimedia team has
been developing the Media Viewer.)
My suggestion would be to leave the redlinks intact, but to provide a
pop-up when hovering over the redlinks (similar to Navigation pop-ups (
https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups)). This
pop-up could provide a small set of core data (via an ajax request) and
also a link to the full Reasonator page. I would probably implement this as
a gadget first and do a few design iterations based on user-feedback before
proposing it as something for readers.
Ryan Kaldari
On Tue, Jan 21, 2014 at 10:02 AM, Magnus Manske
magnusman...@googlemail.com
wrote:
On a technical note, Reasonator is pure JavaScript, so should be easily
portable, even to a Wikipedia:Reasonator.js page (or several pages, with
support JS).
git here:
https://bitbucket.org/magnusmanske/reasonator
On Tue, Jan 21, 2014 at 5:13 PM, Ryan Lane rlan...@gmail.com wrote:
On Tue, Jan 21, 2014 at 7:17 AM, Gerard Meijssen
gerard.meijs...@gmail.comwrote:
Hoi,
At this moment Wikipedia red links provide no information
whatsoever.
This is not cool.
In Wikidata we often have labels for the missing (=red link)
articles.
We
can and do provide information from Wikidata in a reasonable way that
is
informative in the Reasonator. We also provide additional search
information on many Wikipedias.
In the Reasonator we have now implemented red lines [1]. They
indicate
when a label does not exist in the primary language that is in use.
What we are considering is creating a template {{Reasonator}} that
will
present information based on what is available in Wikidata. Such a
template
would be a stand in until an article is actually written. What we
would
provide is information that is presented in the same way as we
provide
it
as this moment in time [2]
This may open up a box of worms; Reasonator is NOT using any caching.
There
may be lots of other reasons why you might think this proposal is
evil.
All
the evil that is technical has some merit but, you have to consider
that
the other side of the
[Wikitech-l] How to retrieve the page, execute some time expensive operation and edit the page ONLY if it wasn't changed meanwhile
The title pretty much say what I need 1) Retrieve the page - page must not be changed starts NOW 2) Do something what requires user input, possibly may last few minutes 3) Save the page ONLY if it wasn't changed, if it was, go back to step 1 this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout. Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to retrieve the page, execute some time expensive operation and edit the page ONLY if it wasn't changed meanwhile
Just to make it clear: 1) Retrieve the page, store last edit time as TIME 2) Do something what requires user input, possibly may last few minutes 3) Retrieve the page history Possible race condition here, what if someone edit the page before step 3 and 5 4) Compare time of last edit in page history with TIME in order to check if page was edited Possible race condition here, what if someone edit the page before step 4 and 5 5) Edit This is not what I need ^ I need something better :-) On Wed, Jan 22, 2014 at 12:41 PM, Petr Bena benap...@gmail.com wrote: The title pretty much say what I need 1) Retrieve the page - page must not be changed starts NOW 2) Do something what requires user input, possibly may last few minutes 3) Save the page ONLY if it wasn't changed, if it was, go back to step 1 this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout. Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to retrieve the page, execute some time expensive operation and edit the page ONLY if it wasn't changed meanwhile
On Jan 22, 2014 7:41 AM, Petr Bena benap...@gmail.com wrote: The title pretty much say what I need 1) Retrieve the page - page must not be changed starts NOW 2) Do something what requires user input, possibly may last few minutes 3) Save the page ONLY if it wasn't changed, if it was, go back to step 1 this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout. Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Starttimestamp and basetimestamp? -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to retrieve the page, execute some time expensive operation and edit the page ONLY if it wasn't changed meanwhile
In documentation I see: basetimestamp: Timestamp of the base revision (obtained through prop=revisionsrvprop=timestamp). Used to detect edit conflicts; leave unset to ignore conflicts starttimestamp: Timestamp when you obtained the edit token. Used to detect edit conflicts; leave unset to ignore conflicts What is difference between these two? Documentation say that there is only 1 edit token which is changed only when user log out / log back. However that makes no sense when description of starttimestamp tell something about Timestamp of token. Is there really only 1 edit token? Is it really same for all pages? Does it really change only when user relog? How does it change for IP users? On Wed, Jan 22, 2014 at 12:47 PM, Brian Wolff bawo...@gmail.com wrote: On Jan 22, 2014 7:41 AM, Petr Bena benap...@gmail.com wrote: The title pretty much say what I need 1) Retrieve the page - page must not be changed starts NOW 2) Do something what requires user input, possibly may last few minutes 3) Save the page ONLY if it wasn't changed, if it was, go back to step 1 this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout. Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Starttimestamp and basetimestamp? -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to retrieve the page, execute some time expensive operation and edit the page ONLY if it wasn't changed meanwhile
The time you obtained the edit token has nothing to do with the uniqueness of the token, or the effective life time of the token. I believe starttimestamp is just any edit after this point is a conflict, where base timestamp should match the timestamp of the base revision. Thus the difference between them is you give them different values. -bawolff On Jan 22, 2014 7:52 AM, Petr Bena benap...@gmail.com wrote: In documentation I see: basetimestamp: Timestamp of the base revision (obtained through prop=revisionsrvprop=timestamp). Used to detect edit conflicts; leave unset to ignore conflicts starttimestamp: Timestamp when you obtained the edit token. Used to detect edit conflicts; leave unset to ignore conflicts What is difference between these two? Documentation say that there is only 1 edit token which is changed only when user log out / log back. However that makes no sense when description of starttimestamp tell something about Timestamp of token. Is there really only 1 edit token? Is it really same for all pages? Does it really change only when user relog? How does it change for IP users? On Wed, Jan 22, 2014 at 12:47 PM, Brian Wolff bawo...@gmail.com wrote: On Jan 22, 2014 7:41 AM, Petr Bena benap...@gmail.com wrote: The title pretty much say what I need 1) Retrieve the page - page must not be changed starts NOW 2) Do something what requires user input, possibly may last few minutes 3) Save the page ONLY if it wasn't changed, if it was, go back to step 1 this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout. Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Starttimestamp and basetimestamp? -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC cluster summary: HTML templating
When writing very complex multi-function Special Pages (almost all of our internal tools are built as special pages) it gets kind of unwieldy with the special page class that just has a single execute() function and the redundant boilerplate to define ajax functions etc. Since most of our front end is javascript now and we sometimes want templates/html or json data from the same controllers, we have a 1:1 mapping between methods and templates and every controller method is automatically an ajax function that can return json or html. The front end can call ANY back end method and ask for json data or the html with the data applied to it. When the Controller gets “too unwieldy” (the threshold for this depends on the developer) we generally refactor them into a single Controller and a set of Helper classes so that we retain the same external end points, just moving the code around. Here’s an example of that: On every content page, there’s a right rail module that shows the latest photos uploaded to the wiki: http://fallout.wikia.com/wiki/Nikola_Tesla_and_You_(Fallout_3) on the back end, that’s entirely self contained in this LatestPhotosController which is dropped into the skin with a render() function. However, the data that it generates can be used in other places: http://fallout.wikia.com/wikia.php?controller=LatestPhotos (call controller, combine data with html and return it) http://fallout.wikia.com/wikia.php?controller=LatestPhotosformat=json (call controller, just return the data that would have been in the template) The default method is executeIndex() and the default template is controller_Index. Here’s the controller code: https://github.com/Wikia/app/blob/dev/skins/oasis/modules/LatestPhotosController.class.php#L21 And the template: https://github.com/Wikia/app/blob/dev/skins/oasis/modules/templates/LatestPhotos_Index.php Hope that helps provide a bit more context for how this is actually used in the application. This is very cool, Owen. Once we have a templating engine picked out, conventions like this make life easier. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to retrieve the page, execute some time expensive operation and edit the page ONLY if it wasn't changed meanwhile
On Wed, Jan 22, 2014 at 4:11 AM, Brian Wolff bawo...@gmail.com wrote: I believe starttimestamp is just any edit after this point is a conflict, where base timestamp should match the timestamp of the base revision. Thus the difference between them is you give them different values. basetimestamp corresponds to wpEdittime in the web UI. If this doesn't match the top revision's timestamp, it is an edit conflict (which might be automatically resolved, just as with the web UI). Omitting it prevents any detection of such edit conflicts, meaning you're likely to just overwrite someone else's edit. starttimestamp corresponds to wpStarttime in the web UI. It is used to detect situations such as article was deleted since I started editing it. Omitting it means that you might recreate an article that has been deleted, or restore the deleted version if the article was deleted and then partially restored. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Xmldatadumps-l] Compressing full-history dumps faster
On 01/21/2014 11:10 PM, Amir Ladsgroup wrote: why? can we make it compressed? It's really annoying to see that huge file there for (even almost) no reason. It's probably because it's relatively small on major wikis (e.g. English Wikipedia has it 3.8 GB). However, I see no reason not to compress it, especially when it's larger (like Wikidata's). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to retrieve the page, execute some time expensive operation and edit the page ONLY if it wasn't changed meanwhile
this explanation should be in the documentation ;) anyway I guess I need to use both of them? On Wed, Jan 22, 2014 at 8:22 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Jan 22, 2014 at 4:11 AM, Brian Wolff bawo...@gmail.com wrote: I believe starttimestamp is just any edit after this point is a conflict, where base timestamp should match the timestamp of the base revision. Thus the difference between them is you give them different values. basetimestamp corresponds to wpEdittime in the web UI. If this doesn't match the top revision's timestamp, it is an edit conflict (which might be automatically resolved, just as with the web UI). Omitting it prevents any detection of such edit conflicts, meaning you're likely to just overwrite someone else's edit. starttimestamp corresponds to wpStarttime in the web UI. It is used to detect situations such as article was deleted since I started editing it. Omitting it means that you might recreate an article that has been deleted, or restore the deleted version if the article was deleted and then partially restored. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Contributing to Wikimedia as Web Developer and Systems Administrator
On 01/22/2014 12:19 AM, Nitin Agarwal wrote: Hi, I would like to know the project ideas being proposed for Gsoc 2014 so that I can start working on the project of my interest and discuss the idea with the mentor. We are not there yet. It is very good that you want to take the initiative now, but then you must either * find an interesting project at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects * start drafting and pitching a proposal of you own * increase your count of fixed https://www.mediawiki.org/wiki/Annoying_little_bugs Pick an area, start fixing bugs, get familiar with the related components and the people contributing to them... This is probably the best way for a newcomer to become a strong GSoC candidate. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to retrieve the page, execute some time expensive operation and edit the page ONLY if it wasn't changed meanwhile
On 01/22/2014 12:35 PM, Petr Bena wrote: this explanation should be in the documentation ;) anyway I guess I need to use both of them? basetimestamp (the timestamp of the revision your edit is based on) should be sufficient. I might be missing something, but I can't think of a scenario where: 1. Get the ID and timestamp of the last revision. 2. Get the text of that revision. 3. Do long-running computation based on that text. 4. POST an edit (resulting from that computation) with basetimestamp set to the timestamp obtained in #1. will cause a race condition. Matthew Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
