I've just updated https://www.mediawiki.org/wiki/Mailing_lists and
https://meta.wikimedia.org/wiki/Mailing_lists/Overview#Mediawiki_and_techni…
. Sorry for the spam, but you really should take a moment to skim and
see whether there are lists there you should join. I especially want to
single out:
design
mediawiki-api-announce
mediawiki-i18n -- localisation and internationalisation
labs-l -- for when you have a question or request re Wikimedia Labs
analytics
wikitext-l -- the new Visual Editor & parser
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Hey,
I got a unit test (added here: https://gerrit.wikimedia.org/r/#/c/14870/)
causing some error which I can't figure out the cause of.
The error is "Error: 1137 Can't reopen table: 'unittest_smw_ids'", full
message here: http://dpaste.org/B2npZ/
Anyone an idea what might be going on?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
The Lua extension (Scribunto) is now enabled on test2wiki.
Feedback would be greatly appreciated, especially if it comes in the
form of bug reports and feature requests filed in the "Scribunto"
component in Bugzilla.
<https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…>
-- Tim Starling
Hi all
Here's a quick update on what has been happening with Wikidata.
After I was off duty last week, I have picked up work on the Wikidata branch
again (aka the ContentHandler stuff). Discussion is happening mostly on Bugzilla:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38622
I have tried to address several of Tim's concerns, and will hopefully wrap up
the lose ends early next week. Here's the Gerrit log:
https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:Wikidata,n…
While I'm still working on this, I'm very much welcoming any comments, reviews,
criticism, whatever. Please look at the code and let me know what you think!
Other than that, there's the ungoing discussion about a new system for managing
interwiki/linterlanguage link targets. The RFC is here:
https://www.mediawiki.org/wiki/Requests_for_comment/New_sites_system
Here, too, we are working on it, but more comments are still encouraged.
Thanks
Daniel
My GSoC project was developing a program for uploading
Wiki Loves Monuments photos to Wikimedia Commons [1]
Timing seemed great, chaining the end of my previous task
with the beginning of GSoC and the end of GSoC with WLM 2012.
Maybe it would be a little adjusted at the beginning, but
not being a too exigent GSoC project, there would be plenty
of time for completion. Or so I thought.
The work in the Real World delayed, pushing down the Google
Summer of Code, which by its own nature had lower priority.
I also made another appreciation error when considering how
much I would advance with a "foreign" computer.
I ended up sprinting the last days to get a deliverable by
the deadline, something that seemed impossible at times,
while I was regretting signing up.
I should also talk about my relationship with my mentor,
but it was pretty much non-existant. With little to no
advance to report, I wasn't motivated to contact her, and she
was too busy with other duties to contact me. So we failed
from both sides. :( I'd love to work with her in the future,
but under different conditions. In the given circumstances,
I feel it was an error for her to accept me as student.
The mentor slot should have been assigned to someone else.
Had a student new to mediawiki, with a project needing
more support, received this level of mentoring, I doubt
he could have finished / it would have been a mergeable result.
OTOH, if someone was going to receive this, I guess I wasn't
that a bad election. :/
Despite the smashed planification, results weren't too bad.
I completed a prototype [2], which implements the core
functionality, asking the user all the needed information and
performing the uploads. It misses one dialog, and has the big
drawback of not being internationalised: the application is
hardcoded in the mixture of languages I used (for distributing
as mockups) when developing.
I had envisioned a translation method which involved making
a new translatewiki backend, but it was clear pretty soon that
translations would need to stay out of the 'release'.
Another point I had planned that was not fullfiled was
preference-handling and load/save of sets of monuments. All
preferences are hardcoded right now. Those are easy to add,
though.
Currently, the program has a functionality similar to the Upload
Wizard, in that you need to be online to work with it. However,
I feel it is superior in the usecase of uploading a full folder,
both in selecting and preparation (plus uploading in the background
while preparing new files). I plan to slowly be adding -outside
of GSoC- some of those missing features and dealing with the
(previsible) feedback.
Although short of time due to the above mentioned issues,
it was refreshing to do some C++ coding. I had only worked with
dynamic languages recently, or with lower-level C. C++ provided
enough class magic to make for comfortable coding, with enough
pointers to crash your program (and a framework complex
enough to discard valgrind usage) :)
I was disappointed with wxWidgets HTTP support, though. There
were a couple of problems I had to overcome by myself and had to
patch a third one on the library.
I have uploaded at [2] the source, windows and linux binaries.
Everyone is welcome to play with them and test the application.
Following the lead of the mobile team with beta uploading,
those binaries upload to http://test.wikipedia.org/ instead
of Wikimedia Commons. It doesn't have many of the commons
templates the program expects (you can preview in Wikimedia
Commons if you wish), but it doesn't disrupt the project.
Best regards
1- http://thread.gmane.org/gmane.org.wikimedia.wikilovesmonuments/2641
2- http://toolserver.org/~platonides/sube/
I get the feeling sometimes that either mailman or Outlook completely
ignores
where I am putting my line breaks and put them wherever it pleases.
The last email I sent I started a line with "> defended" which when I
received
the email from the list had instead "> community defended" with some rather
strange looking mid-sentence, nowhere close to 100 char, line breaks.
Do my emails look terrible to anyone else? Has anyone else had this problem
before? Do anyone know the solution?
I know that this sort of thing is usually out of scope on this list, but I
felt
it was appropriate here because if my emails look just as bad to all of you,
then it is probably terribly annoying.
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
On 23.08.2012 22:49, Brion Vibber wrote:
> Well, the main reason is probably that MySQL doesn't support nested
> transactions... trying to simulate them with a counter sounds fragile, as a
> single rollback would roll back the entire transaction "tree", not just the last
> nested one you started (or else do nothing if you just decrement the counter,
> also possibly dangerous if you expected the rollback to work).
To me it seems correct and safe to assume that a ROLLBACK will cause all open
transactions to fail. I don't see any problem with handling things this way. Am
I missing something? Was there any *concrete* problem that caused this feature
to be removed?
On 23.08.2012 23:21, Brion Vibber wrote:
> On Thu, Aug 23, 2012 at 2:02 PM, Evan Priestley <epriestley(a)phacility.com>wrote:
>
>> We solve this in Phabricator by using BEGIN (depth 0) or SAVEPOINT (depth
>> 1+) when incrementing the counter, ROLLBACK TO SAVEPOINT (depth 1+) or
>> ROLLBACK (depth 0) when decrementing it after a failure, and nothing (depth
>> 1) or COMMIT (depth 0) when decrementing it after a success. Our experience
>> with transaction stacks has generally been good (no real surprises, doesn't
>> feel magical, significantly reduces the complexity of transactional code),
>> although we don't support anything but MySQL.
>>
>
> Oooh, nice! Hadn't come across SAVEPOINT before.
>
> http://dev.mysql.com/doc/refman/5.0/en/savepoint.html
Hm... that'S a 404 for me. For some reason, this is missing in the 5.0 manual,
even though it exists in 4.1 and 5.1:
http://dev.mysql.com/doc/refman/5.1/en/savepoint.html
Anyway, this seems like a neat solution if it is handled automatically by
begin(), rollback() and commit(), so the calling code doesn't have to be aware
of the current transaction level.
I'm tempted to implement this. Any objections?
-- daniel
PS:
--
Daniel Kinzler, Softwarearchitekt
Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de | Tel. (030) 219 158 260
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt
für Körperschaften I Berlin, Steuernummer 27/681/51985.
Hi,
As a volunteer developer for MediaWiki, I have for quite some time been
working on two related things: improving the usability of Wikimedia
Incubator through an extension, and improving internationalization and
language support in MediaWiki. My Google Summer of Code project was a
continuation of these. A difficulty for me is that I usually code whatever
comes up at a certain point, as opposed to having a detailed plan, so GSoC
was in that regard different for me, plus looking at what I did so far
generally, I think I have done greater things for MediaWiki (like improving
RTL support) in the past than now during GSoC.
In MediaWiki core I wanted to include all ISO 639 language codes [1] and
their names and I wanted to make a cache for the MediaWiki language names
in general. This has been done, although the cache is implemented only for
the list of ISO 639 languages. As for unplanned things, I continued working
on the page content language, specifically converting DateFormatter, dates
in sortable tables and default image alignment [2] to the page content
language; I also did a few more things, e.g. added a Uzbek Latin-Cyrillic
language converter[3].
In the WikimediaIncubator extension, I created a special page
(Special:IncubatorFirstSteps[4]) that guides users through setting up an
account and/or creating a test wiki. I improved the automatic info pages
[5] which welcome users to a certain test wiki and I added a parser
function which will eventually replace the current info page template. It
should therefore be able to take parameters, and not all of them have been
added yet but the general structure is ready. The database and logo code is
rewritten, enabling localized logos on the info pages (not important, but
nicer). Lastly, I wanted to add filtering and suggestions for language
codes in inputboxes where they need to be entered, which I did in the
preferences.
Now I will still work on the extension and I will likely be active on
MediaWiki in general, but as I explained I do not really have a plan :) In
core however, I think I would still like to add the feature to specify the
page content language via the interface (into the database), currently it
is only possible through an extension hook.
My mentor was Niklas, and as we are both more quiet persons we did not
communicate as often as it probably should in GSoC; on the other hand I am
familiar with MediaWiki so I did not have a lot of questions or problems.
In any case I would like to really thank him for his time and all the code
review he did for my code commits.
It was also very nice to have regular deployments to Wikimedia wikis,
especially since Incubator is in phase 1, so it gets code updates quickly
after the code is branched.
Lastly, I probably could have achieved more in the GSoC summer, but it is
always surprising how fast the time can go even though you are a lot of
your time at your computer.
Thank you,
Robin Pepermans (SPQRobin)
[1] All languages: https://gerrit.wikimedia.org/r/#/c/11829/
[2] Default image alignment: on translations in RTL languages, images are
correctly aligned at the left instead of right, for example on
https://meta.wikimedia.org/wiki/Wikimedia_Highlights,_May_2012/ar
[3] Uzbek converter: https://gerrit.wikimedia.org/r/#/c/15690/
[4] https://incubator.wikimedia.org/wiki/Special:IncubatorFirstSteps
[5] Incubator info pages are in the format Wx/xyz, e.g.
https://incubator.wikimedia.org/wiki/Wn/bn
All my recent commits: https://gerrit.wikimedia.org/r/#/q/owner:SPQRobin,n,z
> Date: Thu, 23 Aug 2012 15:32:49 +0100
> From: Neil Harris
> Yes. Absolutely this: in some sort of platform-wide repositry, in the
> same way that Commons does for images.
>
> This is also a real chance to clean up many of the cross-wiki
> infelicities that have built up in the old template system.
>
> And coord, citation, and infobox templates are the obvious places to start.
Dont forget {{convert}} that is the most evil template I know of, with
many layers of sub templates to mimic printf type functionality.
Richard
Hi
Its final evaluation period, so I take this time to write some final notes
on the project I worked on this summer, that is integrating collaborative
editing into the VisualEditor project[1]. So to fit rightly into the scope
of GSoC, the whole collaborative thing on VisualEditor was split into two
phases, of which, the first phase was aimed to be delivered. The system is
to allow only one user to make changes to a document in an editing session,
while the others can spectate the changes in realtime, therefore halting at
a stage where concurrency issues arising from multiple editors, would be
deal with.
The project is majorly composed of the server-side and client-side
components. A server(collaboration server in this context) has been built,
which co-ordinates different clients participating in an editing session.
Some of the things that the collaboration server does are -
1. Maintains a centralized copy(server's copy) of the document that is
worked on in an editing session.
2. Listens to the incoming transactions from a client who makes a new
change to the document and applies those transactions to the server's copy
of the document.
3. Broadcasts an incoming transaction to the other clients subscribed to
the same editing session that triggered the transaction, so that they can
apply that transaction to their local documents and keep in sync.
4. Re-use the VisualEditor modules to create a binding for taking care of
the above.
5. Talks to an external parsoid service, when it needs the HTML feeding for
initializing a document. Initially it used parsoid modules to parse wiki
content internally, but considering the scalability, this is done over HTTP
using an external parsoid service.
6. And ofcourse, it scales the above features for multiple editing sessions.
The server is built in node.js and uses socket.io library for making
persistent connections with the clients. For testing, nodeunit has been
used.
The other major aspect of the project is, the client module, which hooks
into VisualEditor, initiates a connection with the server, and does all the
things with transactions including translating them to the server. The
components of client module, like other components of VE, interact using
events, which has allowed me to test them easily. And, for testing some
major parts of the code, qunit has been used.
So the above, makes for more than 90% of all that I wanted to do. Some of
the things that remain are -
1. Authentication of users on collaboration server - Currently, the users
which connect to the collaboration server are not validated before putting
them on one of the editing sessions. To overcome this, there has to be way
by which MediaWiki could help in validating a user coupled with some extra
information by a third party. This called for the need of OAuth, but since
OAuth isn't ready yet, Roan and Trevor suggested to have a new API module
for doing that. I've implemented the API module[2], and written the
authentication part in my project aligned with the implementation. So its
nearly done.
2. Transfer of editing control - This is one feature I've not worked on due
to confusions mainly related to correctly attributing edit credits to
particular users which took part in the editing session. I think, this
should not be hard to implement, once the confusions are stripped away.
The above are part of the tasks in my current plan. My plan for future is
to further refine the code that I've written so far, especially the server
side code. There have been umpteen times when I've shown my demo to people,
and they've said, 'dude, it would be amazing if it supported multiple
editors', that has always enticed me to work on supporting multiple
editors. But, I realized, it was really good decision to cut the scope till
what has been done for the sake of robustness. Although, it will be a
challenging task, but its definitely in my plan to work on supporting
multiple editors in future. The time when we won't need Etherpad, hopefully
:)
It has been a great fun and learning time working along side some bright
students, dedicated volunteers and amazing Wikimedia engineers, especially
the VisualEditor team. Special thanks to Trevor, Gabriel, Roan,
Mark(traceur), and all those who ever showed interest in my project.
Definitely looking forward to more awesome work.
Cheers!
--
Ashish Dubey