On 10.07.2012 15:49, bawolff wrote:
* the parser cache, containing the HTML for every page's content. This cache
uses keys based on the ParserOptions, which includes a field for specifying
the
language. However, currently only a canonical version of the rendered page
is
cached,
On 12.07.2012 20:33, Platonides wrote:
* the parser cache, containing the HTML for every page's content. This cache
uses keys based on the ParserOptions, which includes a field for specifying
the
language. However, currently only a canonical version of the rendered page
is
cached,
Hi all
as a follow up to Jeroens mail, I'd like to give a quick overview of things that
need to happen before we can roll out phase I of Wikidata on the first Wikipedia
(scheduled for late summer). As we are approaching feature completeness, it
becomes increasingly urgent to have a plan for
On 09.08.2012 16:49, Rob Lanphier wrote:
On Thu, Aug 9, 2012 at 6:54 AM, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
* Merging the Wikidata branch (ContentHandler) is still open, see
https://bugzilla.wikimedia.org/show_bug.cgi?id=38622. There has been
no feedback in the last few
On 22.08.2012 15:56, Daniel Friesen wrote:
Where is the discussion and review of ContentHandler?
There is not much discussion going on. There's a slowish conversation I'm having
with Tim on Bugzilla:
On 22.08.2012 19:32, Chris Steipp wrote:
I think you were referring to this bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38622
Oops. Yea, right, thanks.
-- daniel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Hi all
I think it would be extremely useful to allow nested database transactions - or
simulate them using a counter that would only to the actual commit after
commit() has been called as many times as begin() was called before.
This actually used to be the case, according to the comment on
objections?
-- daniel
PS:
--
Daniel Kinzler, Softwarearchitekt
Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de | Tel. (030) 219 158 260
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts
On 24.08.2012 03:14, Aaron Schulz wrote:
SAVEPOINTs are useful if we really need to support people rollback
transactions *and* we need nested transaction support. I think they could be
made to work, but I'm not sold on their necessity for any use cases we have.
So, how would you solve the use
Hi all
Here's a quick update on what has been happening with Wikidata.
After I was off duty last week, I have picked up work on the Wikidata branch
again (aka the ContentHandler stuff). Discussion is happening mostly on
Bugzilla:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38622
I have
On 24.08.2012 18:55, Tyler Romeo wrote:
So, how would you solve the use case I described? What I need to do is to
perform some checks before calling WikiPage::doEdit, and make sure the
result of
the check is still valid when the actual save occurs.
SAVEPOINTs are basically nested
On 28.08.2012 06:16, Aaron Schulz wrote:
I'd have to see what you are doing to see if rollback is really needed.
As far as I see, nested transactions are needed, but no rollback. at least not
from our side.
So, for that case, a simple counter would be sufficient. I still wonder why that
feature
Hello
We have had a pretty productive week with the Wikidata team. The most pressing
issues concerning the Foundation team are however still the same:
The Sites table is pending finalization. It coming along nicely, and I think we
will have a new version early next week. Development is happening
Hi Tim!
For some reason, your mail went under my radar until now. Sorry about that.
On 03.09.2012 03:30, Tim Starling wrote:
I've been busy, but I can do another review of the ContentHandler
branch this week.
That would be great, thanks!
There's the question of what level of quality we
On 07.09.2012 12:22, Denny Vrandečić wrote: Just an idea, but wouldn't Lua
source code make a perfect alternative
content type?
Yes, it would, but it's also a textual content type. These are rather
unproblematic. One thing that is not yet implemented is a highlighter interface
for different
On 07.09.2012 12:29, Daniel Friesen wrote:
Not really much different from the CSS/JS cases we already have.
Except that the current handling of CSS/JS is an inconsistent mess of special
cases in various places of the codebase :)
The trickier stuff will be non-text stuff. Or especially the
On 12.09.2012 08:04, Erik Moeller wrote:
We had an internal tech meeting day today, and among other things,
three speakers presented brief tutorials:
Thank you, that is very helpful!
-- daniel
___
Wikitech-l mailing list
On 21.09.2012 14:07, Denny Vrandečić wrote:
Daniel,
sorry for the previous tone of my answer. Indeed I mixed up the Sites
management RFC, that I was discussing, and your proposal to change the
Sitelinks table. Although they are related, the former does not depend
on the latter.
Whereas I
Hi all!
Since https://gerrit.wikimedia.org/r/#/c/21584/ got merged, people have been
complaining that they get tons of warnings. A great number of them seem to be
caused by the fact the MediaWiki will, if the DBO_TRX flag is set,
automatically start a transaction on the first call to
, Daniel Kinzler wrote:
So, can someone shed light on what DBO_TRX is intended to do, and how it is
supposed to work?
Maybe you should have asked that before you broke it with I8c0426e1.
Well, I did ask about nested transactions on the list. Nobody mentioned the
scheme you describe. Is it documented
On 26.09.2012 02:49, Aaron Schulz wrote:
Perhaps some code could be restructured
in some cases so that the calls at least match, meaning the splitting of
transactions would at least be more deliberate rather than accidental.
I think this is the most important bit here: it should be obvious to
On 26.09.2012 02:08, Tim Starling wrote:
I think that to avoid confusion, begin() and commit() should continue
to issue the queries they are named for.
True. So we'd need start() and finish() or some such.
Your scheme does not appear to provide a method for hooks to release
highly contended
On 26.09.2012 12:06, Asher Feldman wrote:
On Wednesday, September 26, 2012, Daniel Kinzler wrote:
I see your point. But if we have the choice between lock contention and
silent
data loss, which is better?
This isn't really a choice - by default, when a statement in mysql hits a
lock
I have submitted two changes for review that hopefully remedy the current
problems:
* I1e746322 implements better documentation, more consistent behavior, and
easier tracking of implicit commits in Database::begin()
* I6ecb8faa restores the flushing commits that I removed a while ago under the
Hi all!
As discussed last week with Rob, I have no prepared a merge request that
introduces the ContentHandler into MediaWiki core. This is a major building
block for the Wikidata project. I hope the merge will be completed soon, since
this will grow stale fast.
The merge request is here:
On 10.10.2012 11:03, Marcin Cieslak wrote:
Seems the files of maintenance/archives/patch-*content* could need to be
copied to maintenance/postgres/archives
It works for me on mysql, but it is inconsistent in that the db is still
used a varbinary but the description uses an integer.
Yes,
Hi!
I could use some help looking over extensions.
Since the ContentHandler stuff has been merged into the core, several much-used
functions and hooks have been deprecated. I have tried to find and replace all
calls in core, but a lot of extensions are still using the old stuff. They will
still
On 10.10.2012 23:37, Rob Lanphier wrote:
I'm very worried about converting all of the extensions to use new
APIs now. If it turns out we need to revert ContentHandler, this will
make the revert that much more difficult.
I'd rather we remove deprecation warnings for the newly deprecated
Hi!
I have published a draft of how changes on the wikidata repository are going to
percolate to the client wikis:
https://meta.wikimedia.org/wiki/Wikidata/Notes/Percolation
Any feedback would be appreciated!
Of course, we are not starting this from scratch. We are currently implementing
a
Hi!
When designing the ContentHandler, I asked around about whether JS and CSS pages
should be parsed as wikitext, so categories etc would work. The gist of the
responses I got was naw, lets get rid of that. So I did (though PST is still
applied - Tim asked for that at the Berlin Hackathon).
On 05.11.2012 05:43, Tim Starling wrote:
On 02/11/12 22:35, Denny Vrandečić wrote:
* For re-rendering the page, the wiki needs access to the data.
We are not sure about how do to this best: have it per cluster,
or in one place only?
Why do you need to re-render a page if only the language
On 06.11.2012 17:01, Denny Vrandečić wrote:
So, we could go without re-rendering at all, if there is consensus
that this is the preferred solution and that this is better than the
solution we suggested.
Anyone having any comments, questions, or insights?
I already suggested that changes to
On 07.11.2012 00:41, Tim Starling wrote:
On 06/11/12 23:16, Daniel Kinzler wrote:
On 05.11.2012 05:43, Tim Starling wrote:
On 02/11/12 22:35, Denny Vrandečić wrote:
* For re-rendering the page, the wiki needs access to the data.
We are not sure about how do to this best: have it per cluster
are
handled.
Now, the nitty gritty:
On 08.11.2012 01:51, Tim Starling wrote:
On 07/11/12 22:56, Daniel Kinzler wrote:
As far as I can see, we then can get the updated language links before the
page
has been re-parsed, but we still need to re-parse eventually.
Why does it need to be re
On 19.11.2012 17:08, Jeroen De Dauw wrote:
+1. Having a script run that makes pretty arbitrary tags in between actual
releases for extensions that have real releases and associated
tags/branches does not seem helpful at all to me.
It is, however, extremely helpful for those extensions that
Hi all
Today I got a review of Vector's accessibility from an employee of the German
Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB). This
is by no means a full evaluation, just the result of having a casual look. I
visited them with Till and Maria of Wikimedia Germany a
Lars Aronsson schrieb:
What are the plans for increasing this limit? Would it be
possible to allow 500 MB or 1 GB for these file formats,
and maintain the lower limit for other formats?
As far as I know, we are hitting the limits of http here. Increasing the upload
limit as such isn't a
Aryeh Gregor schrieb:
* Categories need to be structured by namespace,
https://bugzilla.wikimedia.org/show_bug.cgi?id=450
* Natural number sorting in category listings,
https://bugzilla.wikimedia.org/show_bug.cgi?id=6948
While we definitly need efficient retrieval by namespace, the default
Aryeh Gregor schrieb:
As soon as you're logged in, you're missing Squid cache, because we
have to add your name to the top, attach your user CSS/JS, etc. You
can't be served the same HTML as an anonymous user. If you want to be
served the same HTML as an anonymous user, log out.
This is a
Robert Rohde schrieb:
Rob,
I'm not completely sure whether or not you are talking about the same
logging infrastructure that leads to our traffic stats at
stats.grok.se [1]. However, having worked with those stats and the
raw files provides by Domas [2], I am pretty sure that those squid
Hi all.
I have wanted to push RC-messages via XMPP for a long time. I have now a working
demo on the toolserver: join enw...@conference.jabber.toolserver.org with any
jabber client to see the human readable part.
The demo works by polling the API, for production use,
Addendum:
I have put some more details about the idea and the demo setup at
http://meta.wikimedia.org/wiki/Recentchanges_via_XMPP.
-- daniel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Tim Starling schrieb:
It's been said (e.g. [1]) that hashing passwords with two rounds of
MD5 is basically a waste of time these days, because brute-forcing
even relatively long passwords is now feasible with cheap hardware.
Indeed, you can buy software [2] which claims to be able to check 90
Artur Fijałkowski schrieb:
2010/8/19 Daniel Kinzler dan...@brightbyte.de:
2) extra channels that include full text, diffs, etc? UDP is a limiting
factor
here. Alternative transport from PHP to the bridge process?
Named pipes? Of course only if PHP can keep named pipe open in
persistent
On 26.10.2010 09:36, Nikola Smolenski wrote:
On 10/26/2010 08:59 AM, MZMcBride wrote:
As Aryeh notes, even those who act in an editing role (rather than in simply
a reader role) don't generally have valuable accounts. The pros you're
talking about are free to use secure.wikimedia.org (which is
It's not that toolserver admins are excentric adding such rule, but an
issue of WM-DE liability if such information is published.
However, I think that providing such file to just a few selected people
would be acceptable.
I think so too, but I have to ask our ED. Will send an email now.
On 04.01.2011 22:39, Brion Vibber wrote:
In order to have a visual editor or three, combined with a plain text
editor, combined with some fancy other editor we have yet to invent, you
will still need that specification that tells you what a valid wiki instance
is. This is the core data; only
On 05.01.2011 05:25, Jay Ashworth wrote:
I believe the snap reaction here is you haven't tried to diff XML, have you?
A text-based diff of XML sucks, but how about a DOM based (structural) diff?
-- daniel
___
Wikitech-l mailing list
Hi all
after some discussion, Wikimedia Germany decided not to hold a developer's
meet-up around the Chapter's conference in March. We just couldn't fit this in
nicely with the venue and the overall organization. Don't despair though:
This is what we will do instead:
* There will be a hackathon
On 17.01.2011 17:14, Asaf Bartov wrote:
Correction: Haifa Hacking Days are to be held August 2nd-3rd.
Wikimania itself will be Aug 4th-6th.
Gah! Thanks Asaf.
There I went and looked it up, and then wrote the wrong thing into the email.
Curses.
-- daniel
On 17.01.2011 19:38, Bryan Tong Minh wrote:
On Mon, Jan 17, 2011 at 5:11 PM, Daniel Kinzler dan...@brightbyte.de wrote:
* There will be a hackathon hosted by Wikimedia Germany in (late) May,
probably
in Berlin, but that's not decided yet. This will mostly about hacking, with a
strong focus
On 17.01.2011 19:53, Ashar Voultoiz wrote:
On 17/01/11 17:11, Daniel Kinzler wrote:
* There will be a hackathon hosted by Wikimedia Germany in (late) May,
probably
in Berlin, but that's not decided yet. This will mostly about hacking, with a
strong focus on GLAM related stuff
Hi all!
I'm coming to San Franscisco to spend a couple of days at the Wikimedia Office
on Feb 7/8. But before that, I have a weekend to spend in SF... well, I might
already have something for Saturday, but Sunday is still free.
So... any recommendations what to do and see? where to hang out in
Thanks for the input everyone!
Roan said:
Have you seen http://wikimediafoundation.org/wiki/Visiting_San_Francisco ?
No, I didn't see that, thanks!
If you like doing hikes, you can do what I did last Saturday and walk
the Land's End Trail.
That sounds like a really good idea. I could use a
Hi all!
what's the best way to get around the same original policy to fetch data from
the toolserver with a XMLHTTPRequest in a Wikipedia gadget? Is there a best
practice, a nice and easy, generally usable method? what would it take to make
one?
I know that some gadgets have been doing this,
Besides some nice extra skins to add to the repo, I need
some examples that break the normal patterns to work with and build as I
rip out the restrictions in the current skin system. And hence I asked
for mockups since such skins are already hard enough that most people
probably would
Hi all!
Wikimedia Germany is again organizing a hackathon in Berlin. It will be in May,
but we have not decided on the weekend yet. So, if you are interrested in
attending the event, please let us know on which dates you *can't* come. We are
especially interrested to know when people around the
On 09.03.2011 09:59, Amir E. Aharoni wrote:
Export to openZIM produced the best result. I read it on the Kiwix
reader for Windows. Directionality was OK, the right font was used for
Hebrew, but a wrong one for IPA (it may have been hard for the
converter to understand it, because in the
.
We’re excited to see you in Berlin, your Hackathon Team
Daniel Kinzler (Program Coordinator)
Nicole Ebber (Logistics)
Cornelius Kibelka (Assistant)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
hi all!
In the hope i'm not clubbing a diseased donkey, i'd like to share an idea i ran
across: we could use the RC4-128 cypher for secure.wikimedia.org, instead of
AES256. RC4 is reportedly a lot faster (3 to 4 times the throughput). Since CPU
capacity for encryption has been mentioned as one of
On 06.04.2011 09:15, Alex Brollo wrote:
I saved the HTML source of a typical Page: page from it.source, the
resulting txt file having ~ 28 kBy; then I saved the core html only, t.i.
the content of div class=pagetext, and this file have 2.1 kBy; so
there's a more than tenfold ratio between
Hi Alex
Thanks Daniel, API stuff is a little hard for me: the more I study, the
less I edit. :-)
Just to have a try, I called the same page, render action gives a file of
~ 3.4 kBy, api action a file of ~ 5.6 kBy.
That's because the render call returns just the HTML, while the API call
Hi all!
Wikimedia Deutschland is offering a contract for implementing the GraphServ
component for our Graph Processor project. Anyone interested is invited to
apply, the official call for bids is at
http://wikimedia.de/wiki/Ausschreibung/GraphServ.
The Graph Processor project aims to develop an
On 14.04.2011 11:10, Siebrand Mazeland wrote:
On 14-04-11 10:02 Daniel Kinzler dan...@brightbyte.de wrote:
Wow, seriously? IE6 should be taken out the back and shot...
You're in luck. These days, even Microsoft agrees with you:
http://www.ie6countdown.com/
Aw man, someone please spoof
.
We’re excited to see you in Berlin, your Hackathon Team
Daniel Kinzler (Program Coordinator)
Nicole Ebber (Logistics)
Cornelius Kibelka (Assistant)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
On 19.04.2011 08:34, Ashar Voultoiz wrote:
You should not add this kind of facebook button on the WMF website. It
is a breach in private life since it tells facebook which website you
are browsing.
...even if you do not click it!
-- daniel
___
On 10.05.2011 20:52, Brion Vibber wrote:
So here at the Wikimedia main office in San Francisco we've got a spiffy
printer upstairs that can churn out large posters, banners, etc (24 / circa
60cm wide). I've been thinking that the walls in Engineering could use some
decoration, and am looking
Hi all!
What is the best way to control load order of JS (or modules modules in
general)? We (WMDE) are developing WikiPraise, a gadget that can show directly
show who contributed which part of a given article revision, as shown to the
user.
WikiPraise works by taking the wikitext annotated
On 11.01.2012 14:12, Thomas Schmidt wrote:
Roan wrote:
I think holdReady is probably the most reliable way to prevent scripts
from messing with your DOM, although I defer to Krinkle for a more
authoritative answer.
Yes, unless they all use that :)
My impression was that it breaks quite a few
Hi Jeroen!
I havn't looked at the details, but I think Page and WikiPage were factored out
of Article only recently (in 1.18 I think) - before that, it was all lumped
together. I guess the interfaces are still in flux, and may be influenced by
trying to be backward compatible. Perhaps try to find
On 10.02.2012 18:04, Jon Davis wrote:
You can configure MediaWiki to use an external SMTP server, I wrote up a
set of instructions on this a while back:
http://snowulf.com/2011/08/30/configuring-mediawiki-to-use-external-smtp/
You can also take a look at the manual for $wgSMTP at
On 12.08.2011 16:36, Roan Kattouw wrote:
I second this notion, meeting up with local Wikimedians in some way,
maybe even inviting them to hang around the venue even if they're not
coders, sounds like a great idea.
Roan Kattouw (Catrope)
From my experience, it works pretty well to invite
Hi Sumana!
Thank you for this very useful summary of the feedback. That goes streight to
our Lessons Learned page :)
And of course a special thanks to you and Guillome for tirelessly hacking the
sessions into etherpad. And of course to Jesse Scott, who took care of the
streaming. We would have
I got some more extensions I'd like to see bundeled:
* Poem. Well, actually, I think support for poem or lines or whatever should
be in core.
* SpamBlacklist and AntiBot. Dealing with spam is one of the main problem of a
young wiki.
-- daniel
___
Hi all!
Ask you may know, there will be an Ask the Developers panel at Wikimania.
However, there are no developers to ask, yet :) To make this work, we need a
few lead WMF developers on the stage, ready to answer questions. So please let
me know if you would be willing to do that, or tell me who
?
-- daniel
On Sat, Jul 30, 2011 at 9:16 AM, Daniel Kinzler dan...@brightbyte.dewrote:
Hi all!
Ask you may know, there will be an Ask the Developers panel at Wikimania.
However, there are no developers to ask, yet :) To make this work, we need
a
few lead WMF developers on the stage, ready to answer
On 01.08.2011 15:50, Russell N. Nelson - rnnelson wrote:
Fish bowl is easy. You have two concentric circles of chairs. The inner
circle are the people speaking. When someone in the inner circle has spoken
their piece, they get up, and somebody from the outer circle can move in.
Less pressure
Hi Robert
As far as I understand, MediaWiki does not use stored procedures, for
compatibility reasons. MediaWiki only requires mysql 4.0, which iirc does not
support stored procedures at all. Also, stored procedures can not (easily) be
ported to other database systems like sqlight.
If you want
On 11.08.2011 11:39, Daniel Friesen wrote:
What are people's opinions on the idea of taking these removed
presentational attributes, and turning them into sugared parts of
WikiText that are output as actual css in the output.
The change would essentially mean that this:
|valign=top
Hi Alisha!
It's quite typical for a bug report to only state in vague / high level terms
what is wrong. If you are lucky, it also describes the expected behavior. If you
are unlucky, it tells you exactly, but wrongly, what to do.
Finding out what code you need to touch to fix the issue is the
Bumping Tim's mail from last week, in case anyone is interested:
In the next RFC meeting we would like to discuss the following RFCs:
* Removing bad database abstractions
tl;dr:
In the xml dumps, I want to change
text sha1 model format
to
model format text sha1
However, this is a breaking change to our XML schema.
See https://bugzilla.wikimedia.org/show_bug.cgi?id=72417
Background:
While trying to fix bug 72361, I ran into an issue with our current XML dump
Am 23.10.2014 16:06, schrieb Daniel Kinzler:
tl;dr:
In the xml dumps, I want to change
text sha1 model format
to
model format text sha1
However, this is a breaking change to our XML schema.
See https://bugzilla.wikimedia.org/show_bug.cgi?id=72417
There is now a patch up for review
Am 27.10.2014 22:08, schrieb Gerard Meijssen:
Hoi,
You may want to wait until the dumps are fixed. Magnus fixed the one but
last dump by hand. The following dump is still broken. Wait until we KNOW
the dumps are ok.
Gerard, what exactly do you mean? The only problem I know of is the fact that
Am 27.10.2014 21:58, schrieb Ariel T. Glenn:
Thank you Google for hiding the start of this thread in my spam folder
_
I'm going to have to change my import tools for the new format, but
that's the way it goes; it's a reasonable change. Have you checked with
folks on the xml data dumps list
Hi all!
It seems that during the current efforts to modernize the API, the default
language (as represented by $wgLang) was changed to always be the content
language [1][2] instead of the user language. This may not be a problem for most
of the core modules, but broke some essential wikibase API
Am 04.11.2014 16:26, schrieb Brad Jorsch (Anomie):
The disadvantage of using the user language is that it reduces
cacheability: all responses have to be marked anon-public-user-private
instead of public where public would otherwise be allowed. True, there are
a number of other reasons that an
Hi all!
I'd like to get some input on a tricky problem regarding caching in memcached
(or accelerator cache). For Wikidata, we often need to look up the label (name)
of an item in a given language - on wikidata itself, as well as on wikis that
use wikidata. So, if something somewhere references
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
Am 04.12.2014 22:46, schrieb Chad:
On Thu Dec 04 2014 at 1:41:43 PM Daniel Kinzler dan...@brightbyte.de
wrote:
https://www.mediawiki.org/wiki/Requests_for_comment/
Drop_actions_in_favour_of_page_views_and_special_pages
This is a proposal to move away from action= in favor of Special pages
So, Chad wants to talk about getting rid of actions.
Anyone want to discuss any of the other RFCs?
If not, how about we just declare them closed/stalled/abandoned or whatever?
-- daniel
Am 04.12.2014 22:41, schrieb Daniel Kinzler:
Hi all!
The Architecture Committee, and especially Tim, has
Am 09.12.2014 17:41, schrieb rupert THURNER:
Not sure who is allowed to comment here, so I hope mentioning a +1 to the
ones which I understand sufficiently and like might be okay.
Anyone show is interrested in dicussing an RFC can chime in here. If you are
willing to *work* on an RFC, please
Am 10.12.2014 02:11, schrieb MZMcBride:
Daniel Kinzler wrote:
Anyone want to discuss any of the other RFCs?
If not, how about we just declare them closed/stalled/abandoned or
whatever?
Why? It's unclear to me what this would accomplish.
If there is nobody to discuss it, and nobody to work
I think that'S around the time we started tracking properties using the
CommonsMedia data type as image links (which they effectively are, even though
we currently don't embed the images on the page). These entries would show in
imagelinks only after the item was edited again, so the grows would
Am 20.01.2015 um 17:34 schrieb Brion Vibber:
Quick update:
I've had a great experience working on our mobile apps, but it's time to
get back to core MediaWiki and help clean my own house... now that we've
got Mobile Apps fully staffed I'm leaving the mobile department and will be
reporting
Hi Legoktm et al!
Thanks for filing the RFC. We have started to track RFCs on Phabricator now - as
I can see, you have already created a ticket. Excellent! I have cross-linked it
from the wiki page now. Since you asked for comments and feedback, I have put
the ticket on the to discuss column of
Am 21.02.2015 um 13:14 schrieb Marielle Volz:
That's what I was going to do originally, but then I looked at my profile
picture on en wiki[1] I saw this message:
Do not copy this file to Wikimedia Commons.
While the license of this image or media file, uploaded and used on (a)
Wikipedia
Can I just agree with everything Brian just said?
+1 :)
Am 08.04.2015 um 23:50 schrieb Brian Wolff:
To be nitpicky, not only is it possible to combine rc with wikipages,
its
been supported (and mostly unused) for ages in the form of
special:recentchangeslinked. More structured lists could be
The European time is off: CEST is UTC+2, so that would mean the IRC meeting
starts at 23:00.
Am 15.04.2015 um 04:59 schrieb Tim Starling:
* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 22:00
* Australia AEST: Thursday 07:00
Am 05.08.2015 um 13:21 schrieb Tim Starling:
In the next RFC meeting, we will discuss the following RFC:
* Streamlining Composer usage
https://www.mediawiki.org/wiki/Requests_for_comment/Streamlining_Composer_usage
Hm... Jan is on vacation, do you know if he's aware of this happening? I
201 - 300 of 576 matches
Mail list logo
