On Wed, Oct 17, 2012 at 3:46 PM, Brion Vibber br...@pobox.com wrote:
I've made a modest initial stab at MobileFrontend support for using
ResourceLoader directly, using a 'target' filtering technique that we
discussed with Trevor, Roan, and Timo. This is another step in integrating
I've made a modest initial stab at MobileFrontend support for using
ResourceLoader directly, using a 'target' filtering technique that we
discussed with Trevor, Roan, and Timo. This is another step in integrating
MobileFrontend/SkinMobile into the core MediaWiki ecosystem.
Once we're happy with
On Wed, Oct 3, 2012 at 10:10 AM, Chad innocentkil...@gmail.com wrote:
On Wed, Oct 3, 2012 at 1:00 PM, Antoine Musso hashar+...@free.fr wrote:
Can we please disable Pull requests until we agree on a workflow to
review those or have them automatically sent to Gerrit?
There is no way to do
On Wed, Oct 3, 2012 at 10:29 AM, Chad innocentkil...@gmail.com wrote:
Yeah, that sounds sane. Anyone who wants to volunteer to keep an eye
on Github and make sure patches get into Gerrit, let me know and I'll add
you to the group on Github.
Crap, I think I just volunteered. ;)
-- brion
On Sun, Sep 23, 2012 at 7:59 PM, Brion Vibber br...@pobox.com wrote:
I've updated the patch to use the 'srcset' attribute as defined in the
current HTML 5 working group version, only using the density options and
not the width/height options:
http://www.whatwg.org/specs/web-apps/current-work
On Thu, Sep 20, 2012 at 12:42 PM, Krinkle krinklem...@gmail.com wrote:
I suggest we built-upon or write or own module further and integrate the
lazy-load principle. In other words, on document ready fix the images
above
the fold, which may or may not have started downloading yet.
Then
On Wed, Sep 19, 2012 at 1:20 AM, aude aude.w...@gmail.com wrote:
On Wed, Sep 19, 2012 at 7:02 AM, Jon Robson jdlrob...@gmail.com wrote:
In terms of supporting non-standard files - there is no reason why to get
an obscure size e.g. 224px you could get for example the 240px image and
resize
How to load up high-resolution imagery on high-density displays has been an
open question for a while; we've wanted this for the mobile web site since
the Nexus One and Droid brought 1.5x, and the iPhone 4 brought 2.0x density
displays to the mobile world a couple years back.
More recently,
On Tue, Sep 18, 2012 at 9:38 AM, Trevor Parscal tpars...@wikimedia.orgwrote:
In VisualEditor we ended up putting all CSS rules that include images in
*.icons-raster.css and *.icons-vector.css files, which are loaded
dynamically based on the window.devicePixelRatio property.
It has it's
On Tue, Sep 18, 2012 at 10:15 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
Sending more data to primarily empower mobile devices sounds rather
counter-intuitive
Amount of data, and *when that data comes in*, are distinct things. One
other change we've got brewing up for the mobile
On Tue, Sep 18, 2012 at 10:22 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
I hate derailing threads, bit doesn't the mobile skin already do this
Nope.
I
always notice fast loading of articles on my cell phone, and slow section
opening (I figured it was quite clever to defer
On Tue, Sep 18, 2012 at 10:19 AM, Trevor Parscal tpars...@wikimedia.orgwrote:
It's important to separate supporting retina display mobile and desktop
devices. Apple's web site uses the load both method to show off the retina
display MacBook - which is more likely to have a faster internet
On Tue, Sep 18, 2012 at 12:31 AM, Brion Vibber br...@pobox.com wrote:
Here's my first stab:
https://bugzilla.wikimedia.org/show_bug.cgi?id=36198#c6
https://gerrit.wikimedia.org/r/#/c/24115/
I've made a couple changes in patchset 2:
* fix for images that specify width but not height (whoops
On Fri, Aug 31, 2012 at 12:08 AM, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
Done in true developer style [RFC] MediaWiki Foundation:
https://www.mediawiki.org/**wiki/Requests_for_comment/**
MediaWiki_Foundationhttps://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation
On Wed, Sep 5, 2012 at 2:00 PM, Roan Kattouw roan.katt...@gmail.com wrote:
On Wed, Sep 5, 2012 at 12:35 PM, Asher Feldman afeld...@wikimedia.org
wrote:
Browser scaling is also at least worth
experimenting with. Instances where browser scaling would be bad are
likely instances where the
On Mon, Sep 3, 2012 at 9:50 AM, Jeroen De Dauw jeroended...@gmail.comwrote:
So what was the error?
Non-existing field or table. Happens because of not running update.php.
Getting some weird type error at some random location does not really
suggest that though, so is likely result into one
On Sun, Sep 2, 2012 at 8:25 PM, Thomas Dalton thomas.dal...@gmail.comwrote:
On Aug 31, 2012 11:52 PM, Brion Vibber br...@pobox.com wrote:
* Definitely don't have left right or center options.
Can you elaborate on that? The positioning of images can make a big
difference to how a page
On Fri, Aug 31, 2012 at 7:36 AM, Ariel T. Glenn ar...@wikimedia.org wrote:
So there are some things we could change:
1. We could generate and keep only certain sizes, tossing the rest.
Heck yes. Generate some standard sizes at upload time and let the browser
scale if a funny size is
On Fri, Aug 31, 2012 at 3:52 PM, Daniel Zahn dz...@wikimedia.org wrote:
Maybe we could have large,medium,small etc as aliases for
standard/popular sizes to encourage using less of the non-standard
ones?
I kinda like this. It would also be nice if simply including an image
defaulted to some
On Fri, Aug 31, 2012 at 4:25 PM, Daniel Zahn dz...@wikimedia.org wrote:
Also wondering if there are any thumbnails that are larger than their
actual images, and if yes to get rid of them.
For raster image formats, we don't generate thumbs larger than the original
-- we just use the original
On Fri, Aug 31, 2012 at 5:52 PM, Brion Vibber br...@pobox.com wrote:
Note that in mobile/tablet contexts it's also very handy to be able to
extract just the photos and provide them for separate browsing; this has
influenced my thinking on this for sure.
^ in particular, distinguishing
On Fri, Aug 31, 2012 at 6:17 PM, Bartosz DziewoĆski matma@gmail.comwrote:
Please don't. The current syntax is nice, concise, consistent and not
overflowing with special characters. The proposed one is verbose and
looks technical.
The current syntax is actually hard to machine-parse, with
On Fri, Aug 31, 2012 at 9:31 PM, David Gerard dger...@gmail.com wrote:
On 1 September 2012 00:38, Brion Vibber br...@pobox.com wrote:
The current syntax is actually hard to machine-parse, with lots of
language-specific overrides and weird options that combine in non-obvious
ways
On Wed, Aug 29, 2012 at 2:55 PM, Chris Steipp cste...@wikimedia.org wrote:
As mentioned in those bugs, mediawiki support a basic CORS
implementation already. It looks like we haven't authorized any domain
for wmf projects though.
Looks like Roan is taking charge on it on bug 20814, yay. :)
On Wed, Aug 29, 2012 at 6:03 PM, Alex Brollo alex.bro...@gmail.com wrote:
Ouch this is a little bit above my skill understanding (really I
discovered AJAX not far ago). . Where can I find some examples of API
inter-project data exchage wth callback parameter?
I.e: I'd like to get the
On Thu, Aug 23, 2012 at 1:37 PM, Daniel Kinzler dan...@brightbyte.dewrote:
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
On Thu, Aug 23, 2012 at 2:02 PM, Evan Priestley epriest...@phacility.comwrote:
We solve this in Phabricator by using BEGIN (depth 0) or SAVEPOINT (depth
1+) when incrementing the counter, ROLLBACK TO SAVEPOINT (depth 1+) or
ROLLBACK (depth 0) when decrementing it after a failure, and nothing
of other projects using GitHub, such as Apache
Cordova (PhoneGap) which hosts on Apache git servers but takes a lot of
contributions through forks on their GitHub mirror.
Having an official GitHub presence just makes sense.
-- brion vibber (bvibber @ wikimedia.org / brion @ pobox.com
On Fri, Jul 27, 2012 at 10:59 AM, Chad innocentkil...@gmail.com wrote:
On Fri, Jul 27, 2012 at 1:55 PM, Chris McMahon cmcma...@wikimedia.org
wrote:
I realize this is all hand-wavy and stuff, but as Brion pointed out, it's
all git. With some thought behind the design, a two-way integration
On Wed, Jul 18, 2012 at 12:24 PM, Meghan Mahar meghan.ma...@appian.comwrote:
I currently have a set of internal users for our wiki that have
Administrator access. I also have a set of external users (our customers)
that can only read pages and create discussion pages.
I would like to remove
On Wed, Jul 11, 2012 at 7:16 AM, Andre Klapper andre_klap...@gmx.netwrote:
Barring any changes like that, I'd prefer to keep the keyword, and ask
that the new Bug Wrangler help keep the upstream keyword up-to-date.
For issues that do have the keyword, it's handy shorthand that has
saved
On Wed, Jul 11, 2012 at 10:40 AM, Aran a...@organicdesign.co.nz wrote:
I'm just wondering how to clone an extension for a particular branch...
e.g. using Subversion I could do this:
svn co
http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_18/extensions/CheckUser
What's the
On Wed, Jul 11, 2012 at 10:51 AM, Brion Vibber br...@pobox.com wrote:
This is pretty much the same as doing 'git clone' followed by 'git branch'
s/branch/checkout/
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
On Tue, Jul 10, 2012 at 10:15 AM, jida...@jidanni.org wrote:
Just hit many CTRL++ in Firefox 15.
re: http://en.wikipedia.org/wiki/Language_family#See_also
This is an example of poor, non-scalable layout by wiki authors -- the kind
of thing that often messes up mobile view, but can happen on
On Thu, Jun 28, 2012 at 4:13 AM, Derric Atzrott
datzr...@alizeepathology.com wrote:
I just wonder: Why do we not simply transmit the SVG image, but render a
png for an SVG-file to the browser? Historic reasons?
I think it is because there is no good way for us to know if a browser
supports
On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklem...@gmail.com wrote:
So, stripping inline styles:
* will not fix bad layouts made with tables (which are probably at least as
common as bad layouts made with inline styles).
* will break unrelated things, because inline styles are not directlty
On Mon, Jun 25, 2012 at 7:45 AM, Derric Atzrott
datzr...@alizeepathology.com wrote:
How do you format dates according to user preference in Mediawiki? I
presume it has something to do with DateFormatter
(http://svn.wikimedia.org/doc/classDateFormatter.html), but I'm not 100%
sure how to
In my experience, the bots in the channel are an important part of our
workflow -- new bug reports, bug updates, and patches in gerrit. When I'm
discussing things in #wikimedia-dev I usually end up having to manually add
references to something that a bot already sent to #mediawiki, which is one
Well, the future is here -- Apple is now shipping a laptop with a
high-resolution 2880x1800 screen (MacBook Pro with Retina display),
optimized for a sharper display at traditional screen sizes. I have one
here on my desk and oh, is that screen beautiful. :)
We can reasonably expect such displays
On Mon, Jun 18, 2012 at 4:43 PM, Platonides platoni...@gmail.com wrote:
My concern are images inside articles, where a big screen user will want
|500px but a small screen one |120px.
Maybe we should move to a size specification dependant on the clientWidth.
That's really a separate issue,
On Mon, Jun 18, 2012 at 4:44 PM, David Gerard dger...@gmail.com wrote:
On 19 June 2012 00:30, Brion Vibber br...@pobox.com wrote:
warning: patent politics question may lead to offtopic bikeshedding
Additionally there's the question of adding H.264 transcode *output*,
which
would let us
On Thu, Jun 14, 2012 at 12:19 PM, Jon Robson jdlrob...@gmail.com wrote:
Another approach to consider for IE6/7 users is where it makes sense ship a
stylesheet which hides everything other than the content. I believe
Wikipedia should be accessible to all regardless of their browser choices.
On Wed, Jun 6, 2012 at 1:45 AM, Bergi a.d.be...@web.de wrote:
But I thought there was a possibility to push to our repository without
using Gerrit / being affected by Gerrit at all?
I can understand that Gerrit is a nice review tool which is useful for the
production and master branches, but
On Sat, Jun 2, 2012 at 1:03 AM, Arthur Richards aricha...@wikimedia.orgwrote:
*View-specific functionality*
Different view types will likely have different bits of functionality that
they require, separate from the rest of MW, that may not make sense to
exist in a Skin. We could allow
On Sat, Jun 2, 2012 at 2:06 PM, Platonides platoni...@gmail.com wrote:
We *must* hide them only with CSS. Remember that if the user clicks
print without going first to printable version, we shall show them all
the references.
Printable version is just a way to show in screen something
On Sun, May 20, 2012 at 2:59 PM, Brion Vibber br...@pobox.com wrote:
Ok, updated patchset at https://gerrit.wikimedia.org/r/#/c/7832/
Thoughts? Worth adding more structure or is this good enough?
I'll assume this is ok for now since no one objects. :) Anybody want to
help review
We've pushed some updates to UploadWizard, most notably:
* disabled multiple-file selection in browsers where it didn't work
* files now start uploading immediately when selected (this can be disabled
server-side if there are problems with it)
* improved category input fields
* 'skip tutorial'
On Thu, May 17, 2012 at 8:36 AM, Platonides platoni...@gmail.com wrote:
I don't think it should contain all campaign parameters as a single tag,
as parameters.
Specially evil is the licensesOwnWork=cc-by-sa-3.0|cc-by-3.0|cc-zero.
The data's stored as a bunch of simple key-value pairs,
On Sun, May 20, 2012 at 2:17 PM, Platonides platoni...@gmail.com wrote:
On 20/05/12 23:10, Brion Vibber wrote:
On Thu, May 17, 2012 at 8:36 AM, Platonides platoni...@gmail.com
wrote:
I don't think it should contain all campaign parameters as a single tag,
as parameters.
Specially evil
Ok, updated patchset at https://gerrit.wikimedia.org/r/#/c/7832/
Thoughts? Worth adding more structure or is this good enough?
JSON output looks like this (config portion is now optional, leave it out
to just get a list of campaigns):
{
uploadcampaign: {
campaigns: [
I'm adding an API module to retrieve UploadWizard upload campaign
information, which we need for the upcoming mobile application for Wiki
Loves Monuments. Essentially the app will include a very limited
implementation of a couple steps of UploadWizard for things like license
selection and filling
On Mon, Apr 23, 2012 at 2:46 PM, Ryan Kaldari rkald...@wikimedia.orgwrote:
I would like to second what Platonides has said. It's important to
understand that 99% of the inline CSS comes from templates. Stripping the
CSS is probably not a good option, as the results would be rather
On Thu, Apr 19, 2012 at 10:11 AM, Thehelpfulone thehelpfulonew...@gmail.com
wrote:
On 17 April 2012 22:04, Brion Vibber br...@pobox.com wrote:
Is there a schedule for the 1.19 release?
Is
http://www.mediawiki.org/wiki/MediaWiki_1.19/Roadmap#Deployment_schedule
what
you are looking
On Thu, Apr 19, 2012 at 7:57 AM, Jon Robson jrob...@wikimedia.org wrote:
Solutions I have thought about so far involve the following. I am yet
to conclude on which is the best way to do this so would really
appreciate discussion...
1) scrubbing all inline styles
You mean removing them?
I've started adding some documentation on chunked uploading via the API on
mediawiki.org:
https://www.mediawiki.org/wiki/API:Upload#Chunked_uploading
This info is based on watching UploadWizard at work, and may be incomplete
or misleading. :) So please feel free to hop in and help clean it up,
Is there a schedule for the 1.19 release?
It seems we're already rolling out 1.20 in production, so normally we'd
expect 1.19 to be done and out the door already. :)
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Tue, Apr 17, 2012 at 2:58 PM, Erik Moeller e...@wikimedia.org wrote:
MathJax is now enabled as an experimental math rendering mode on
MediaWiki.org (thanks, Aaron).
To enable it, select it in your preferences under Appearance.
Awesome -- this confirms that it does work, including the web
On Mon, Apr 16, 2012 at 12:26 PM, Erik Moeller e...@wikimedia.org wrote:
On Wed, Mar 7, 2012 at 1:05 PM, Brion Vibber br...@pobox.com wrote:
In the last few days I've updated the Math extension's experimental
MathJax
support to where it can actually be enabled by individual users. If all
On Wed, Apr 11, 2012 at 6:50 AM, Chad innocentkil...@gmail.com wrote:
That's weird, Sam went ahead and copied GeSHi into the repo in
43764e3[0]. I haven't tested it personally--is it working on test2
and mw.org?
Looks ok to me, works locally... and the ext does work on mediawiki.org so
On Wed, Apr 11, 2012 at 12:27 AM, Kim Eik k...@heldig.org wrote:
I have created a patch for the gallery tag and have been given the
following review.
https://gerrit.wikimedia.org/r/4609
* JavaScript injection: you can inject javascript: URIs which execute
code when clicked
* plain links
On Wed, Apr 11, 2012 at 11:18 AM, Daniel Renfro dren...@vistaprint.comwrote:
I'd like to get some input on configuring the caching-strategy for my
Mediawiki installation.
As I understand it, APC caches the PHP byte-code to improve on webserver
performance, but can also store sessions and
On Tue, Apr 10, 2012 at 3:46 PM, Rob Lanphier ro...@wikimedia.org wrote:
Hi everyone,
Sam has created the wmf/1.20wmf1 branch and deployed it to
test2.wikipedia.org and mediawiki.org. So, please, go for and test!
Woohoo!
Deployment from git working so far, this makes me happy. :)
--
On Thu, Apr 5, 2012 at 10:34 AM, Jon Robson jrob...@wikimedia.org wrote:
The best way to balance all the pros/cons is to load the chrome+first
paragraph as fast as possible. *Then* load all subsequent sections
asynchronously *while* the user is reading the first section. That way we
have
One thing I've noticed in the last couple of days of madly reviewing things
in gerrit is that merge conflicts in the RELEASE-NOTES-1.20 file are very
common.
Because of the delay between submission and post-review merge, there's a
high probability that a new entry in one of the sections of
On Wed, Mar 28, 2012 at 10:33 AM, Daniel Renfro dren...@vistaprint.comwrote:
$img = wfLocalFile( $title );
$params = array(
'width' = 100,
'height' = 100,
);
$thumb = $img-transform( $params );
// dump some output to test things
var_dump(
$img-createThumb( 100 ),
On Sun, Mar 25, 2012 at 3:24 PM, Brion Vibber br...@pobox.com wrote:
I've started on a MediaWiki extension to assist in fetching extensions as
well, stealing a couple bits from that script. :)
Since I haven't yet fully grokked setting up new exts in gerrit it's
sitting on github
I'm generally in favor of this plan. I haven't looked over the specific
code experiments yet but the plan sounds solid. A few notes:
* over time we'll want to do things like migrate File: pages from 'plain
wikitext that happens to have an associated file' to 'structured data about
a file'. This
On Thu, Mar 22, 2012 at 1:53 PM, Arthur Richards aricha...@wikimedia.orgwrote:
Cool thanks Platonides! I was wondering about something like this
yesterday. I appreciate the irony of that script living in SVN :p
I've started on a MediaWiki extension to assist in fetching extensions as
well,
I kinda like the first model (it feels more organic), but the second has
the advantage that you've got a previous branch to revert to quickly if
needed. That's a plus for deployment work.
-- brion
On Mar 22, 2012 12:44 PM, Rob Lanphier ro...@wikimedia.org wrote:
Hi everyone,
This email is
On Mar 19, 2012 8:44 PM, Daniel Friesen li...@nadir-seen-fire.com wrote:
CSS image fallbacks may be a little annoying.
Last time I checked browsers don't consider I don't understand that
image filetype. an invalid url(). In other words in:
background-image: url(foo.png);
background-image:
On Tuesday, March 20, 2012, David Gerard dger...@gmail.com wrote:
On 20 March 2012 19:06, Ian Baker i...@wikimedia.org wrote:
* WebM (aka VP8) is really not bad, but is technically inferior to h.264
Main and High Profiles[1].
This comparison appears specious in the context of this thread,
I've been fiddling with a new iPad, with its notoriously high-resolution
display (2048x1536, roughly similar to the iPhone 4's earlier 2x resolution
jump on the small screen but on something real sized). Text renders
stunningly sharp. And you know what else?
SVG.
Graphics.
Look.
Totally.
As some may know, we've restricted videos on Wikimedia sites to the
freely-licensed Ogg Theora codec for some years, with some intention to
support other non-patent-encumbered formats like WebM.
One of our partners in pushing for free formats was Mozilla; Fire fox's
HTML5 video supports only
On Thu, Mar 15, 2012 at 12:05 PM, Asher Feldman afeld...@wikimedia.orgwrote:
Replacing this with a desktop view that leaves users permanently
accessing the desktop site via m. isn't suitable for our environment. It
may make sense for smaller sites without a dedicated mobile namespace but
On Thu, Mar 15, 2012 at 2:29 PM, Arthur Richards aricha...@wikimedia.orgwrote:
Asher and I just had a chat in #wikimedia-mobile. We agreed to have the
Squids handle the new cookie in the same way they handle the old
'stopMobileRedirect' cookie (rather than add back the old
'permanently
On Tue, Mar 13, 2012 at 3:32 PM, John Erling Blad jeb...@gmail.com wrote:
So, since we're discussing SAML and OAuth and OpenID, and such, I
should mention this:
http://simplesamlphp.org/
It supports SAML, OpenID, OAuth, it's extendable and it supports
multiple backends (LDAP,
On Fri, Mar 9, 2012 at 1:48 AM, Strainu strain...@gmail.com wrote:
Here's a sample page on a test wiki, copied from en.wikipedia:
http://leuksman.com/mw/index.php/Alpha_compositing
Yes, but... is it just me or it takes at least 5s to load the
formulas? I have a pretty decent computer,
On Thu, Mar 8, 2012 at 1:24 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
Hey,
$file = wfFindFile( 'Foobar.jpg' );
$thumb = $file-transform( array( 'width' = 200 ) );
if ( $mto !$mto-isError() ) { $url = $mto-getURL(); } else { /*
Handle error */ }
I tried your code, and now all my
In the last few days I've updated the Math extension's experimental MathJax
support to where it can actually be enabled by individual users. If all
goes well with review I'd love to get this deployed soon so the math-heads
can turn it on and check for lingering incompatibilities...
MathJax
On Sun, Feb 19, 2012 at 5:49 AM, Sumana Harihareswara suma...@wikimedia.org
wrote:
On 02/19/2012 01:10 AM, John Erling Blad wrote:
Some of the urls to Wikipedia will fail when converted by the
mechanism in Twitter, so you either must use the ugly url in the tweet
or use a short url.
On Fri, Feb 17, 2012 at 6:57 PM, Mark A. Hershberger
mhershber...@wikimedia.org wrote:
* Bug 34458: Editing fails in IE7
https://bugzilla.wikimedia.org/34458
This is has evidently been around a while so we don't *need* to block
any deployments, but it would be nice to fix it
This
On Tue, Feb 21, 2012 at 12:03 AM, Rob Lanphier ro...@wikimedia.org wrote:
== Important to figure out, but not blocking ==
http://bugzilla.wikimedia.org/34458 -- Editing fails in IE7
This one is no longer being reproduced and I've closed it out, but other JS
errors reported on the same bug
On Tue, Feb 21, 2012 at 12:03 AM, Rob Lanphier ro...@wikimedia.org wrote:
http://bugzilla.wikimedia.org/34504 -- [Regression] There should not
be a mismatch between html and stylesheet version
There is now a fix waiting for merge deployment on this. A change to CSS
wasn't
I'm still a bit leery of country-based selectors, though a good design may
work. I've added some notes about autocomplete-based selectors here:
https://www.mediawiki.org/wiki/Talk:Universal_Language_Selector_Mobile#Universal_Language_Picker
I have a live mockup:
On Tue, Feb 21, 2012 at 5:11 PM, Brion Vibber br...@pobox.com wrote:
A few issues with country-based anything:
And of course:
* the data needs to be maintained somehow
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
Awesome, it's great to see the mobile team filling out!
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Feb 8, 2012 at 12:17 PM, Rob Lanphier ro...@wikimedia.org wrote:
After that it means, in theory, that trunk will be open for
post-deploy commits. However, we *cannot* let the same backlog back
up that we did before, and there's no way we can keep up with
everything we need to do for
On Mon, Jan 23, 2012 at 7:44 AM, Sumana Harihareswara suma...@wikimedia.org
wrote:
On 01/20/2012 06:35 PM, aude wrote:
FYI, the Wikimania 2012 call for participation is out!
We encourage you to submit a talk, a workshop or panel session for
Wikimania 2012. We have a technical track
On Thu, Jan 12, 2012 at 7:17 AM, Antoine Musso hashar+...@free.fr wrote:
I have added a new continuous integration job to check our postgres
support.
This is exactly the same job as MediaWiki-phpunit, only the database
backend
change.
The link is:
Ah, another community old hand joining on... Welcome aboard, Andre! :D
-- brion
On Thu, Jan 12, 2012 at 3:22 AM, Tomasz Finc tf...@wikimedia.org wrote:
Greetings all,
I'm pleased to announce that Andre Engles has decided to join the Mobile
team as our data analyst contractor. In this role
On Wed, Jan 11, 2012 at 10:44 AM, Chad innocentkil...@gmail.com wrote:
On Wed, Jan 11, 2012 at 12:45 PM, Antoine Musso hashar+...@free.fr
wrote:
I do not think we want such setting in core since it does not make sense.
Developers can opt-in to get deprecation warnings shown, it is not to
Quick questions:
* Does anybody actually want to use MobileFrontend to implement a
feature-phone gateway on other sites?
If so, it may be worth doing some of that cleanup to make things more
portable.
Note that I'd also love to kill the m. stuff as it's problematic in a
number of ways, so I
On Wed, Jan 4, 2012 at 12:10 AM, IAlex ialex.w...@gmail.com wrote:
I added those fields to the Title class to avoid some DB queries and avoid
code
duplication.
*nod* they're just not generally applicable to many circumstances, and
really are page-data not title-data to begin with.
The
On Tue, Jan 3, 2012 at 10:16 AM, Thomas Gries m...@tgries.de wrote:
See also
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/UserMailer.php?revision=104208view=markup
and change line 195 $headers['X-Mailer']='MediaWiki mailer';
to something else
I don't see any reason to
On Mon, Jan 2, 2012 at 11:01 AM, Roan Kattouw roan.katt...@gmail.comwrote:
On Mon, Jan 2, 2012 at 3:56 PM, Santhosh Thottingal
santhosh.thottin...@gmail.com wrote:
[1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/107556
In that CR thread, Neil suggested moving message parsing to
On Tue, Jan 3, 2012 at 11:36 AM, Roan Kattouw roan.katt...@gmail.comwrote:
On Tue, Jan 3, 2012 at 8:24 PM, Brion Vibber br...@pobox.com wrote:
I would rather have real, working client-side processing support;
Me too, but I don't like the idea of Yet Another Miniparser that
parses a narrow
On Tue, Jan 3, 2012 at 1:43 PM, Thomas Gries m...@tgries.de wrote:
Perhaps the original requester wanted a change of the sender addresses
in LocalSettings.php:
$wgEmergencyContact = sender e-mail;
$wgPasswordSender = sender e-mail;
Yes we've already established this; that's the only
I've reverted a number of recent commits to the Title class which added
several more pre-cached fields to it, as I really don't think we want that
sort of data in Title objects to begin with. A Title object is meant to
represent a... well, a page title :) and as such should be roughly
equivalent
I noticed this commit during code review:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/107350
this adds a module providing mw.Api.watch() and mw.Api.unwatch() functions
as handy wrappers around calling the MediaWiki API methods. Each takes
three parameters:
* title
* success callback
*
on
peoples' radar before they're irrevocable.
-- brion vibber (brion @ pobox.com / bvibber @ wikimedia.org)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
401 - 500 of 1208 matches
Mail list logo