The links may not go anywhere useful. Ignore them.
I'm sorry. These e-mails shouldn't have gone out (and didn't in testing).
The links should slowly start to work as things finish importing.
Yay one time migration costs. Again, sorry for the possible deluge some
of you may get.
-Chad
Hello,
A quick reminder about Language Engineering team's monthly IRC office hour
later today at 1700 UTC on #wikimedia-office. Please see below for the
original announcement, local time, and agenda. We will post logs on
metawiki[1] after the event.
Thanks
Runa
[1] https://meta.wikimedia.org/wiki/IRC_office_hours#Office_hour_logs
Monthly IRC Office Hour:
=======================
# Date: December 10, 2014 (Wednesday)
# Time: 1700 UTC (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141210T1700)
# IRC channel: #wikimedia-office
# Agenda:
1. Updates from the Content Translation project
2. Q & A/Discussions
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Fri, Dec 5, 2014 at 11:26 AM
Subject: [x-post] Language Engineering IRC Office Hour on December 10, 2014
(Wednesday) at 1700 UTC
To: MediaWiki internationalisation <mediawiki-i18n(a)lists.wikimedia.org>,
Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>, Wikimedia
developers <wikitech-l(a)lists.wikimedia.org>
[x-posted announcement]
Hello,
Please save the date for the monthly IRC office hour of the Wikimedia
Language Engineering team on Wednesday, December 10, 2014 at 1700 UTC
on #wikimedia-office. Project updates will include information about
the new version of Content Translation[1] and plans for the next
release.
Please see below for event details and local time.
Thanks
Runa
[1]
https://www.mediawiki.org/wiki/Content_translation/Announcement-November2014
Monthly IRC Office Hour:
=======================
# Date: December 10, 2014 (Wednesday)
# Time: 1700 UTC (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141210T1700)
# IRC channel: #wikimedia-office
# Agenda:
1. Updates from the Content Translation project
2. Q & A/Discussions
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Hi all!
The Architecture Committee, and especially Tim, has been going through the RFC
backlog over the last moths. Many where discussed at the weekly RFC chat on
Wednesdays, and most of these were resolved. But there are some rather old RFCs
left, for which it's a bit unclear whether anyone is still interested in
discussing them.
So, if you like, go through the list below and tell us whether you would like to
discuss an RFC, or think it should be abandoned, or amended, or rewritten, or
whatever.
*
https://www.mediawiki.org/wiki/Requests_for_comment/Refactor_on_File-FileRe…
This is a proposal to refactor media handling code. In particular, it proposes
to split backend tasks performed by MediaHandler from UI related tasks.
*
https://www.mediawiki.org/wiki/Requests_for_comment/Drop_actions_in_favour_…
This is a proposal to move away from action= in favor of Special pages. Perhaps
obsolete, since action handling was rewritten since?
* https://www.mediawiki.org/wiki/Requests_for_comment/Itemise_protection
This argues that we should support multiple protections to apply to a page at
once, e.g. indefinite semi-protection and at the same time a short-term full
protection.
I'd personally like to discuss this as part of a larger refactoring that would
implement protection based on our permission system. Basically, applying
protection would mean overriding which group has which permissions on a given page.
* https://www.mediawiki.org/wiki/Requests_for_comment/Regex-based_blacklist
A proposal to overhaul SpamBlacklist (from 2008). I'd personally be more
interested in integrating this with (a rewrite of) AbuseFilter. We could have
multiple lists, accessible from AbuseFilter rules.
There are also some RFCs that relate to organizational issues rather than
MediaWiki features and architecture as such:
* https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation
Automatically compose RELEASE-NOTES based on special lines in the git commit
message. I like the idea!
* https://www.mediawiki.org/wiki/Requests_for_comment/Distribution_and_deploy…
This looks like a grand design, with very little information about what exactly
it is supposed to do, and how. It's from 2010 and marked "incomplete". Anyone
interested?
* https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation
This is about creating a governance group for MediaWiki, separate from
Wikimedia. The release management for MediaWiki has since been moved to Mark
Hershberger and Markus Glaser, but I don't know much about their arrangement
with WMF. Is there still demand for a MediaWiki Foundation?
Some good ideas here, and some old cruft. I think the most important factor in
deciding what to discuss is to see for which RFCs there are people interested in
working on them.
So, please give us some feedback, ideally until Monday, so we can plan the RFC
chat for Wednesday .
Cheers,
Daniel
In this week's RFC meeting I think we should discuss the following RFC:
* Drop actions in favour of page views and special pages
<https://www.mediawiki.org/wiki/Requests_for_comment/Drop_actions_in_favour_…>
Because it was mentioned in Daniel's wikitech-l thread.
The meeting will be on the IRC channel #wikimedia-office on
irc.freenode.org at the following time:
* UTC: Wednesday 21:00
* US PST: Wednesday 13:00
* Europe CET: Wednesday 22:00
* Australia AEDT: Thursday 08:00
-- Tim Starling
Hi list,
I wanted to get some feedback about https://phabricator.wikimedia.org/T74222.
In the last security release, I changed the return of the api to remove the
"action" for log entries that had been revdeleted with "Hide action and
target". However, ever since 2009 / r46917, we've assumed that "Hide action
and target" didn't mean the actual action field in the db, but rather the
target and the text of the message about the action, which might include
other parameters. So the message about what's being hidden and the intended
protection of that option could have slightly different interpretations.
I'd like to hear if anyone has intended for the actual log action to be
deleted / suppressed. If not, I'm happy to revert the recent patch, and
we'll just update the wording in the deletion UI to be more clear about
what is being removed.
Hey all,
Thanks again to everyone who participated in the recent MediaWiki-Vagrant
survey. Your responses have given us some great insight into how we might
improve upon this already invaluable developer tool.
A broad summary of the results has been published to MW.org, along with the
(further anonymized) data for anyone who's interested.[1] I tried to keep
the summary short and sweet but the even shorter and sweeter (tl;dr) is:
users of MW-Vagrant are highly satisfied with it overall but there are some
improvements to be made in terms of stability, performance, and
provisioning speed.
Cheers,
Dan
[1] https://www.mediawiki.org/wiki/MediaWiki-Vagrant/Surveys/2014Q4
--
Dan Duvall
Automation Engineer
Wikimedia Foundation <http://wikimediafoundation.org>
Google Code-in (GCI) has been running for only one week and students
have already resolved 35 Wikimedia tasks!
Some of the achievements:
* Citoid offers export in BibTeX format (and more contributions)
* Analytics' Dashiki has a mobile-friendlier view
* Echo's badge label text has better readability; Echo uses the
standard gear icon for preferences
* Wikidata's Wikibase API modules use i18n for help/docs
* Two MW extensions got patches to not use deprecated i18n
functions
* MW displays an error when trying to create a self-redirect
* The sidebar group separator in MW's Installer looks like in
Vector
* Our Phabricator docs have video screencasts and an updated "Bug
report life cycle" diagram
* Huggle's on-wiki docs were updated; exceptions received cleanup
* Pywikibot's replicate_wiki supports global args; optparse was
replaced by argparse
* Reasons for MW sites listed as defunct on WikiApiary were
researched
* We got logo proposals for the European Wikimedia Hackathon 2015
* ...and many more.
Sounds good? Then please spend 5 minutes to go through your tasks and
identify simple tasks to allow more young people contribute!
Got an idea for a task? Become a mentor for that task! And spread the
word to other community members who might be good mentors! Read
https://www.mediawiki.org/wiki/Google_Code-in_2014#Mentors.27_corner and
please contact me if you need help.
Thank you!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hello,
I am not sure this is the right mailing list to introduce this project
but I have just released Displee. It is a small Android app that allows
to search for images in the English Wikipedia by taking pictures:
https://play.google.com/store/apps/details?id=org.visualink.displee
It is a kind of open source Google Goggles for images from en.wikipedia.org.
I have developed Displee as a demonstrator of Pastec http://pastec.io,
my open source image recognition index and search engine for mobile apps.
The index hosted on my server in France currently contains about 440 000
images. They may not be the most relevant ones but this is a start. ;-)
I have also other ideas to improve this tiny app if it has an interest
for the community.
Displee source code (MIT) is available here:
https://github.com/Visu4link/displee
Pastec source code (LGPL) is available here:
https://github.com/Visu4link/pastec
The source code of the Displee back-end is not released yet. It is
basically a python3 Django application.
I will be glad to receive your feedback and answer any question!
Best regards,
--
Adrien Maglo
Pastec developer
http://www.pastec.io
+33 6 27 94 34 41
Hi,
It's been some time since we launched tool labs and there is
incredible number of tools now. They all however have 2 major
problems. Every tool has own, different layout / css style (which may
be confusing the users of these tools) and every developer of these
tools probably have to reinvent a wheel at some point as they all have
to do some common tool setup - eg. they have to create some basic php
skeleton that would access wikimedia resources, from databases,
memcache, reddis to API's and so on.
What about creating some common uniform framework in php that, just as
pywikipediabot that is used to create bots, would be used to create
web-based tools. So that maintainer of a tool would just fork or clone
this framework and wouldn't have to spend their time creating
functions that would generate html pages with wikimedia uniform style
(similar to how vector looks, for example, or just any uniform style,
so that tools would look similar), access wikimedia databases, OAuth,
ldap, API...
I believe it would not just make creation of new tools incredibly
simple, but it would also make all tools have consistent look and
feel, and thus improve the end user experience. What you think? Is
there someone who would like to work on that?
Yes please provide some links to all these solutions if you can I will try
to reuse as much as possible
On Dec 8, 2014 5:51 PM, "Platonides" <platonides(a)gmail.com> wrote:
> I coded such frameworks some years ago. It was based on MediaWiki code,
> so it (a) looked similar to MW code, (b) would be easier to port if it was
> to be converted into a MediaWiki extension, (c) had quite advanced code
> ready to use (like the database access primitives or creating a gallery).
>
> The code is ~200 lines of library code plus ~250 for the skin (ie. skipped
> for cli scripts).
> Mostly glue so that it could load from a db from a project, to use
> ToolserverI18N instead of MW native ones, etc.
> The html showed either Vector or Monobook skin, including links to view
> the tool translated and even warned about the status of each Toolserver
> cluster (doesn't have an equivalence in labs).
>
> If you are interested on this code, it can be used as a basis for the
> framework. It should be brought up to date with modern MediaWiki, though.
> On the plus side, that would allow my old toolserver tools to run again :)
>
> _______________________________________________
> Labs-l mailing list
> Labs-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>