The boxes that are on a wikipedia-page on the top right hand corner
generally, as I have seen are created by using templates Infobox or
Navbox. Are there any other templates which can result in such a box?
Thanks
Priyank
Hello everybody!
At my company we develop extensions for MediaWiki. We use the "LoadExtensionSchemaUpdates" hook to create tables with the "maintenance/update.php" script.
Recently we faced the question whether it is possible to have stored procedures/functions in an extensions SQL-File, or not. We tried it out and it didn't work for us. The update.php says we've got an error in the SQL syntax, but there isn't one.
Can anybody help us? Is it possible to provide stored procedures to the database using the update.php? Is there an example anywhere? Thx.
Greetings,
Robert Vogel
Social Web Technologien
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH
___________________________________
Untere Bachgasse 15
93047 Regensburg
Tel. +49 (0) 941 - 56 95 94 98
Fax +49 (0) 941 - 50 27 58 13
www.hallowelt.biz
vogel(a)hallowelt.biz
Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani
In order to be able to have time to clean up the default assignments in
Bugzilla, I've put my weekly triage on hold this week and last week.
The rationale behind this cleanup is to avoid Cookie Licking
(http://communitymgt.wikia.com/wiki/Cookie_Licking) and make it easier for
people to find work that has been requested but isn't being worked on.
(Many thanks to Sumana for introducing me to the term.)
At the end of this process, my hope is that the assignments in Bugzilla
will actually reflect work that people intend to complete. I'm
restricting the changes to components that relate to Wikimedia sites
(Wikipedia, Wiktionary, Wikinews, Wikisource, etc.)
As part of these changes, I'm asking people who've been assigned bugs
because of the default assignments to review the list of bugs that they
are currently assigned. If you've been assigned any bugs by default, I
will email you a list of bugs and ask you to respond by telling me which
assignments you would like to keep because you intend to work on them
in the not-to-distant future.
If I do not receive a response by August 15th, I’ll assume that you
don't intend to work on any of the bugs and remove you from those in the
list I send you.
Again, note that I'm only doing this on components used on Wikimedia and
for bugs where the current assignee was the default assignee. If you
found a bug and “took” it by assigning yourself, I should not be
contacting you about it.
Your help in this is much appreciated.
Thanks,
Mark.
[If this ends up on the list twice, it is because I'm sending it again
through my own mail server since Google's Gmail shows it as sent two
hours ago, but it hasn't shown up in the list archives yet.]
Yesterday I came across this feature request, which I promptly
mis-understood:
https://bugzilla.wikimedia.org/30018
Option to make access to specific user rights or user groups
dependent on having a verified email address
The requester clarified the request today:
There's relatively little benefit to making people provide a
verified email address at one point time. On long-lasting wikis,
verification might have been 5-10 years ago. The aim of this bug is
to make user rights dependent on a verified email address *on an
ongoing basis*.
So for example if the user removes the email address, or replaces it
with another but doesn't verify it, the user rights associated with
their user group are automatically suspended, until a verified email
address is provided, when they're automatically re-enabled.
This would be more useful if there are situations where the
"verified" status of an existing email address can be automatically
revoked (eg if emails to the user bounce); I'm not sure if that's
the case but if it isn't that's a separate issue.
I'm fascinated by the idea and can see arguments both ways. I thought
I'd bring it up here to see if anyone could help me think through it.
Thanks,
Mark.
Hello,
Wikimania is just next week, but two months from now will be another
conference that may be of interest to MediaWiki users and developers:
SMWCon, or the Semantic MediaWiki Conference, which will be happening in
Berlin on September 21-23:
http://semantic-mediawiki.org/wiki/SMWCon_Fall_2011
Semantic MediaWiki, if you don't know about it, is a MediaWiki extension
that has somewhat taken on a life of its own in the six years since it was
first created:
http://semantic-mediawiki.org/wiki/Semantic_MediaWiki
Though of course the main focus will be Semantic MediaWiki, we plan to have
talks on other related topics, like DBpedia, ontologies, and the creation of
a semantic data repository (not necessarily SMW-based) for Wikipedia itself.
And there's definitely room in the schedule for talking about issues related
to core MediaWiki.
This is a call for presentations, so if you want to attend, please consider
giving a talk. To propose a talk, just add a line to the wiki page here:
http://semantic-mediawiki.org/wiki/SMWCon_Fall_2011#Conference_days
And while we're at it, if you plan to attend SMWCon, please add your name to
the attendees list, here:
http://semantic-mediawiki.org/wiki/SMWCon_Fall_2011#Registration
-Yaron
All,
Please join me in welcoming Ben and Daniel to Wikimedia Foundation.
Both Ben and Daniel are joining the Technical Operations team to help us to
build, improve, scale and support our web systems and infrastructure.
Ben, who is based in SF office, comes with a broad set of expertise and
experiences in Systems Engineering and Operations, in particular, scaling
the systems and creating tools to manage large number of servers. While his
initial focus is on database and analytics systems, he will also be working
on our new distributed (with redundancy and scalable) file system and
getting the infrastructure in the new datacenter into full production.
He comes to WMF from Linden Lab, makers of Second Life, where he was first a
member, then a manager of the Systems Engineering team. The group was
responsible for maintaining the thousands of servers that power the Second
Life grid as well as the development, QA, and staging environments. In
addition to maintaining the grid, the SE team at Linden was instrumental in
helping the engineering group design systems and services in a way that
would scale easily and fail safely, increasing reliability and uptime for
the service as a whole. He is eager to learn new approaches to managing
large numbers of servers with few people effectively, and would be happy to
talk about how things work at Linden Lab for comparison. Prior to Linden,
Ben helped grow Simply Hired from a 5-computer stealth startup to a
600-server company with millions of page views per month.
Ben also enjoys adventure wherever he can find it, whether local or
foreign. Travel, photography, cooking, backpacking, etc all keep swallowing
up whatever time is left over. He was married last October and loves having
a fish monger, baker, butcher, and vegetable market all within walking
distance in the North Berkeley neighborhood where he lives.
Daniel will initially be working out of from Cologne, Germany and he will be
commuting to Amsterdam sporadically to work on our data center there.
Previously, he has worked as a system administrator for OnVista
Media, Ligatus, and Host Europe, managing and supports hundreds of servers.
Daniel is also an active Wikipedian. He made his first edit on en.wp in Apr
2002, but spends most of his time on en.wikt. where he has been an
administrator since 2008 and focuses on adding German words and
categorization. He also maintains a statistics site about Mediawikis at
http://s23.org/wikistats/. His global account name and IRC handle is
"mutante" (cloak wiktionary/Mutante) while his WMF username is "dzahn".
Daniel has a daughter living here in the Bay Area and has taken her to visit
our office last year. Besides speaking his native German tongue, he speaks
English, French and a little "ksh" (Kölsch / Ripuarian).
Thanks,
CT
Hi,
Currently ParserFunctions have no notion about variables, which
resulting in lots of typing and lots of braces, for example:
{{ #ifexpr: {{ #var: a }} + {{ #var: a }} > 4 | ... }}
I always wanted #expr and #ifexpr functions recognize variables so I can
write
{{ #ifexpr: a + a > 4 | ... }}
Attached patch implements this integration between ParserFunctions and
Variables.
Changes summary:
1. When if a word is a not predefined expression word (like `pi' or
`trunc'), it is checked whether Varaibles extension enabled and whether
such a variable exists. If variable exists, its value used.
2. New error message introduced: "Unexpected variable".
3. Second parameter added to ExprParser::doExpression, parser — it is
required by Variables (though it is not actually used). For
compatibility with older code, parameter is optional.
4. Variables extension is not required, if Variables extension is not
enabled, ParserFunctions does not recognize variables but does not issue
errors.
I have access to SVN. If the patch is generally ok, I can commit it.
Thanks,
Van.