Hi all,
I am working on this script
https://gerrit.wikimedia.org/r/#/c/138539/2/resources/js/ext.translate.spec…
for importing old translations into the Translation extension. To do so, I
have to create pages in the Translations namespace.
The function createTranslationPages() does that task. I was processing the
POST requests in a for loop previously but that was too many POST requests
in parallel and I get "MediaWiki-API-Error: badtoken" in the response
headers. So I thought of serializing it as per
https://www.mediawiki.org/wiki/API:Etiquette#Request_limit with a recursive
solution. However, the processing done inside the saveHandler() function
happens when the first POST request gets completed and does not wait for
all the requests to complete.
Nikerabbit has already commented inline, but I would like to know if this
issue has been faced before by someone over here and what is the best
solution for this. Thank you.
You can also help with suggestions at this pad:
http://etherpad.wikimedia.org/p/pm_serialize_post
--
Warm Regards,
*Pratik Lahoti*
GSoC Intern | Wikimedia
User:BPositive <http://www.mediawiki.org/wiki/User:BPositive>
Dear Brad,
Thank you very much. Most extensions are now showing all recent branches.
The following extensions, however, still have missing branches:
Elastica: most recent `origin/REL1_22', have `origin/wmf/1.24wmf8'
MobileApp: no `origin/REL1_xx', have `origin/wmf/1.24wmf8
Popups: no `origin/REL1_xx', have `origin/wmf/1.24wmf8'
TextExtracts: no `origin/REL1_xx', have `origin/wmf/1.24wmf8'
VectorBeta: most recent `origin/REL1_22', have `origin/wmf/1.24wmf8'
Wikidata: most recent `origin/REL1_22', `origin/mw1.24-wmf8'
Summarizing a different way:
No `REL' branches: MobileApp, Popups, TextExtracts;
No `REL1_23' branch: Elastica, VectorBeta, WIkidata; and
No `origin/wmf/1.24wmf8': Wikidata.
If these branches can be set automatically with each release at your end,
then I should be able to generate DEB packages automatically and post them
the next day.
Sincerely Yours,
Kent
> Date: Mon, 9 Jun 2014 10:54:44 -0400
> From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] [Pkg-mediawiki-devel] [MediaWiki-announce]
> MediaWiki 1.23.0 released
>
> On Sun, Jun 8, 2014 at 7:49 AM, wp mirror <wpmirrordev(a)gmail.com> wrote:
>
>> However, I notice that, for most MediaWiki extensions, when I execute:
>>
>> (shell)$ git branch -r
>>
>> the git repo does not (yet) show an `origin/REL1_23' branch that I can
>> checkout. While some extensions show a recent development branch such as
>> `origin/wmf/1.24wmf8', many extensions lag months behind (e.g.
`ApiSandbox'
>> has no branch more recent than `origin/wmf/1.23wmf20').
>>
>
> When I do "git branch -r" on a checkout of ApiSandbox,[1] I see both
> origin/REL1_23 and origin/wmf/1.24wmf8 branches exist.
>
> [1]: Either
> https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ApiSandbox.git
<https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ApiSandbox.git> or
> https://git.wikimedia.org/git/mediawiki/extensions/ApiSandbox.git
<https://git.wikimedia.org/git/mediawiki/extensions/ApiSandbox.git>, I
tested
> both.
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> Wikimedia Foundation
There is currently a proposal to make {{!}} a magic word that directly
outputs |, the pipe character, rather than calling Template:!. If your wiki
currently has Template:! set up to output a pipe, or if it doesn't have a
template called Template:!, then this change doesn't affect you. All of the
Wikimedia Foundation's wikis that have Template:! are currently using it
for this purpose, some with a few minor issues:
* https://bg.wiktionary.org/ has had their Template:! tagged for speedy
deletion (though not deleted) since 2012, although a pipe was its original
content. This currently renders {{!}} non-functional on this wiki, and this
change will cause it to become functional again.
* https://fi.wikiquote.org/, https://mk.wikibooks.org/, and
https://mk.wikisource.org/ all have extra whitespace alongside the pipe
character in Template:!, which is likely unintentional. This change will
cause the extra whitespace to not be used when {{!}} is used.
As of now, no WMF wikis need to make any further changes to prevent this
magic word from breaking anything. Any non-WMF wikis using {{!}} to produce
something other than a pipe character will have to move Template:! to a new
name and update all transclusions to point to the new name directly.
AutoWikiBrowser can be used to assist with this process if necessary. If
any of these wikis don't do this before upgrading to 1.24, pages using
{{!}} will render incorrectly until they do so.
See https://gerrit.wikimedia.org/r/#/c/136234/ for more details about this
proposed change.
Regards,
Jackmcbarn
C. Scott Ananian wrote:
>(As a brief plug: I would like to make
>WP feel more like an active community of *people* and less like a
>sterile collection of pages authored by some invisible cabal; from
>some previous threads about the "last edit" banner on mobile I'm sure
>there are some who prefer the anonymous font of knowledge look. But
>ultimately for real-time collaboration to be useful, a prospective
>editor needs to find someone to collaborate with...)
"Anonymous font of knowledge" isn't so bad. But there are other, larger
issues here that I'm not sure you're giving enough weight to.
We often don't want to attach ownership to content. It creates a lot of
problems when people do this on a wiki and I would argue that content
ownership is antithetical to the wiki model.
With something like the mobile site strapline, you're putting authorship
information at the top of the article's view mode. Putting your name at
the top of something is a fundamental and elementary means of indicating
ownership of something (cf. any school assignment or research paper).
(Trying to explain to a celebrity or other personality why they can't edit
the article about themselves, when it has their name on the article, is
another facet to the problem of ownership and explaining ownership.)
Knowing the last modified timestamp can be useful, but the implementation
is weak. It's currently trivial for the last modified date to be
manipulated by a page protection or simple vandalism and a subsequent
reversion. This leads to an article that hasn't really been edited in
three years saying "last edited 1 day ago", which is disingenuous and
misleading.
Knowing the last contributor can be useful, but it opens up an attack
vector which people have already been exploiting using vandalistic
usernames. It's also pretty weak to see "last edited by [some random bot
doing the job that MediaWiki fails to do such as category renaming]".
While the information displayed is often technically accurate, you start
to see diminishing value of the signal. The metadata starts to seem more
like noise.
And, yes, I talk to lots of editors every month and anecdotally many of
them would prefer not to have their usernames plastered at the top of
articles. I'm not sure this is unreasonable.
MZMcBride
Hi,
requests matching
http://\(es\|pt\).wikipedia.org/wiki/[dD]ata:image/png;base64,iVBORw0K.*
are on the increase. Currently, ~500K/day.
I cannot make sense of those requests, and they look wrong, as they
seem to be a data URI appended to the a proper URL [1].
Corresponding bug is 66112 [2].
The requests' User-Agent identifies them as Firefox and Chrome, both
on various flavors of Windows.
It's not ancient browsers, as the biggest part identifies as
Firefox 29 (~60%) and Chrome 35 (~31%).
It does not seem to be simple bots faking User-Agents, as the number
of requests shows a strong weekly pattern and the Client IPs match
countries for the target wikis, and the IPs themselves differ a
lot—covering 200-500 /24 nets per day in sampled-1000 stream.
Requests go to desktop site of eswiki (~58%) and ptwiki (~38%).
Referrers are mostly empty (~97%).
The image data in the data uri scheme decodes to images from
VectorBeta [3] like:
VectorBeta/resources/typography/images/search-fade.png
VectorBeta/resources/typography/images/tab-break.png
VectorBeta/resources/typography/images/tab-current-fade.png
VectorBeta/resources/typography/images/portal-break.png
Any clues?
Is this issue on our end or can for example rogue User-JS amount for
that many skew requests?
Have fun,
Chrisitan
P.S.: On stat1002, there are TSVs from the sampled-1000 stream
filtered to the relevant requests for May and June at
/home/qchris/data-uris
.
[1] Since they are just UI images, here are some concrete examples:
http://es.wikipedia.org/wiki/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…http://pt.wikipedia.org/wiki/Data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…http://es.wikipedia.org/wiki/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…http://es.wikipedia.org/wiki/Data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=66112
[3] But that's not to say that it's a VectorBeta issue. It might be
for example our (or User-)JS walking DOM and firing off strange
requests.
--
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65a Email: christian(a)quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax: +43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---------------------------------------------------------------
Hi, in response to bug 54607 [1], we've changed the semantics of the
mobileformat parameter to action=parse
== Summary ==
Previously, it used to accept strings 'html' or 'wml', later just
'html' and modify the structure of output (see below). This was problematic
because you needed to retrieve the HTML from output in different ways,
depending on whether mobileformat is specified or not. Now,
mobileformat is a boolean parameter, that is if there's a 'mobileformat'
parameter in request, it will be treated as "the output should be
mobile-friendly", regardless of value. And the output structure will
be the same. For compatibility with older callers,
mobileformat=(html|wml) will be special-cased to return the older
structure at least for 6 month from now. These changes will start
being rolled out to the WMF sites starting from tomorrow, Tuesday
October 24th and this process will be complete by October 31st.
== Examples ==
=== Non-mobile parse ===
api.php?action=parse&format=xml
{
"parse": {
"title": "...",
"text": {
"*": "foo"
}
}
}
api.php?action=parse&format=json
<?xml version="1.0"?>
<api>
<parse title="..." displaytitle="...">
<text xml:space="preserve">foo</text>
</parse>
</api>
=== Parse that outputs mobile HTML, old style ===
api.php?action=parse&format=json&mobileformat=html
{
"parse": {
"title": "API",
"text": "foo"
}
}
api.php?action=parse&format=xml&mobileformat=html
<?xml version="1.0"?>
<api>
<parse title="..." text="foo" displaytitle="...">
</parse>
</api>
=== Parse that outputs mobile HTML, new style ===
api.php?action=parse&format=...&mobileformat
Same as for non-mobile parses.
== FAQ ==
Q: I didn't use mobileformat before, does anything change for me?
A: No.
Q: I use mobileformat=html, will my bot/tool be broken now?
A: No, you will have 6 months to switch to new style.
Q: I'm only planning to use mobileformat, what should I do?
A: Just use the new style.
Q: How did this format discrepancy appear in the first place?
A: To err is human.
-----
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=54607
--
Best regards,
Max Semenik ([[User:MaxSem]])
On 06/02/2014 08:16 PM, Steven Walling wrote:
> GuidedTour's backend has also undergone a major refactor, which is close
> to being merged. This is described in full at the commit, which is just
> waiting on us to update logging: https://gerrit.wikimedia.org/r/#/c/116228/
As Steven noted, you should not have to change your code using the old
API immediately. However, we hope you will see a benefit to the new
API, in flexibility, new features, and readability.
We are polishing the API and finishing final testing. The documentation
for the upcoming API is available at
http://growthdoc.wmflabs.org/NonLinearGuidedTourPreview/ (this URL is
temporary), so if you think something could be clarified or tweaked,
please let us know.
The basic idea of the new API is that you start by constructing a
TourBuilder. From that, you construct StepBuilder objects by calling
firstStep (for the entry point)
(http://growthdoc.wmflabs.org/NonLinearGuidedTourPreview/#!/api/mw.guidedTou…)
or step
(http://growthdoc.wmflabs.org/NonLinearGuidedTourPreview/#!/api/mw.guidedTou…)
for other steps.
Steps
(http://growthdoc.wmflabs.org/NonLinearGuidedTourPreview/#!/api/mw.guidedTou…)
can listen for events, which can then trigger a transition to another
step, hide the tour, or end it. This is controlled by .transition()
(http://growthdoc.wmflabs.org/NonLinearGuidedTourPreview/#!/api/mw.guidedTou…).
.next() sets the next step, which can also be dynamic.
The details are covered by the API documentation; I just wanted to give
a broad overview.
The old API is deprecated, and will not be maintained permanently (we
will keep you updated on any plans to remove it).
Matt Flaschen
> [weighing in on the nesting/quoting bikeshed: the structured quoting
> which Simple Machines Forum (SMF) provides is a nice compromise: it
> preserves the exact origin of the quoted material, for easy
> backreference, but it also allows flexible editing of the quoted
> content and for combining multiple quotations into a single response.]
Clearly the whole thing should be started over using Xanadu [1] :)
[1]
http://www.theguardian.com/technology/2014/jun/06/vapourware-software-54-ye…
Hi,
we are going to have another IRC office hour about the migration to
Phabricator: https://www.mediawiki.org/wiki/Phabricator
in #wikimedia-office on irc.freenode.net
on June 17, 2014 (Tuesday) at 17:30 UTC
We will quickly present the status, progress, open issues.
And we are happy to answer your questions!
See you at the IRC office hour!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/