Wikitech-l May 2012

wikitech-l@lists.wikimedia.org

136 participants
127 discussions

Notes from the Gerrit Hackathon
by Rob Lanphier 25 May '12

25 May '12

Hi folks, Chad alerted me to the notes of the Gerrit Hackathon, which happened May 7-11: https://groups.google.com/forum/#!msg/repo-discuss/kEL3FPT2rLo/w39qjsmnrwwJ No one from WMF was there, but I thought you all might find this interesting. Bits I found interesting: * The Gerrit devs are working on a plugin/extension system, which should make it much easier to extend Gerrit. They're planning both a simple but stable API ("extensions"), and a more powerful but less stable API ("plugins"). *, They plan to integrate Lucene, which in addition making search generally work better, will also mean that they can then start moving stuff out of the database and into git itself (in git notes[1] if necessary for after-the-fact editing). It took me a while to understand why this is useful, but now I get it. If they really go all the way with this, it could mean cloning a repo will give you all of the data in Gerrit, which means that Git guis could be made to support Gerrit metadata, and that one might never have to interact directly with the web interface. * Tagging ("change labels") is on their roadmap (which the notetaker acknowledges are "highly coveted"). However, they want to integrate Lucene into Gerrit first, since they tags just being search metadata that can be indexed/refreshed in Lucene rather than having to ever live in the db. Rob [1] Git notes: http://schacon.github.com/git/git-notes.html

2 1

Re: [Wikitech-l] The bugtracker problem, again
by Mark A. Hershberger 24 May '12

24 May '12

Andre Klapper <andre_klapper(a)gmx.net> writes: > Can I (average user) add myself to that default CC list for a component > (I am not aware of any way), or do I need to first need to find out that > "default CC" exists, somehow find out who and how to contact for getting > added to it (and then somebody has to add me and respond to my request) > without losing motivation on my way to achieve all this? :-/ I just discovered the Component Watching extension for Bugzilla that allows anyone to watch any component via their Bugzilla preferences. https://bugzilla.mozilla.org/show_bug.cgi?id=634531 Since I think this would be very useful for Wikimedia users, I've created a request for it: https://bugzilla.wikimedia.org/show_bug.cgi?id=37105 -- http://hexmode.com/ Find peace within yourself and there will be peace on heaven and earth. -- Abba Isaac

1 0

UploadWizard campaign info API format
by Brion Vibber 24 May '12

24 May '12

I'm adding an API module to retrieve UploadWizard upload campaign information, which we need for the upcoming mobile application for Wiki Loves Monuments. Essentially the app will include a very limited implementation of a couple steps of UploadWizard for things like license selection and filling the ID field and description, so we have one consistent set of configuration for both web upload (using UploadWizard) and mobile uploads (using the app). The change waiting review in gerrit: https://gerrit.wikimedia.org/r/#/c/7832/ If anybody's got a prime usage in mind for reading UploadWizard campaign data from the API and has recommendations for adjusting the output format (maybe for making the editing view more AJAX-y) please give a shout -- this is not final and we can adjust it. Currently it'll return XML like this: <?xml version="1.0"?><api> <uploadcampaign> <campaigns> <campaign name="wlm-es" id="2" isenabled="0" autoCategories="" autoWikiText="" defaultAlt="" defaultCategories="" defaultDescription="" defaultLat="" defaultLon="" defaultOwnWorkLicence="cc-by-sa-3.0" headerLabelPage="sdfsdf" idField="sdfafsdfd" idFieldInitialValue="" idFieldLabel="" idFieldLabelPage="" idFieldMaxLength="25" licensesOwnWork="cc-by-sa-3.0|cc-by-3.0|cc-zero" ownWorkOption="choice" skipTutorial="" thanksLabelPage="" tutorialHelpdeskCoords="27, 1319, 691, 1384" tutorialTemplate="Licensing_tutorial_$1.svg" tutorialWidth="720" /> </campaigns> </uploadcampaign></api> or JSON like this: { "uploadcampaign": { "campaigns": [ { "name": "wlm-es", "id": 2, "isenabled": 0, "autoCategories": "", "autoWikiText": "", "defaultAlt": "", "defaultCategories": "", "defaultDescription": "", "defaultLat": "", "defaultLon": "", "defaultOwnWorkLicence": "cc-by-sa-3.0", "headerLabelPage": "sdfsdf", "idField": "sdfafsdfd", "idFieldInitialValue": "", "idFieldLabel": "", "idFieldLabelPage": "", "idFieldMaxLength": "25", "licensesOwnWork": "cc-by-sa-3.0|cc-by-3.0|cc-zero", "ownWorkOption": "choice", "skipTutorial": "", "thanksLabelPage": "", "tutorialHelpdeskCoords": "27, 1319, 691, 1384", "tutorialTemplate": "Licensing_tutorial_$1.svg", "tutorialWidth": "720" } ] } } -- brion

4 7

HTMLMultiSelectField as <select multiple="multiple"/>
by Daniel Werner 24 May '12

24 May '12

Right now I am implementing a new option (as part of https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd like to use a <select multiple="multiple"/> html element with options. Right now MediaWiki always generates a list of selectboxes instead of that when using the HTMLMultiSelectField class. We are talking about 280+ selectable items here, so for now we came to the conclusion that a real multi <select/> would be nicer and less space consuming for now I have already managed to implement this multiple select, modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which can be set to false to disable the known behavior and use a select element instead. This would mainly be for the JavaScript-less ui. If javascript were enabled, we could still do something nicer, for example with something like jQuery chosen plugin here. My question would just be, how I should implement these changes preferably. Is it ok with the new option for HTMLMultiSelectField or should this be a new class inheriting from HTMLMultiSelectField? I think HTMLMultiSelectField sounds more like describing what I just implemented rather than a bunch of select boxes, but of course renaming the existing one could "break" extensions (even though both are fully compatible and interchangeable). So one option would be simply naming the new one HTMLMultiSelectField2 if we don't want to stick with an additional option here. Cheers Daniel -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de 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.

4 3

Many new developers & project owners - welcome!
by Sumana Harihareswara 24 May '12

24 May '12

We used to send an email to wikitech-l every time we approved new Subversion committers, but now that we've switched to Git, I don't do that anymore. We've welcomed at least a hundred new people to our developer community since the Git switch two months ago, and you can see most of them at https://www.mediawiki.org/wiki/Developer_access/Archive . Welcome to all of you! We've also given some folks Gerrit project owner status so they can merge in changes to MediaWiki core or to certain extensions; see https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership/Archive for that list. Explanation at https://www.mediawiki.org/wiki/Git/Workflow#Who_can_review.3F_Gerrit_projec… . Incidentally, right now the queue of people waiting for developer access accounts (Git/Gerrit and Labs access) is empty, as is the queue of requests for Gerrit project ownership. Feel free to add yours! https://www.mediawiki.org/wiki/Developer_access https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

1 0

some people complained already about my recent security alerts for PHP, OpenOffice, LibreOffice...
by Thomas Gries 23 May '12

23 May '12

... in consequence, you will _/not /_receive further major security alerts.

5 5

The bugtracker problem, again
by David Gerard 23 May '12

23 May '12

Discussion on Oliver Keyes' blog: http://quominus.org/archives/714 He's coming from the perspective of liaison with newbies. Read the comments. (I will note that Antoine Musso was right in the previous discussion that Mantis has a nice, friendly interface. I myself was most displeased to discover that (a) the code itself is really horrible (b) it's all but unsupported even to free-software standards.) - d.

23 45

Git Office Hours - May 22nd
by Chad 22 May '12

22 May '12

Hi everyone, I'd like to invite anyone who is interested in Git, Gerrit and code review to office hours I will be holding on IRC next week. Here are the full details: Channel: #wikimedia-dev on Freenode Date: May 22, 2012 Time: 18:30-19:30 UTC (13:30 EDT, 11:30 PDT) Subject: Git/Gerrit I will be on hand to answer any questions you have about the git migration so far, the process moving forward, and anything else interesting you can think up. Have a great week, and I hope you can join us next Tuesday! -Chad

2 1

WIkidata and Global Profile.
by Raylton P. Sousa 22 May '12

22 May '12

By chance Wikidata[1] could be a substitute for the Global Profile[2]? Because at least from what I understand it would not take much to implement this. I do not know if I'm talking nonsense, but I would be happy if it was done. [1]http://meta.wikimedia.org/wiki/Wikidata [2]http://www.mediawiki.org/wiki/GlobalProfile

3 2

Introducing: Designs for the Universal Language Selector
by Pau Giner 22 May '12

22 May '12

Today we are announcing the designs and interactive prototypes for the Universal Language Selector. Wikipedia is available in 285 languages, and MediaWiki has been translated to almost 400 languages. Several language-related tools are available to support the consumption and contribution of content in different languages. These tools allow users to type text in a language for which their keyboard is not prepared, download appropriate web fonts to display non-Latin scripts properly and choose the language of their user interface. The Universal Language Selector is a tool that will allow users to select a language and configure its support in an easy way. When the number of languages in a list approaches 400, ease of use becomes both a need and a challenge. The design process for the selector started with the analysis of user needs and the definition of representative scenarios to support. Then, we explored different ideas in the form of sketches and wire-frames through different iterations. Finally, we have created interactive prototypes to test whether our ideas work with real users, and we want to share them with the community. More information about the designs has been recently published at the Wikimedia Foundation blog: http://blog.wikimedia.org/2012/05/21/introducing-designs-for-the-universal-… We are announcing the availability of the Universal Language Selector designs to gather feedback on the proposed solutions, and ask for volunteers to test our prototypes. If you want more details on the designs or want to have ideas for improvement or criticism on the designs, feel free to do so on the talk page for the Universal Language Selector: https://www.mediawiki.org/wiki/Universal_Language_Selector#Proposed_design If you are a speaker of Arabic, Dutch, Hebrew or Hindi, you can also request participation for the usability tests at http://goo.gl/QpWmu In less than 30 minutes you can participate in the tests and experience whether our proposed solutions work in practice for your specific language community and context. Pau -- Pau Giner Interaction Designer Wikimedia Foundation

1 0

← Newer
1
2
3
4
5
6
7
...
13
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l May 2012