Based on many ideas that were put forth, I would like to seek comments on
this ZERO design. This HTML will be rendered for both M and ZERO subdomains
if varnish detects that request is coming from a zero partner. M and ZERO
will be identical except for the images - ZERO substitutes images with
links to File:xxx namespace through a redirector.
* All non-local links always point to a redirector. On javascript capable
devices, it will load carrier configuration and replace the link with local
confirmation dialog box or direct link. Without javascript, redirector will
either silently 301-redirect or show confirmation HTML. Links to images on
ZERO.wiki and all external links are done in similar way.
* The banner is an ESI link to */w/api.php?action=zero&banner=250-99* -
returns HTML <div> blob of the banner. (Not sure if banner ID should be
part of the URL)
Expected cache fragmentation for each wiki page:
* per subdomain (M|ZERO)
* if M - per "isZeroCarrier" (TRUE|FALSE). if ZERO - always TRUE.
3 variants is much better then one per carrier ID * 2 per subdomain.
P.S.
Redirector is a Special:Zero page, but if speed is an issue, it could be an
API calls (which seem to load much faster). The API call would redirect to
the target, or could either redirect to the special page for confirmation
rendering, or output HTML itself (no skin support, but avoids an extra
redirect). Might not be worth it as javascript will be available on most of
our target platforms now or soon.
I wrote a tool that will import bugs from Bugzilla into either Mingle
and/or Trello (two project management tools used by some teams at the
Wikimedia Foundation). The mobile web team was finding it difficult to keep
track of two separate tools - one for new feature development, the other
for tracking bugs, so Bingle helps bridge the gap and allows us to focus on
one tool. This has had the side effect of keeping visibility of reported
bugs high and has made it easier for us to quickly prioritize incoming bugs
against existing work, and quickly respond to open issues.
You can find the code and some rudimentary usage instructions here:
https://github.com/awjrichards/bingle
I hacked this together rather quickly - expedience was my goal rather than
perfection, so it's not well documented, a little quirky, and there's a lot
of room for improvement. I've been sitting on it for a while, hoping to
make improvements before announcing it, but I have not found the time to
make the changes I would like (eg for it to use the Bugzilla API rather
than Bugzilla atom feeds). So, I invite anyone interested and willing to
fork it, and pitch in and help make it awesome :)
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
Heya folks :)
Quite a while ago Ubuntu did a paper cuts initiative
(https://wiki.ubuntu.com/OneHundredPaperCuts). Basically it was about
collecting and fixing small bugs/annoyances that were easy to fix but
had a large impact on how pleasant it is to use the product. We're
going to do something similar for Wikidata now.
I'd like to get a bugzilla keyword for this so we can easily tag those
bugs. For that I need at least one other team however who'd like to
join such an initiative. Is there anyone who's interested in this?
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Technical Projects
Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Hi all,
I've been working on an api module/extension to extract metadata from
commons image description pages, and display it in the API. I know
this is an area that various people have thought about from time to
time, so I thought it would be of interest to this list.
The specific goals I have:
*Should be usable for a light box type feature ("MediaViewer") that
needs to display information like Author and license. [1] (This is
primary use case)
*Should be generic where possible, so that better metadata access can
be had by all wikis, even if they don't follow commons conventions.
For example, should generically support exif data from files where
possible/appropriate, overriding the exif data when more reliable
sources of information are available.
*Should be compatible with a future wikidata on commons thing. [2]
**In particular, I want to read existing description page formatting,
not try and force people to use new parser functions or formatting
conventions, since they may become outdated in near future when
wikidata comes
**Hopefully Wikidata would be able to hook into my system (Well at the
same time providing its own native interface)
*Since descriptions on commons are formatted data (Wikilinks are
especially common) it needs to be able to output formatted data. I
think html is the most easy to use format. Much more easy to use than
say wikitext (However this is perhaps debatable)
What I've come up with is a new api metadata property (Currently
pending review in gerrit) called extmetadata that has a hook
extensions can hook into. [3] [4] [5] Additionally I developed an
extension for reading information from commons description pages. [6]
It combines information from both the file's metadata, and from any
extensions. For example, if the Exif data has an author specified
("Artist" in exif speak), and the commons description page also has
one specified, the description page takes precedence, under the
assumption its more reliable. The module outputs html, since that's
the type of data stored in the image description page (Except that it
uses full urls instead of local ones).
The downside to this is in order to effectively get metadata out of
commons given the current practises, one essentially has to screen
scrape and do slightly ugly things (Look ahead for a brighter tomorrow
with wikidata!)
As an example, given a query like
api.php?action=query&prop=imageinfo&iiprop=extmetadata&titles=File:Schwedenfeuer_Detail_04.JPG&format=xmlfm&iiextmetadatalanguage=en
it would produce something like [7]
So thoughts? /me eagerly awaits mail tearing my plans apart :)
[1] https://www.mediawiki.org/wiki/Multimedia/Media_Viewer
[2] https://commons.wikimedia.org/wiki/Commons:Wikidata_for_media_info
[3] https://gerrit.wikimedia.org/r/#/c/81598/
[4] https://gerrit.wikimedia.org/r/#/c/78162/
[5] https://gerrit.wikimedia.org/r/#/c/78926/
[6] https://gerrit.wikimedia.org/r/#/c/80403/
[7] http://pastebin.com/yh5286iR
--
Bawolff
The day we have all equally hoped for and dreaded is come to pass: Etherpad
Lite has now replaced Etherpad "Classic" in production, and the labs instance
is on its way out.
This is my as-wide-as-possible email warning to say that everything on the
labs instance, as really should have been expected, is going to be gone soon.
Not immediately - we intend to give you two weeks to get your important data
off the instance and onto the new one at https://etherpad.wikimedia.org/ -
but you should _absolutely_ be moving things as soon as possible. We will
also keep a data dump around, in case anything else needs to get pulled out
of the pads, but I would suggest not relying on that if you don't have to.
And in the future: If a URL has "wmflabs.org" in it...don't put anything,
ANYTHING, important there. The purpose of labs is to let us experiment with
new technology without having to worry about reliability.
Thanks so much for your help and understanding in the course of this
migration.
tl;dr: http://etherpad.wmflabs.org is going down in 2 weeks, get yer stuff
off it.
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
As multilingual content grows, interlanguage links become longer on
Wikipedia articles. Articles such as "Barak Obama" or "Sun" have more than
200 links, and that becomes a problem for users that often switch among
several languages.
As part of the future plans for the Universal Language Selector, we were
considering to:
- Show only a short list of the relevant languages for the user based on
geo-IP, previous choices and browser settings of the current user. The
language the users are looking for will be there most of the times.
- Include a "more" option to access the rest of the languages for which
the content exists with an indicator of the number of languages.
- Provide a list of the rest of the languages that users can easily scan
(grouped by script and region ao that alphabetical ordering is possible),
and search (allowing users to search a language name in another language,
using ISO codes or even making typos).
I have created a prototype <http://pauginer.github.io/prototype-uls/#lisa> to
illustrate the idea. Since this is not connected to the MediaWiki backend,
it lacks the advanced capabilities commented above but you can get the idea.
If you are interested in the missing parts, you can check the flexible
search and the list of likely languages ("common languages" section) on the
language selector used at http://translatewiki.net/ which is connected to
MediaWiki backend.
As part of the testing process for the ULS language settings, I included a
task to test also the compact interlanguage designs. Users seem to
understand their use (view
recording<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>),
but I wanted to get some feedback for changes affecting such an important
element.
Please let me know if you see any possible concern with this approach.
Thanks
--
Pau Giner
Interaction Designer
Wikimedia Foundation
context
-------
i’m working on a mediawiki extension,
http://www.mediawiki.org/wiki/Extension:GWToolset, which has as one of its
goals, the ability to upload media files to a wiki. the extension, among
other tasks, will process an XML file that has a list of urls to media
files and upload those media files to the wiki along with metadata
contained within the XML file. our ideal goal is to have this extension run
on http://commons.wikimedia.org/ <onhttp://commons.wikimedia.org/>.
background
----------
h
ttp://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_Co…<http://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_C…>
Metadata Set Repo
-----------------
one of the goals of the project is to store Metadata Sets, such as XML
under some type of version control. those Metadata Sets need to be
accessible so that the extension can grab the content from it and process
it. processing involves iterating over the entire Metadata Set and creating
Jobs for the Job Queue which will upload each individual media file and
metadata into a media file page using a Mediawiki template format, such as
Artwork.
some initial requirements
• File sizes
• can range from a few kilobytes to several megabytes.
• max file-size is 100mb.
• XML Schema - not required.
• XML DTD - not required.
• When metadata is in XML format, each record must consist of a single
parent with many child
• XML attribute lang= is the only one currently used and without user
interaction
• There is no need to display the Metadata sets in the wiki.
• There is no need to edit the Metadata sets in the wiki.
we initially developed the extension to store the files in the File:
namespace, but we were told by the Foundation that we should use
ContentHandler instead. unfortunately there is an issue with storing
content > 1mb in the db so we need to find another solution.
1. any suggestions?
Mapping
-------
a mapping is a json that maps a metadata set to a mediawiki template. we’re
currently storing those as Content in the namespace GWToolset. an entry
might be in GWToolset:Metadata_Mappings/Dan-nl/Rijkmuseum.
1. does that namespace make sense?
a. if not, what namespace would you recommend?
2. does this concept make sense?
a. if not, what would you recommend?
Maintaining Original Metadata Snippet & Mapping
-----------------------------------------------
another goal is to link or somehow connect the original metadata used to
create the mediafile:
• metadata set
• metadata snippet
• metadata mapping
the current thought is to insert these items as comments within the wiki
text of the media file page
1. does that make sense?
a. if not, what would you recommend doing?
2. is there a better way to do this?
mediawiki template parameters
-----------------------------
the application needs to know what mediawiki template parameters exist and
are available to use for mapping media file metadata to the mediawiki
templates. for the moment we are hard-coding these parameters in a db table
and sometimes in the code. this is not ideal. i have briefly seen
TemplateData, but haven’t had enough time to see if it would address our
needs.
1. is there a way to programatically discover the available parameters for
a mediawiki template?
thanks in advance for your help!
dan
I have a bot editing script that started having trouble logging
in to the English Wikipedia a few days ago. I think what's
happening is that the login process started using Javascript in a
way it didn't before, and is detecting that my script doesn't do
Javascript (which it doesn't), and throwing a second, fallback,
non-Javascript-using login page at the point where the script is
expecting to have already logged in.
So the question is, if this is the case, is there a way to force
the use of the non-Javascript login page from the beginning?
Or if this is not the case, is there some other recent change
that might have affected the flow?
(And, in case you're wondering, no, the script does not use the
API, but yes, I know about it, and this may be the circumstance
that goads me into actually using it.)
Deployment Schedule and Highlights
Week of September 2nd, 2013
Full schedule:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_2nd
== Monday ==
No deploys! US holiday! (Labor Day)
== Tuesday ==
* E2: Deploying updates/bug fixes to Echo and PageTriage
* MediaWiki Core: We'll be deploying 1.22wmf15 to all non-Wikipedia
sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote,
Wikiversity, and a few other sites)
** See the release notes here:
https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf15
== Wednesday ==
* Wikipedia Zero: Finalizing their intended code
* MobileFrontEnd: Graciously moved to Wed to allow MWCore on Tuesday.
* Gerrit: The machine that hosts Gerrit will be swapped for a much more
powerful machine. This should not cause any issues to end users if
things go to plan.
== Thursday ==
* MediaWiki Core: Version 1.22wmf15 will be deployed to all Wikipedia
language sites.
* MediaWiki Core: The next release of MediaWiki, 1.22wmf16, will be
deployed to the test wiki group (test.wikipedia, test2.wikipedia,
test.wikidata, and mediawiki.org)
* E3 is deploying bug fixes to GuidedTour and GettingStarted.
== Friday ==
No deploys! It's Friday!
Have a good weekend and let me know if you have any questions,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |