Hi all!
Wikidata (technically, Wikibase) uses a lot of JS/API based editing, and we have
several times hit upon the question of how to best report errors from the API.
I'll try to break the issue down into several concrete questions. But first off,
the status quo as I understand it:
* errors are reported using an error code (a string) and a free form error
message. The message is usually not internationalized, though sometimes it is.
* warnings are reported as free form text.
* Additional information can be added to both errors and warnings, but there is
no standard way to do this.
* Errors exposed by the API are often not generated but just passed through by
the API; Typically, a generic error code is used with the original error message
(e.g. from an exception).
So, here are my questions:
* Should error messages returned by the API be translated? Or should the
translation be left to JavaScript in the client?
** In both cases, it would be nice to have a consistent relationship between
error codes and the corresponding system message.
** If translation is done on the client, we need to pass any message parameters
separately.
** The message key would have to somehow be derived or mapped from the error code.
* When using system messages to translate the error codes from the API, these
messages will often contain wikitext. How can we best avoid this? Wikitext is
likely to be quite useless to the client - it would be better to return HTML; or
pass all the message keys and parameters, and let the client generate the message.
* Status objects are often used to collect errors and warnings the occur while
trying to perform some task. It would be nice if the API would provide a
standard way to put the contents of a Status object into the result (well, at
least the errors and warnings).
Any thoughts on that?
-- daniel
A few days ago I have noticed that Selenium[1] can now drive PhantomJS[2],
"a headless WebKit with JavaScript API". Intrigued by the buzzword to word
ratio I have decided to take it for a test drive.
# Test Drive
If you are on a Mac (and use Homebrew), installation is as simple
as possible:
$ brew update && brew install phantomjs
(You will need Ruby for this part.)
$ irb
> require "watir-webdriver"
=> true
> browser = Watir::Browser.new :phantomjs
=> #<Watir::Browser:0x..f96d67ac99e7fe7c6 url="about:blank" title="">
> browser.goto "google.com"
=> "http://www.google.hr/"
> browser.screenshot.save 'screenshot.png'
=> #<File:screenshot.png (closed)>
Saving screenshots from a headless browser. Wat?[3]
A bit of unscientific research (just a few test runs) follows. We have two
repositories with Selenium tests, browsertests[4][5]
and MobileFrontend[6][7].
# browsertests
I had to fix a few things and I could not get a few tests to run[8][9][10].
I did not want to spend a lot of time on it, there were still a lot of
tests that were running just fine.
$ export BROWSER_LABEL=firefox
$ bundle exec cucumber --tags ~@phantomjs-bug
Using the default profile...
18 scenarios (18 passed)
100 steps (100 passed)
5m35.491s
$ export BROWSER_LABEL=chrome
$ bundle exec cucumber --tags ~@phantomjs-bug
Using the default profile...
18 scenarios (18 passed)
100 steps (100 passed)
3m37.241s
$ export BROWSER_LABEL=phantomjs
$ bundle exec cucumber --tags ~@phantomjs-bug
18 scenarios (18 passed)
100 steps (100 passed)
1m53.282s
For some reason tests always fail on phantomjs when I run them in parallel,
even if only two browsers are open at the same time. I did not notice that
with mobilefrontend tests. I will investigate it next week.
# MobileFrontend
$ export BROWSER_LABEL=firefox
$ time bundle exec rake serial
real 0m56.888s
$ time bundle exec rake parallel
real 1m9.035s
$ export BROWSER_LABEL=chrome
$ time bundle exec rake serial
real 1m18.420s
$ time bundle exec rake parallel
real 1m9.510s
$ export BROWSER_LABEL=phantomjs
$ time bundle exec rake serial
real 0m47.956s
$ time bundle exec rake parallel
real 0m10.521s
I had to make just one line change to make all tests run in PhantomJS[11].
Does this sound interesting? Join the weekly QA/testing event on February
11[12] and I will teach you all you need to know.
Can not wait until February 11? Just reply here or send me an e-mail
message. IRC is fine too, just ping zeljkof.
Željko
--
[1] http://seleniumhq.org/
[2] http://phantomjs.org/
[3] http://knowyourmeme.com/memes/wat
[4] https://gerrit.wikimedia.org/r/#/admin/projects/qa/browsertests
[5] https://github.com/wikimedia/qa-browsertests
[6]
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Mobile…
[7] https://github.com/wikimedia/mediawiki-extensions-MobileFrontend
[8] https://gerrit.wikimedia.org/r/#/c/45737/
[9] https://gerrit.wikimedia.org/r/#/c/45738/
[10] https://gerrit.wikimedia.org/r/#/c/45765/
[11] https://gerrit.wikimedia.org/r/#/c/45182/
[12] https://www.mediawiki.org/wiki/QA/Weekly_goals
Hi,
On Fri, Jan 18, 2013 at 3:24 PM, Guillaume Paumier
<gpaumier(a)wikimedia.org> wrote:
>
> More generally, and to follow up on our discussion yesterday about
> better coordination, I think I'd like to integrate that kind of
> announcements into a central page on mw.o that would also list Tech
> chats, tech-related IRC office hours, QA testing sessions, upcoming
> deployments, etc.
>
> The goal would be both for us and for contributors to have a clearer
> view of what's coming up. I may take a stab at a
> [[mw:Project:Calendar]] next week and transclude part of it into
> [[mw:How to contribute]].
So, I've done this: https://www.mediawiki.org/wiki/User:Guillom/sandbox
For now, it only contains content taken from [[Events]] and the
"testing/bugs wheel". I'm fairly happy with functionality and looks,
and I think we can start using it and adding more events.
The information is centralized on that page, but using LST, it's also
possible to selectively pull information from it to display on
topic-specific pages. See
https://www.mediawiki.org/wiki/User:Guillom/sandbox2 for examples.
There is probably room for improvement; feel free to add to the talk
page or the #Todo section. If [[wikia:uncyclopedia:Nobody cares]],
I'll move this to the proper place and I'll start transcluding its
content.
PS: For those interested, there's some doc at
https://www.mediawiki.org/wiki/Template:Event
--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
https://donate.wikimedia.org
There are ongoing separate discussions about the best way to organize
testing sprints and bug days. The more we talk and the more we delay the
beginning of continuous activities the more I believe the solution is
common for both:
Smaller activities and more frequent. Each one of them less ambitious
but more precise. Not requiring by default the involvement of developer
teams. Especially not requiring the involvement of WMF dev teams.
Of course we want to work together with development teams! But just not
wait for them. They tend to be busy, willing and at the same time
unwilling (a problem we need to solve but not necessarily before
starting a routine of testing and bug management activities. If a dev
team (WMF or not) wants to have dedicated testing and bug management
activities we will give them the top priority.
Imagine this wheel:
Week 1: manual testing (Chris)
Week 2: fresh bugs (Andre)
Week 3: browser testing (Željko)
Week 4: rotten bugs (Valerie)
All the better if there is certain correlation between testing and bugs
activities, but no problem if there is none.
From the point of view of the week coordinators this is how a cycle
would look like:
Week 1: decide the goal of the next activity.
Weeks 2-3: preparing documentation, recruiting participants.
Week 4: DIY activities start. Support via IRC & mailing list.
Group sprint on Wed/Thu
DIY activities continue.
Week 4+1: Evaluation of results. Goal of the next activity....
During the group sprints there would be secondary DIY tasks for those
happy to participate but not fond of the main goal of the week.
If one group needs more than one activity per month they can start
overflowing the following week, resulting in simultaneous testing & bugs
activities.
Compared to the current situation, this wheel looks powerful and at the
same time relatively easy to set up. There will plenty of things to
improve and fine tune, but probably none of them will require to stop
the wheel.
What do you think?
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
The king is dead. Long live the king!
Begin doorgestuurd bericht:
> Van: demon(a)svn.wikimedia.org
> Datum: 25 januari 2013 17:49:02 CET
> Aan: mediawiki-cvs(a)lists.wikimedia.org
> Onderwerp: [MediaWiki-commits] SVN: [115794] GOODBYE
> Antwoord aan: wikitech-l(a)lists.wikimedia.org
>
> https://www.mediawiki.org/wiki/Special:Code/MediaWiki/115794
>
> Revision: 115794
> Author: demon
> Date: 2013-01-25 16:49:01 +0000 (Fri, 25 Jan 2013)
> Log Message:
> -----------
> This is the way the world ends: Not with a bang but a whimper.
>
> Added Paths:
> -----------
> GOODBYE
>
> Added: GOODBYE
> ===================================================================
> --- GOODBYE (rev 0)
> +++ GOODBYE 2013-01-25 16:49:01 UTC (rev 115794)
> @@ -0,0 +1,3 @@
> + So long S-V-N
> + You have served us well for years
> + Look, now we use Git!
>
>
> _______________________________________________
> MediaWiki-commits mailing list
> MediaWiki-commits(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-commits
Hi all,
I've been taking a look at the SVN history[0], and it doesn't look like
anything is actively using SVN anymore. Looking at the logs, it doesn't
look like much of anything has been committed in the last few months
that hasn't since been moved to Git (in Gerrit or elsewhere). This being
said:
I'm going to mark all of the MediaWiki SVN repository as read-only
tomorrow, Jan. 25th.
Note this won't make anything in SVN go away, as we're still committed
to leaving the SVN repositories available in a read-only manner. This
also doesn't prevent us from converting extensions or other code to
Git if someone decides to resurrect a project. Finally, this does not
affect the Wikimedia repository, which still has a couple of active
projects.
-Chad
[0] http://www.mediawiki.org/wiki/Special:Code/MediaWiki
Hi,
There's been a lot of bikeshedding topics recently. On things ranging
from spaces, to typos, to naming things. I was kind of tired of these
mundane threads, so I decided to start one on something productive.
What color should the bikeshed be?
I vote blue.
-Chad
Hi,
last night i finally made the switch to the new planet software.
http://wikitech.wikimedia.org/view/Planet.wikimedia.org
----
== What is planet? ==
An RSS feed aggregator. See [[meta:Planet_Wikimedia]] for details.
== How do i access it? ==
http://en.planet.wikimedia.org/ and several other languages,
*.planet.wikimedia.org.
== New planet (planet-venus) ==
On Jan,23rd 2013 we switched from the
[http://wikitech.wikimedia.org/index.php?title=Planet.wikimedia.org&oldid=25…
old planet] (http://www.planetplanet.org/) to
the new planet-venus (http://www.intertwingly.net/code/venus/)
=== What's better about the new planet? ===
#It's packaged in Ubuntu.
([http://packages.ubuntu.com/km/lucid/python/planet-venus
planet-venus]), the old planet was not packaged.
#It's fully [https://gerrit.wikimedia.org/r/#/q/project:operations/puppet+topic:planet+s…
puppetized], the old planet was all manual.
#It uses [[git]]. People adding feed URLs can just send [[Gerrit]]
patchsets. The old planet used SVN.
#It's a complete rewrite of the old code in Python. It uses more
modern technology like html5lib, Atom, XSLT and templates.
#..
== What may not be better about the new planet (yet)? ==
#The "gmq" planet, which is a combo of Scandinavian languages does not
have separate index pages in each language yet.
#Some CSS/layout/design issues, like localized logo in Arabic or
right-to-left alignment of thumbnails. (Arabic does already use a
separate CSS file though and has the sidebar on the right hand side)
#It does not include iframes (this might be considered a good thing though)
== Where should i report issues? ==
On Bugzilla.
== Where does it run? ==
On [[zirconium]] in [[eqiad]]. The old planet was on [[singer]].
== Where's the code? ==
In git, in the operations/puppet repo:
#./manifests/role/planet.pp
#./manifests/misc/planet.pp
and
#git clone https://github.com/rubys/venus.git
== How do i add/remove feed URLs? ==
#[https://labsconsole.wikimedia.org/wiki/Git#Git.2FGerrit_and_the_repositories
Clone] the operations/puppet git repository.
#go to ./puppet/templates/planet/ and edit one of the
<language>_config.erb files
#submit to gerrit and have somebody merge it
== How do i change HTML of the index pages? ==
#see above, edit ./puppet/templates/planet/index.html.tmpl.erb
== How do i add/change translations in the index pages or add a new language? ==
#see above, edit ./puppet/manifests/role/planet.pp (find $planet_languages=...)
== How do i request changes if i can't or don't want to submit a
change set myself? ==
Ask on [[meta:Planet_Wikimedia#Requests_for_Update_or_Removal]]
== Are there more general docs on planet-venus and it's architecture? ==
Sure, see [http://www.intertwingly.net/code/venus/docs/index.html
docs] and [http://www.intertwingly.net/code/venus/docs/venus.svg
venus.svg].
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
Hi, back in November Erik and Sumana explained the intention of the WMF
to get less involved in the direct organization of developer events.
Instead, the WMF will empower and help community groups taking the lead
organizing developer activities.
http://lists.wikimedia.org/pipermail/wikimedia-l/2012-November/122725.html
In practice, this means that those events are run more in a
franchise-like mode (sorry for the commercial word: I'm using it to
illustrate the point). As we can learn from the franchise model, the
more complete is the documentation and the more standardized is the
process, the easier it is for a local promoter to setup and activity on
their own and succeed. Local successes help the global success, and
global success helps local successes.
Ok, now back to our reality. :)
The first element of an event is its name, and already there we have
room for improvement.
Proposal: naming all our developer events
MediaWiki Hackathon City
e.g. MediaWiki Hackathon Amsterdam, to mention an event currently
showing a branding problem:
https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013
Localizations and exceptions to be considered and approved one by one.
The problem, in more detail:
- We seem to have an erratic use of "Wikipedia", "Wikimedia",
"MediaWiki", [choose your logo] and [nothing] for naming these events.
For instance, see the web pages of "San Francisco Hackathon" "Berlin
Hackathon" or "Amsterdam Hackathon" and try to find the full name
written down. The pictures show that creative, inconsistent solutions
were found for the banners. This makes no sense for the outsiders we
want to reach.
- We seem to use "Hackathon" always but then Bangalore was a "DevCamp".
It is useful to settle in one word, unless the event is something
completely different.
- Some events specify the date in their name, some don't. There is no
need to specify the month-year in the name of the event since any event
has a date anyway. This allows us to recycle and update web pages,
archiving properly past events. URLs stay and they become stronger. You
can find an extreme example of this problem in Wikimania where (up to
date) every year there has been a new URL, a new Twitter account, etc.
Let's avoid this problem at least in our context.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
There are reports everywhere of uploading new versions of images failing
(upload works but new version does not show up).
Last time this happened all that needed to be done was fot varnishhtcpd to
be restarted on the image cache servers. [1] could someone with the ability
to check, check if that needs to be done again? Imho this type of issue is
a rather serious one which causes lots of frustration and confusion.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=41130
-bawolff
