On 02/07/2013 03:14 AM, MZMcBride wrote:
Sure, I picked Gists. It didn't seem like a very difficult choice. All
cleaned up (redirected) now.
I don't think that makes sense. If someone has a link to
http://www.mediawiki.org/wiki/Extension:Gist from a README or something,
they're now going to a
Matthew Flaschen wrote:
On 02/07/2013 03:14 AM, MZMcBride wrote:
Sure, I picked Gists. It didn't seem like a very difficult choice. All
cleaned up (redirected) now.
I don't think that makes sense. If someone has a link to
http://www.mediawiki.org/wiki/Extension:Gist from a README or something,
Everyone knows your phone is more powerful than half of production cluster,
but now back to the business
We should make a structure for this new documentation base we are going to
create, I think beside of categories, they might be some spaces at least
Documentation: or something like that, where
Hey,
For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation
with people who will care if corporate users are screwed over by a
change. It needs community management, so that the features needed by
corporate
Hello,
Wikitext editors can have media materials rendered using any arbitrary
size (the thumbnails wikitext syntax). Each different size would
produce a hit to the server backend which will generate a thumbnail for
that size.
The following requests for comment is about having a consistent set
On 7 February 2013 11:37, Antoine Musso hashar+...@free.fr wrote:
The following requests for comment is about having a consistent set of
thumbnails sizes that are allowed to be rendered and let the client
browser to do the up or down scaling.
On Feb 6, 2013, at 9:32 PM, David Schoonover d...@wikimedia.org wrote:
Just want to summarize and make sure I've got the right conclusions, as
this thread has wandered a bit.
*1. X-MF-Mode: Alpha/Beta Site Usage*
*
*
We'll roll this into the X-CS header, which will now be KV-pairs (using
On Thu, Feb 7, 2013 at 2:29 AM, Petr Bena benap...@gmail.com wrote:
Everyone knows your phone is more powerful than half of production cluster,
but now back to the business
We should make a structure for this new documentation base we are going to
create, I think beside of categories, they
I think subsections are fine as long as they are small, for long pages, it
would be better to have it as subpage.
But TBH I would prefer the subpages everywhere, you can always create some
index page that would include the subpages to subsections.
On Thu, Feb 7, 2013 at 2:16 PM, Ryan Lane
I'd like to propose to define *one* request header to be used for all
analytics purposes. It can be key/value pairs, and be set client side where
applicable. Varnish can append to it where needed, later keys overriding
earlier ones. Then we can log that one header across all HTTP/caching
I should also point out that the likelihood of any links pointing to either
of the other two extensions is very low, considering neither have README
files (both had their code on the page) and only the GitHub extension even
had the extension page URL in the extension description.
*--*
*Tyler
(Added MW-Enterprise mailing list)
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation
with people who will care if corporate users are screwed over by a
change.
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation
with people who will care if corporate users are screwed over by a
change. It needs community management,
Sorry about that - Gmail reload glitch
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation
with people who will care if corporate users are screwed over by a
Hi Dan,
We have
http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion where
we've been discussing some MW user issues, but the dicussion was not
focused on corporate per se. We can use the same page or maybe set up a
subpage if you think it will be easier. There is also
On 7 February 2013 17:06, Dan Andreescu dandree...@wikimedia.org wrote:
I was on the other side of this, albeit a while back. We had to decide
between MediaWiki and Confluence to power Disney's ParentPedia (which has
since been abandoned):
The main reasons we chose Confluence:
* An easier
On Thu, Feb 7, 2013 at 11:45 AM, David Gerard dger...@gmail.com wrote:
(In my current job I'm happily spreading MediaWikis far and wide,
albeit with very little customisation. But I'm really keen to use the
Visual Editor as soon as it's in a tarball version.)
Yes, that is the prime reason
Hi,
The report covering Wikimedia engineering activities in January 2013 is now
available.
Wiki version:
https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2013/January
Blog version:
https://blog.wikimedia.org/2013/02/07/engineering-january-2013-report/
We're also proposing a shorter,
Yes, that is the prime reason we're still on 1.17 at work, it's the
most recent version the FCKEditor extension works on.
@Admins who use FCKEditor:
please be reminded that be reminded, that FCKEditor has severe security
issues.
___
Wikitech-l
On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries m...@tgries.de wrote:
@Admins who use FCKEditor:
please be reminded that be reminded, that FCKEditor has severe security
issues.
Yes, but as I mentioned until there is a suitable replacement, your
choices are: run an insecure wiki, not use
Hi folks,
We had to revert 1.21wmf9 on a few wikis due to bug 44748. Bug report:
https://bugzilla.wikimedia.org/44748
The problem is that, when 1.21wmf9 is enabled, editing is completely
broken on ku.wiktionary and sr.wikinews, among others.
Below is the stack trace. Any ideas?
Rob
On 07/02/13 20:57, Guillaume Paumier wrote:
*Git conversion https://www.mediawiki.org/wiki/Git/Conversion*
The
ExtensionDistributorhttps://www.mediawiki.org/wiki/Extension:ExtensionDistributorwas
rewritten in early January. While this was primarily done to support
the data center
On Thu, Feb 7, 2013 at 3:50 PM, Platonides platoni...@gmail.com wrote:
On 07/02/13 20:57, Guillaume Paumier wrote:
*Git conversion https://www.mediawiki.org/wiki/Git/Conversion*
The
ExtensionDistributorhttps://www.mediawiki.org/wiki/Extension:ExtensionDistributorwas
rewritten in early
Am 07.02.2013 21:46, schrieb OQ:
On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries m...@tgries.de wrote:
@Admins who use FCKEditor:
please be reminded that be reminded, that FCKEditor has severe security
issues.
Yes, but as I mentioned until there is a suitable replacement, your
choices are: run
Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system
internally. 150,000+ topics, 1000+ active users across several continents, five
years of history, and a fully supported team of developers to create
extensions. (We are looking into open-sourcing some of them.)
The main
I don't mind these discussions, but can we please stop changing the
subject, because it's changed three times and it makes it difficult to keep
track of.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
- Original Message -
From: Daniel Barrett d...@vistaprint.com
1. A desire for a department to have their own space on the wiki.
I'm not talking about access control, but (1) customized look feel,
and (2) ability to narrow searches to find articles only within that
space. The closest
On 02/07/2013 08:17 AM, Mark A. Hershberger wrote:
(Added MW-Enterprise mailing list)
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation
with people who will care
Long story short: the MediaWiki API could be included at
http://www.codecademy.com/tracks/apis
if someone wants to do the work. Codecademy is happy to have us there.
I think it is a good idea, in need of someone willing to drive this:
- It is a good excuse to improve our API documentation at
I will be happy to part-take in this, as I do have some experience with the
API :)
I am heading the API v2 project, and this would be a natural extension of
that.
* RFC http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
* Action/Parameter
On 02/06/2013 08:09 PM, Aaron Schulz wrote:
nullLockManager is defined in Setup.php.The code:
LockManagerGroup::singleton()-get( 'nullLockManager' );
... works fine in eval.php and is used in production.
However, $wgLockManagers is redefined in parserTest.inc .
It looks like it's basically
31 matches
Mail list logo
