Dear all,
is there an API for extraction the previous section title from a wikipage?
My situation is the following. I have a wikipage that looks like that:
<page>
intro
==section1==
text
<math id=1>...</math>
text
<math id=2>...</math>
===section 2===
text
<math id=3>...</math>
</page>
And I want to know the previous section title for each math object in that page
1->section1
2->section1
3->section 2
It's certainly doable to write a program that extracts that that
information from the wikipage... but I guess seldom special cases
would cause a lot of long tail trouble.
So is there a API that could be used for that. Both parsoid or the old
regular parser works for me.
Best
Physikerwelt
Hi what about merging Extension:Update in core of mediawiki the extension is at https://www.mediawiki.org/wiki/Extension:Update and tells the user when there is an update to mediawiki and extension it is useful.
MZMcBride wrote:
>We have two requests for comment indices on mediawiki.org:
>
>* https://www.mediawiki.org/wiki/Requests_for_comment
>* https://www.mediawiki.org/wiki/Requests_for_comment/Archive
>
>The current system requires manually updating the various lists, which is
>kind of gross as the lists predictably fall out of date. I've proposed and
>begun to implement a classification scheme that will allow us to automate
>the generation of these indices. Details of this scheme are available
>here: <https://www.mediawiki.org/wiki/Special:Permalink/1315007#Cleanup>.
>
>One consequence of this change is that the "Updated" and "Status" table
>columns will likely go away soon. Looking at the contents of these table
>columns, I think ditching them is probably fine.
This is now done. We simplified the RFC infobox template to use a single
status parameter and all of the requests for comment should now be coded.
I added a few lines of JavaScript to
<https://www.mediawiki.org/wiki/MediaWiki:Gadget-site.js> to hide the
"Requests for comment/" prefix. Code review and optimization very welcome.
MZMcBride
It looks like the Purge extension
<https://www.mediawiki.org/wiki/Extension:Purge> for MediaWiki could be
very useful to replace many similar gadgets on Wikimedia sites.
New users often need to purge the server cache, and don't know how to do it.
A simple link is way more helpful than "visit the history page and
replace 'history' with 'purge'", etc.
Also, a server-side extension has much better i18n support and works
without JavaScript.
Is anyone interested in getting it in?
<https://www.mediawiki.org/wiki/Extension:Purge>
On 10.12.2014 15:30, Jonathan Aquilina wrote:
> Hey guys reading through some of these tasks, I am wondering has the wiki
> media foundation taken into account mobile devices and started taking media
> wiki down a mobile friendly path through using bootstrap etc?
They are a dozen of tasks (mostly for beginners) related to Kiwix for
Android.
Emmanuel
--
Kiwix - Wikipedia Offline & more
* Web: http://www.kiwix.org
* Twitter: https://twitter.com/KiwixOffline
* more: http://www.kiwix.org/wiki/Communication
I've just deployed the ApiFeatureUsage extension to Beta Labs for testing.
If an API client (e.g. a bot or a user script) sets a unique User-Agent or
Api-User-Agent header, a summary of deprecated API features hit by that
client may be fetched from Special:ApiFeatureUsage[1] or from the API
itself.[2]
Please try it out, and report any issues in Phabricator using the
MediaWiki-extension-ApiFeatureUsage project. If things look good after
testing I'll be looking at getting it deployed to production in the next
month or so.
[1]: http://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiFeatureUsage
[2]:
http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=query+fe…
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Since https://gerrit.wikimedia.org/r/#/c/180811/ is now merged, the old
WikiGrok suggestion data is now obsolete. You'll want to delete the old
entries in your wikigrok_questions table and replace them with new ones.
The specific changes are that the format version number (wgq_version) has
changed from 1 to 2, and the data property in wgq_data called 'property'
has been split into 'propertyId' and 'propertyName'. See
https://www.mediawiki.org/wiki/Extension:MobileFrontend/WikiGrok#Assign_sug…
for an example of the new data format.
Kaldari
Hallo,
The second most popular tempate in the Hebrew Wikipedia is one that inserts
the rlm character[1]. It has an optional parameter. If it's used, it
inserts the lrm character instead. The condition runs in every transclusion.
Running a condition every time seems to me like an unnecessary thing,
especially that the parameter is (probably) not used most of the time. It
could be avoided by replacing all the instances where that parameter is
used by another template that simply inserts the lrm. But maybe it's not
actually needed because MediaWiki's caching avoids the performance problem?
I'm not much of a performance person, so I'd like the experts' opinion.
Thanks.
[1] https://en.wikipedia.org/wiki/Right-to-left_mark
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
I am experimenting with catching Javascript errors with raven.js [1] (see
the JS error logging RfC [2] for background; see T1345 [3] for a prototype
for JS error logging). For various reasons, Javascript does not have a
reliable way to install a global exception handler like e.g. PHP does with
set_exception_handler(), so the standard way of doing this is to wrap
modules into a try-catch block.
ResourceLoader already wraps minified scripts with something like
mw.loader.implement( "<module name>", function() { <module code> } );
so this could be changed to something like
mw.loader.implement( "<module name>", Raven.wrap( function() { <module
code> } ) );
That means that the error logging module would have to be loaded by the
time other modules are initialized, so I imagine it would have to become a
startup module. My questions are:
1. do you see any problems with such a setup? The eventual goal would be to
use this on the Wikimedia production cluster.
2. especially, is adding another startup script acceptable? (Adding
raven.js to the jquery and mediawiki modules would mean a ~10% size
increase.)
3. what would be the proper way of doing this from an extension? Add two
new hooks for module wrapping and for defining additional startup modules?
[1] https://github.com/getsentry/raven-js
[2]
https://www.mediawiki.org/wiki/Requests_for_comment/Server-side_Javascript_…
[3] https://phabricator.wikimedia.org/T1345