Wikitext-l

wikitext-l@lists.wikimedia.org

239 discussions

Re: [Wikitext-l] [Mediawiki-api] [Engineering] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 01 Feb '16

01 Feb '16

Luigi, On Thu, Jan 28, 2016 at 2:09 AM, XDiscovery Team <info(a)xdiscovery.com> wrote: > I tried /rest_v1/ endpoint and it is terribly fast. that is great to hear. A major goal is indeed to provide high volume and low latency access to our content. > @Strainu / @Gabriel , what does 'graph' extension do ? If you refer to https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_graph_png…, this is an end point exposing rendered graph images for https://www.mediawiki.org/wiki/Extension:Graph (as linked in the end point documentation). > I have few questions for using proxy cache: > 1# Is it possible to query a page by page_ID and include redirect? We don't currently provide access by page ID. Could you describe your use case a bit to help us understand how access by page id would help you? > /page/title/{title} > allow to get metadata by page, including the pageID , but I would like to > have final page redirect (e.g. dna return 7956 and I would like to fetch > 7955 of redirected 'DNA' ) We are looking into improving our support for redirects: https://phabricator.wikimedia.org/T118548. Your input on this topic would be much appreciated. > /page/html/{title} get the article but page_ID / curid is missing in source > I would like to get the two combined. This information is actually included in the response, both in the `ETag` header and in the <head> of the HTML itself. I have updated the documentation to spell this out more clearly in [1]. The relevant addition is this: The response provides an `ETag` header indicating the revision and render timeuuid separated by a slash (ex: `ETag: 701384379/154d7bca-c264-11e5-8c2f-1b51b33b59fc`). This ETag can be passed to the HTML save end point (as `base_etag` POST parameter), and can also be used to retrieve the exact corresponding data-parsoid metadata, by requesting the specific `revision` and `tid` indicated by the `ETag`. > 2# The rest are experimental: > what could happen if a query fail? > Does it raise an error, return 404 page or what else? The stability markers are primarily about request and response formats, and not about technical availability. Experimental end points can change at any time, which can result in errors (if the request interface changed), or return a different response format. We are currently discussing the use of `Accept` headers for response format versioning at https://www.mediawiki.org/wiki/Talk:API_versioning. This will allow us to more aggressively stabilize end points by giving us the option of tweaking response formats without breaking existing clients. > I am thinking if possible to use api.wikipedia as fallback, and use proxy > cache as primary source any ajax example for doing that to handle possible > failures? Yes, this is certainly possible. However, you can rely on end points currently marked as "unstable" in the REST API. Basically all of them are used by a lot of production clients at this point, and are very reliable. Once we introduce general `Accept` support, basically all of the unstable end points will likely become officially "stable", and several `experimental` end points will graduate to `unstable`. > 3# Does /rest/ endpoint exist also for other languages? Yes, it is available for all 800+ public Wikimedia projects at /api/rest_v1/. [1]: https://github.com/wikimedia/restbase/pull/488/files#diff-2b6b60416eaafdf0a… -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

2 3

Re: [Wikitext-l] [Mediawiki-api-announce] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Luigi Assom 29 Jan '16

29 Jan '16

Hi Gabriel! please read below comments, and remaining questions are: - how to extract _ID from ETag in headers: GET /page/title/{title} - how to ensure GET /page/title/{title with different char encoding or old titles are always resolved to last canonical version} [i registered this email after reply, sorry for eventual cross-posting] On Fri, Jan 29, 2016 at 6:42 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote: > Luigi, > > On Thu, Jan 28, 2016 at 2:09 AM, XDiscovery Team <info(a)xdiscovery.com> > wrote: > > I tried /rest_v1/ endpoint and it is terribly fast. > > that is great to hear. A major goal is indeed to provide high volume > and low latency access to our content. > > > @Strainu / @Gabriel , what does 'graph' extension do ? > > If you refer to > > https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_graph_png… > , > this is an end point exposing rendered graph images for > https://www.mediawiki.org/wiki/Extension:Graph (as linked in the end > point documentation). > Oh very interesting! So basically html markup can be extended ? Would it be possible to share json objects as html5 markup and embed them in wiki pages? > > > I have few questions for using proxy cache: > > 1# Is it possible to query a page by page_ID and include redirect? > > We don't currently provide access by page ID. Could you describe your > use case a bit to help us understand how access by page id would help > you? > > Oh yes! Thank you so much for asking. I've been working with complex networks and knowledge graphs; I can compute a knowledge graph for each dump, and match graph entities with wiki articles. Part of UX goes like this: - a user query my knowledge graph, click on entity A, I prompt the context of A, I query commons to decorate A by _ID(A). If I had to query wiki by title _TITLE(A), I run into these issues: #1 '*my title (could contain brackets or weird chars in other languages or in any case title could change @ any-time! )'* how to ensure is resolved to corresponding canonical page? # 2 *a page is named 'Dna' at time0; changed to 'DeoxRiboAcid' at time1; changed to 'DNA' at time2.* I want to avoid to update my graph just because titles changes: entities are always the same. So, assume I have titles dated at time0, how to ensure that a query will always land to last revisioned article at *timeN*? If I had to keep synced my graph, for how long old wiki titles will be validly resolved and not deleted? In general, for research project working with commons, I think that query by _ID is very much handy (thinking about all cases or oddities for not unicode chars, less exception to handle, portability to localise content..). > > /page/title/{title} > > allow to get metadata by page, including the pageID , but I would like to > > have final page redirect (e.g. dna return 7956 and I would like to fetch > > 7955 of redirected 'DNA' ) > > We are looking into improving our support for redirects: > https://phabricator.wikimedia.org/T118548. Your input on this topic > would be much appreciated. > > just did it! > > /page/html/{title} get the article but page_ID / curid is missing in > source > > I would like to get the two combined. > > This information is actually included in the response, both in the > `ETag` header and in the <head> of the HTML itself. I have updated the > documentation to spell this out more clearly in [1]. The relevant > addition is this: > > The response provides an `ETag` header indicating the revision and > render timeuuid separated by a slash (ex: `ETag: > 701384379/154d7bca-c264-11e5-8c2f-1b51b33b59fc`). This ETag can be > passed to the HTML save end point (as `base_etag` POST parameter), and > can also be used to retrieve the exact corresponding data-parsoid > metadata, by requesting the specific `revision` and `tid` indicated by > the `ETag`. > Sorry not clear to me! I still don't know what parsoid is. Please let me understand, how to I transform the ETag <meta property="mw:TimeUuid" content="56f23674-6252-11e5-a0b4-fd306fc438f5" /> into corresponding page_ID from a client? Should I do a second query? Should I pass another parameter? Is pageID encoded in ETag ? *Could you provide an example...?* > > > 2# The rest are experimental: > > what could happen if a query fail? > > Does it raise an error, return 404 page or what else? > > The stability markers are primarily about request and response > formats, and not about technical availability. Experimental end points > can change at any time, which can result in errors (if the request > interface changed), or return a different response format. > Among the two (end points and response format) I feel it most comfortably if the latter would not change that frequently or abruptly. > We are currently discussing the use of `Accept` headers for response > format versioning at > https://www.mediawiki.org/wiki/Talk:API_versioning. This will allow us > to more aggressively stabilize end points by giving us the option of > tweaking response formats without breaking existing clients. > Ok. > > > I am thinking if possible to use api.wikipedia as fallback, and use proxy > > cache as primary source any ajax example for doing that to handle > possible > > failures? > > Yes, this is certainly possible. However, you can rely on end points > currently marked as "unstable" in the REST API. OK. > Basically all of them > are used by a lot of production clients at this point, and are very > reliable. Once we introduce general `Accept` support, basically all of > the unstable end points will likely become officially "stable", and > several `experimental` end points will graduate to `unstable`. > > > 3# Does /rest/ endpoint exist also for other languages? > > Yes, it is available for all 800+ public Wikimedia projects at > /api/rest_v1/. > > Thank you.

1 0

Parsoid entrypoint http://parsoid-lb.eqiad.wikimedia.org being decommissioned
by Subramanya Sastry 29 Jan '16

29 Jan '16

Hello everyone, The public Parsoid endpoint http://parsoid-lb.eqiad.wikimedia.org is being decommissioned [1] once we migrate over all straggler references to that endpoint [1] possibly as soon as 3 weeks from now. As far as we know, there are very few requests to that endpoint right now, but if you have been using that endpoint, please switch over to using the RESTbase service instead. You can access Parsoid HTML for the wikimedia wikis via their REST API endpoint. For example, https://en.wikipedia.org/api/rest_v1/?doc is the REST API url for English Wikipedia content. Thanks, Subbu. 1. https://phabricator.wikimedia.org/T110474

1 0

query rest endpoint proxy cache
by Luigi Assom 28 Jan '16

28 Jan '16

Hello, I was not aware api.wikipedia are available in cached version ! I tried /rest_v1/ endpoint and it is terribly fast. https://wikimedia.org/api/rest_v1/?doc I have few questions for using proxy cache: *1# Is it possible to query a page by page_ID and return the resulting redirected page if necessary?* e.g.: /page/title/{title} allow to get metadata by page, including the pageID , but I would like to have final page redirect (e.g. dna return 7956 and I would like to fetch 7955 of redirected 'DNA' ) /page/html/{title} get the article but page_ID / curid is missing in source I would like to get the two combined. *2# The rest are experimental:* what could happen if a query fail? Does it raise an error, return 404 page or what else? I am thinking if possible to use api.wikipedia as fallback, and use proxy cache as primary source any ajax example for doing that to handle possible failures? *3# Does /rest/ endpoint exist also for other languages?*

1 0

Re: [Wikitext-l] [Engineering] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 25 Jan '16

25 Jan '16

On Mon, Jan 25, 2016 at 11:38 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote: > Will it apply to the pageviews API as well? It will, but the canonical URL for this has always been https://wikimedia.org/api/rest_v1/?doc, which will continue to work. Are you aware of any pageview users hitting rest.wikimedia.org? In any case, we'll check the logs for remaining rest.wikimedia.org accesses & make an effort to remind remaining users before decommissioning it. Gabriel

1 0

Re: [Wikitext-l] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 25 Jan '16

25 Jan '16

Strainu, On Mon, Jan 25, 2016 at 11:01 AM, Strainu <strainu10(a)gmail.com> wrote: > Hi, > > Does this apply to the Graph extension as well? the graph extension has been using /api/rest_v1/ right from the start, so it's likely that no changes are needed for graphs. Gabriel

1 0

CentOs 5 Install
by Bob Cohen 10 Jan '16

10 Jan '16

1 0

Storing stand-alone Parsoid data
by André Costa 06 Nov '15

06 Nov '15

I have some general Parsoid questions I hoped someone here might help me with. The background is that we are doing some preliminary work looking at how Text-to-Speech might work on Wikipedia (there will be some info online in the coming weeks). One detail of this is that you might occasionally have to highlight specific words/sentences that are dealt with differently (e.g. World War III -> World War 3). It is still unclear how frequent such things would be but if they are very frequent then there would likely be push-back from the community if this is stored in the normal wikitext. In this case we would have to store the markup outside of the wikitext and any viewing/editing of it would have to happen in some user enabled extension of the normal environment. And here we come to the question. 1. If we would have to store this markup outside of the wikitext could this be done by storing the individual parsoid-data-units? 2. Would it be possible to add these units to the existing parsoid-data (which gets loaded from the wikitext) when loading a page? 3. Would it be possible to detect which of these units would be affected by edits to the wikipage? This is still in the early stages so mainly we are looking at what possibilities exist should we need them. Using Parsoid data was something we thought of as a light-weight solution to having to store a synced copy of the wikitext+additional markup. Cheers, André André Costa | GLAM-tekniker, Wikimedia Sverige | Andre.Costa(a)wikimedia.se | +46 (0)733-964574 Stöd fri kunskap, bli medlem i Wikimedia Sverige. Läs mer på blimedlem.wikimedia.se

4 5

Get those small bugs fixed by new contributors: It's Google Code-In time!
by Andre Klapper 01 Nov '15

01 Nov '15

* Do you have small, self-contained, "easy" bugs you'd love to get fixed? (Also see https://www.mediawiki.org/wiki/Annoying_little_bugs ) * Does your documentation need improvements? * Do your old bugs welcome some testing? * Does your user interface have some small design issues? * Does the Outreachy/GSoC project you finished welcome small tweaks? * Would you enjoy helping someone port your template to Lua? * Does your gadget use some deprecated API calls? * Do you have some tasks that welcome some research? Google Code-In (GCI) will take place again in Dec+Jan: a contest for 13-17 year old students to provide small contributions to free software projects. Wikimedia will apply again to take part in GCI. The more tasks we can offer the likelier the changes Wikimedia will get accepted. Unsure about quality of contributions and effort? Read about tgr's post about Multimedia achievements in GCI 2014: https://lists.wikimedia.org/pipermail/multimedia/2015-January/001009.html In short: * Add the project "GCI2015" + a comment to Phabricator tasks you'd mentor. * Tasks are welcome in five areas: Code; Outreach/Research; Documentation/Training; Quality Assurance; User Interface. * Make sure the task description provides pointers to help the student. * Add yourself to the table of mentors on the wikipage. * "Beginner tasks" (<30 min for an experienced contributor) also welcome. * "Generic" tasks also welcome (e.g. "Fix two user interface messages from the "Blocked By" list in https://phabricator.wikimedia.org/T40638 "). For all information, check https://www.mediawiki.org/wiki/Google_Code-in_2015#Mentors.27_corner Can you imagine providing a helping hand to someone fixing tasks? Please ask if you have questions! Thank you! andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Re: [Wikitext-l] Wikitext-l Digest, Vol 53, Issue 3
by D F 16 Aug '15

16 Aug '15

What I mean is that the whole string ... {{inner1|...|???}} ... {{inner2|...|???}} ... {{inner17|...|???}} ... {{inner18|...|???}} ... is passed as the first argument of {{outer| ... |language}} instead of being hard coded in the template {{outer| ... |language}} since the first argument is not known in advance. Thanks, Daniel Forgues On Sun, Aug 16, 2015 at 5:01 AM, <wikitext-l-request(a)lists.wikimedia.org> wrote: > Send Wikitext-l mailing list submissions to > wikitext-l(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/wikitext-l > or, via email, send a message with subject or body 'help' to > wikitext-l-request(a)lists.wikimedia.org > > You can reach the person managing the list at > wikitext-l-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Wikitext-l digest..." > > > Today's Topics: > > 1. Re: Outer templates modifying inner templates' parameters in > nested template calls? (Arlo Breault) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 15 Aug 2015 15:30:56 -0700 > From: Arlo Breault <abreault(a)wikimedia.org> > To: Parsoid and wikitext discussion <wikitext-l(a)lists.wikimedia.org> > Subject: Re: [Wikitext-l] Outer templates modifying inner templates' > parameters in nested template calls? > Message-ID: <A99A5E66440D49C78EF7756667638071(a)wikimedia.org> > Content-Type: text/plain; charset="utf-8" > > On Monday, July 13, 2015 at 9:02 PM, D F wrote: > > Is there a way, or some hack, for an outer template to modify some inner > templates' parameters in nested template calls? For example: > > > > {{outer| ... {{inner1|...|???}} ... {{inner2|...|???}} ... > {{inner17|...|???}} ... {{inner18|...|???}} ... |language}} > > > > so that > > > > * if language = english, then ??? is replaced with en (before the inner > templates are called) > > * if language = spanish, then ??? is replaced with sp (before the inner > templates are called) > > > > This way, we only have to change the language parameter of the outer > template, and all the inner templates are called with the appropriate > parameter. (Instead of manually modifying the numerous inner templates.) > > > > I know that inner templates are called before outer ones. (This would > mean that the inner templates would execute with the ??? parameter, > returning something that would allow the outer template to modify the ???, > then the outer template would call back the inner templates with the > modified parameter, before the outer template finally does it's own thing > with the result. I don't know whether or not this could be hacked.) > > > Maybe I’m misunderstanding but you can pass template > parameters as arguments to nested templates. As in, > > /Page > {{aha|output=hello}} > > /Tempate:aha > {{echo|{{{output}}}}} > > /Template:echo > {{{1}}} > > The content of page will be “hello”. I used a named parameter > so that the example is clearer; that isn’t necessary. > > Hope it helps. > > > > > > Thanks > > > > Daniel Forgues > > _______________________________________________ > > Wikitext-l mailing list > > Wikitext-l(a)lists.wikimedia.org (mailto:Wikitext-l@lists.wikimedia.org) > > https://lists.wikimedia.org/mailman/listinfo/wikitext-l > > > > > > > ------------------------------ > > _______________________________________________ > Wikitext-l mailing list > Wikitext-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitext-l > > > End of Wikitext-l Digest, Vol 53, Issue 3 > ***************************************** >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Wikitext-l