Turning back to the automating thing and the Main Page.
I've got tired updating the Other Wikipedias section (congratulations to
the Swedish Wikipedia!), so I wrote some code to automate the job.
There is a bot that updates different statistics per wiki. I decided to
parse the data page and push it through a mediawiki message to avoid
hard-coded pieces of text inside.
Here we have to expensive parts: getContent() for a template with necessary
data, and retrieving a message for the view. Is it OK to have expensives at
the Main Page?
The module is placed here: <http://goo.gl/3V5St>
--
З павагай,
Павел Селіцкас/Pavel Selitskas
Wizardist @ Wikimedia projects
So I was wondering how people would feel about adding a coding convention
for the use of is_null() in PHP code.
It's 10 times slower than doing === null, which is a bit trivial in
context, but nonetheless a fact, and it's also a bit easier to read,
especially when doing the inverse (i.e., doing !is_null( ... ) versus !==
null). Also, there's no functional difference between the two.
Any objections other than maintaining the status quo?
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com
Hi,
I am working on a GUI for LilyPond and am looking for your feedback on
the desirability or usefulness --if any-- for MediaWiki.
My desire is to have LilyPond accessible to everyone by presenting a
basic GUI initially so as to provide a more gentle introduction than
text to most people, simultaneously offering an easy way to learn the
LilyPond language and handhold them while they make the switch.
Although I started three years ago it is still mostly a play thing --I
do this just for fun and it has seen a few rewrites-- so it will be a
long way before it matches any of the power that LilyPond has, or even
that other GUIs offer right now.
I would enjoy having more focus and actual users and so early this
spring I took up the idea to create a basic web frontend alongside the
main Gnome/Gtk+ GUI.
Then, by the usual blend of sheer coincidence and providence, the
<score> extension landed. That has kept me wondering if what I have
now could [almost] be useful for MediaWiki or WikiPedia...or what
would need to be done to make it so.
Any feedback is much appreciated! Please have a look at
http://lilypond.org/schikkers-list
or go straight to the LilyPond Schikkers Demo
http://lilypond.org/schikkers/
Thankyou
Greetings, Jan
PS: as an aside, I read some complaints about Lily's SVG output on this
list; would you please send a bug report on that, or anything else
that you find amiss to bug-lilypond(a)gnu.org?
--
Jan Nieuwenhuizen <janneke(a)gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Hi
Most of you already know that, but I will repeat it once more, so that
everyone who is using bots project is aware of that.
Since tool labs (project tools on wikimedia labs) is now serving the
purpose which bots project on labs initially served for, we decided to
convert bots project to testing environment of tools project (and
shelter both wikimedia labs projects under the one big "virtual"
project called "tool labs")
I know it is very confusing naming but I hope once "aliasing" of
project names is possible on wikitech we just rename bots project to
tools-testing or something like that.
== I am already confused of the naming, explain now, or I will eat you ==
Wikimedia labs = a platform which host virtual instances, each
instance being a member of some labs project (that is basically entry
in LDAP which all these instances and members of project are member
of)
Tool labs = is a project that is supposed to offer hosting for web
based tools and bots. Tool labs consist of 2 wikimedia labs projects -
bots (testing) and tools (production)
== What does it mean for me in practice ==
The bots project will look very identical to tools project, but if we
need to test anything we will do that on bots just to make sure it
won't break tools project. That is a main difference.
Beside that bots project is going to be smaller (we don't need to
allocate so many resources just for a testing platform). Right now we
have 3 grid execution hosts, in future we will probably have 1 (or 2).
Therefore if you are hosting your bot on bots project now, you
/should/ move it to "stable" version of tool labs which is the tools
project. You don't need to do that if you don't want - but eventual
breakages may happen, and stability is not really guaranteed on bots
project (not that it was on tools :-))
TL/DR: If you are hosting your bot on bots project right now, move it
to tools project if you can, or bad things may (but not necessarily
will) happen to it, if we manage to break bots during some test.
[Public Service Announcement]
>From this week on I'm going to regularly blog about small & not so easy
to discover functionality in Bugzilla. It's based on conversations with
Wikimedia users & developers in the last months. That's you! ;)
The first one covers Bugzilla's Autocompletion feature:
http://blogs.gnome.org/aklapper/2013/06/14/bugzillatips-autocompletion/
Next weeks' topics:
* Changing the columns in search results
* Getting copies of another user’s bugmail
* Searching for empty fields
* Saved and shared searches
* Creating reports and tables
All episodes are/will be linked on
https://www.mediawiki.org/wiki/Bug_management#Tricks_and_best_practices_in_…
If you have some topic in mind: Tell me via IRC, email or Usertalk page,
or add a wishlist item to "Document best practices in Bugzilla" on
https://www.mediawiki.org/wiki/Bug_management/Task_list !
Cheerio & enjoy your weekend,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ and likely
elsewhere as well
On Fri, Jun 14, 2013 at 10:40 PM, Wjhonson <wjhonson(a)aol.com> wrote:
> Where is this public policy discussion going to be archived for those who cannot attend
>
>
>
>
>
>
> -----Original Message-----
> From: Greg Grossmeier <greg(a)wikimedia.org>
> To: mediawiki-l <mediawiki-l(a)lists.wikimedia.org>; Wikimedia developers <wikitech-l(a)lists.wikimedia.org>; mediawiki-enterprise <mediawiki-enterprise(a)lists.wikimedia.org>
> Sent: Fri, Jun 14, 2013 1:33 pm
> Subject: [MediaWiki-l] IRC Office Hour (was Re: RFP Submissions: Please review and ask questions! - Next Steps)
>
>
> We have the date/time for the IRC office hours!
>
> https://www.mediawiki.org/wiki/Project:Calendar#June_2013
>
> Thursday June 20th at 17:00 UTC (10:00am Pacific) in #wikimedia-office
> on Freenode.
>
> Webchat: http://webchat.freenode.net/?channels=wikimedia-office&uio=d4
>
> We plan on having representatives from both submissions in attendance,
> so please come with your questions ready!
>
> Best,
>
> Greg
>
> <quote name="Greg Grossmeier" date="2013-06-13" time="10:16:44 -0700">
>> = Office Hours =
>> Next week we will have a IRC "office hour" with myself and Rob Lanphier
>> and the parties who submitted proposals. This is a time for
>> anyone/everyone to ask questions in real time from both the RFP
>> submitters and of us (WMF/Robla and I). This is yet to be scheduled, but
>> it is looking like Wednesday or Thursday (the 19th or 20th) in the
>> morning Pacific time (around 4 or 5pm UTC).
>>
>> I will send out a note with the final date/time as soon as possible.
>
> --
> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hi
I'm not an audio expert but AFAIK, FLAC is probably the best solution to
store lossless audio streams. Similar to TIFF for pictures.
The difference (with TIFF) is that we don't have FLAC support for now in
Mediawiki... and it seems there is no way at all to upload audio streams
in a lossless format for now.
I have found two related features requests:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=20252
* https://bugzilla.wikimedia.org/show_bug.cgi?id=39867
But both don't have pretty recent comments and don't seem to be actively
followed. My question is: Does someone has a project to fix that point
in a near future?
Regards
Emmanuel
--
Kiwix - Wikipedia Offline & more
* Web: http://www.kiwix.org
* Twitter: https://twitter.com/KiwixOffline
* more: http://www.kiwix.org/wiki/Communication
Hi everyone,
On behalf of Emufarmers, Isarra, and Jack, I'd like to present our proposal
for the release management RfP:
https://www.mediawiki.org/wiki/Release_Management_RFP/EIJL
If you have any concerns or questions we're more than willing to answer
them via email or on the talk page.
Thanks,
-- Legoktm
Earlier this evening I found myself gawking at a strange confusion of
letters and symbols that had appeared in my editor. What are these symbols,
and where do they come from? What secret geometry governs their
arrangement? Just what is this, anyway? I sat and stared, perplexed. The
symbols stared back.
Soon my eyes adjusted to the strange contours of the glyphs, and I began to
perceive a kind of rhythm or a structure to their ordering. Finally, I lit
upon this enchanted hieroglyph:
@file
Of course! That's what this is -- a file! I wept with joy, and my heart
soared with gratitude for this humble Doxygen tag, without which the
ontology of our source code would be occult and irretrievable.
But soon my rapture gave way to creeping doubts: could we not, after all,
do better?
I went to the drawing board. After several iterations (all agile,
naturally), I came up with two tags that I think are very fine and that I'd
like to see us adopt. Consider them:
@tag
This tag denotes a Doxygen tag. Like '@file', it answers the question,
"What is this?". Answer: it is a Doxygen tag. It is not a banana. A car
part, neither. If you thought it was a ceiling fan or a Python decorator,
you were wrong -- dead wrong. Because it is a Doxygen tag.
@comment
This tag denotes a comment. It precisely identifies the purpose and
discourse of the text which surrounds it. It tells you, "There is wisdom
here. Stay a while and listen."
Here is a sample file header, demonstrating proper usage of these tags:
/**
* Example
* This file represents an example.
*
* @file
* @ingroup examples
* @comment
* @tag
*/
The syntax is economical and expressive; the meaning eloquent and germane.
What do you think? Don't worry about the HTML representation for now -- we
can worry about those later.
---
Ori Livneh
ori(a)wikimedia.org
Event Details
# Date: 2013-06-12
# Time: 1700-1800 UTC, 1000-1100 PDT
#IRC channel: #wikimedia-office on irc.freenode.net
The Wikimedia Language Engineering team [1] invites everyone to join the
team’s monthly office hour on June 12, 2013 (Wednesday) at 1700 UTC/1000
PDT in #wikimedia-office. During this session we would be talking about
some our recent activities and updates from the ongoing projects. The
provisional agenda is outlined below.
See you all at the IRC office hour!
Siebrand Mazeland
Product Manager Language Engineering
Wikimedia Foundation
Agenda
# Introductions
# Universal Language Selector - Phase 1 deployment was on Tuesday
2013-06-11 [2,3,4]
# Universal Language Selector - Phase 2 and later
# Q/A - We shall be taking questions during the session. Questions can also
be sent to "siebrand at wikimedia dot org" before the event, and will be
addressed during the office hour.
[1] http://wikimediafoundation.org/wiki/Language_Engineering_team
[2] https://www.mediawiki.org/wiki/Universal_Language_Selector
[3] https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ
[4] https://www.mediawiki.org/wiki/Universal_Language_Selector/Design