Re: [Wikitech-l] want to work with WikiMedia Foundation

[Matthew Flaschen]

On 01/14/2013 11:01 PM, Harsh Kothari wrote:
> Hi Shailja
> 
> Thanks for your interest.
> 
> You can go through it
> http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker
> 
> Here is all the details you want. Need any help just ping . Hope you will
> get your information.

I'd also be glad to help if you have questions.

Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] want to work with WikiMedia Foundation

[Harsh Kothari]

Hi Shailja

Thanks for your interest.

You can go through it
http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker

Here is all the details you want. Need any help just ping . Hope you will
get your information.

Thanks
Harsh


On Tue, Jan 15, 2013 at 9:27 AM, Shailaja Shah wrote:

> Hello,
>
> I am a 3rd year B.Tech I.C.T.(Information and Communication
> Technology) student and am eager to contribute to the projects of
> postgresql involving PHP and SQL which is one of my interests.And I have
> also some experience in JAVA and C.
>  I request you for contact of a mentor to guide me for the same.
>
>
>  Cheers,
>
>
>
> Shailaja Shah
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Harsh Kothari
Engineering Trainee,
Physical Research Laboratory.
Follow Me : harshkothari410 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] want to work with WikiMedia Foundation

[Shailaja Shah]

Hello,

I am a 3rd year B.Tech I.C.T.(Information and Communication
Technology) student and am eager to contribute to the projects of
postgresql involving PHP and SQL which is one of my interests.And I have
also some experience in JAVA and C.
 I request you for contact of a mentor to guide me for the same.


 Cheers,



Shailaja Shah
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: [Wikimedia-l] Aaron Swartz Community Impact

[James Forrester]

All,

I thought that this might be particularly-relevant to members of this list,
for those not on wikimedia-l; apologies if you have already seen.

James.
-- 
James D. Forrester
jdforres...@gmail.com
[[Wikipedia:User:Jdforrester|James F.]] (speaking purely in a personal
capacity)


-- Forwarded message --
From: Gayle Karen Young 
Date: 14 January 2013 11:13
Subject: [Wikimedia-l] Aaron Swartz Community Impact
To: "wikimedi...@lists.wikimedia.org" 


*I sent this to the staff list and am sending it to wikimedia-l now as
well. I didn’t know Aaron Swartz, but many friends and colleagues that I
respect and admire were influenced and impacted, by both his life and
death.  I’m sad for those who knew him, and I carry the sense that the
world is a worse place for his absence.

I’m worried that other talented, smart people who see what is wrong with
this world and try to change it against overwhelming odds will see this as
one more thing that tips the scales towards the “this isn’t worth it” or “I
can’t exist like this”, slide a little further down the slippery slope into
their own abyss. I’m worried about people in pain and confusion, who may
not have the people in their lives who are able to handle explicit or
implicit expressions of pain and grief, who may feel isolated or sad and
not able to reach out for help, or don’t believe they can be helped.

I started my career studying depression treatment and prevention because
I’ve seen what it does to people - whether they’re beautifully ordinary
people you’d meet on the street or whether they’re great shining lights
whose loss makes you want to rail at an unfair universe -  and because I
have my own history of major depressive episodes and my own sit-down with a
bottle of pills one dark night and I’ve grieved suicide in my own family
system and lived with its consequences. For the living, different kinds of
death leave different kinds of wounds, and I think suicide leaves the most
jagged, livid ones. If you’ve had a loved one pass from illness or old age,
the wound is just different than that of suicide.  As an illness,
depression is painful and inherently isolating, and it makes people feel
terrible about themselves - and isolation is a major factor for suicide.
 Depression slams blinders on possibility, when people most need to be able
to see the options and paths before and around them, and when people need
to have access.   The state inherently robs someone of their ability - and
even of the belief that help is possible and available.

My favorite author
on
this topic, Kay Redfield Jamison, wrote “When people are suicidal, their
thinking is paralyzed, their options appear spare or nonexistent, their
mood is despairing, and hopelessness permeates their entire mental domain.
The future cannot be separated from the present, and the present is painful
beyond solace.”

The factors that generally lead to depression and suicide are complex,
though people keep trying to find the one tipping point thing, the one
cause.   At the end of the day, death forces the living to sit with the
unknowns. I think anecdotally that if you live long enough, you develop a
certain resiliency and a greater capacity - but that’s if you get to that
point in the first place.

So here’s your public service announcement - communities where there is
exposure to suicide via media/internet carry greater risks. It’s called
suicide
contagion . As a
community, it’s worth it to be informed and to be extra care-full of those
we interact with,  and to take increased care of your mental health. (Take
a walk. Call a friend.)

Major risk factors
for
suicide include mental disorders, especially mood disorders, hopelessness,
impulsive/aggressive tendencies, family history or previous attempts,
physical illness, job/financial loss, relationship loss, lack of social
support and isolation, stigma associated with asking for help, cultural
beliefs, and exposure to others who have committed suicide (via internet as
a form of transmission).

If someone you know is suicidal (and especially if they have a plan), get
help. Don’t try to talk them out of suicide. Don’t tell them their family
will miss them or that they’ll be a huge loss, even though both of those
are true. Listen to them. Tell them what they’re going through is
temporary, even if they’ve lived with it for awhile, and that It’s
treatable. It will pass. And for the love of anything you consider holy,
get professional help. They’ll often believe they can’t be helped. If it’s
you, please ask for it. I will find you help. You are not alone. If you
have or had suicidal thoughts, you’re not crazy. It’s okay - or at least,
it’s not yet but it will be.  It’s a signal flare that it’s time to get aid.

Rilke wrote, “I am not yet wise in my grie

[Wikitech-l] Open Tech Chat this week: git-deploy!

[Rob Lanphier]

Hi everyone,

This week's open tech chat is going to be very tied to current events,
where the current event is the data center migration, and
specifically, our move to git-deploy[1] as a replacement for the
venerable "scap"[2] for deployments in the new (and old) datacenters.

This talk will be geared toward people that already have deploy access
due to the urgency of this training.  So, while we won't be kicking
anyone out who just wants to learn about this stuff, and we can
probably handle a couple of basic questions that people who currently
deploy should already know, we'd like to keep things largely focused
on the people who need to learn this to know the new system.

Meeting details are here.
http://www.mediawiki.org/wiki/Meetings/2013-01-17

Hope to see you there!

Rob

[1] http://wikitech.wikimedia.org/view/Git-deploy
[2] http://wikitech.wikimedia.org/view/Scap

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Deployment freeze during Eqiad migration week (and deployments next week)

[Techman224]

On the date you plan to deploy 1.21wmf8 to test, test2, and mediawiki; do you 
also plan on deploying it to Wikidata with them or with the other 
non-Wikipedias?

Techman224

On 2013-01-14, at 7:26 PM, Rob Lanphier  wrote:

> Hi everyone,
> 
> As you probably read from CT's email last week about the Eqiad
> migration (you read that, right?  No?  Go read it.  I'll wait)
> 
> Ok, done now?  So, as you know (now), we plan to suspend all scheduled
> deployments next week during the data center migration (January
> 21-25).  We'd like to keep the number of moving parts to a minimum,
> thus we'd like to avoid changing anything unless necessary.
> 
> That said, we are contemplating leaving the Wednesday window for
> 1.21wmf8 to non-Wikipedia in place as a means of testing deployments
> themselves.  Unlike previous core deployments (which are pretty
> routine), we're reserving the right not to have that deployment, and
> may delay the already-revised deployment calendar one more week if
> things are still messy on Wednesday.  I'm guessing that the odds of
> that deployment happen are pretty low (I'll say "20%" based on aerial
> extraction).
> 
> So, to reiterate the plan with respect to deployments over the next
> couple of weeks:
> 
> January 14-15 (Mon-Tue): deployments from fenari to Tampa cluster
> using scap/sync-file/sync-dir as normal.
> January 16 (Wed): 1.21wmf8 deployed to test, test2, and mediawiki.org
> January 16-18 (Wed-Fri): 1.21wmf8 deployments using git-deploy from fenari
> January 17 (Thu): Brown bag with Ryan Lane and Chris Steipp to talk
> about git-deploy
> January 21 (Mon): Deployment freeze (and U.S. holiday)
> January 22-25 (Tue-Fri): Deployment freeze
> January 23 (Wed): MAYBE 1.21wmf8 deployment to some or all non-Wikipedia 
> sites.
> 
> I hope this all makes sense.  Questions/comments/concerns?
> 
> Rob
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Deployment freeze during Eqiad migration week (and deployments next week)

[Rob Lanphier]

Hi everyone,

As you probably read from CT's email last week about the Eqiad
migration (you read that, right?  No?  Go read it.  I'll wait)

Ok, done now?  So, as you know (now), we plan to suspend all scheduled
deployments next week during the data center migration (January
21-25).  We'd like to keep the number of moving parts to a minimum,
thus we'd like to avoid changing anything unless necessary.

That said, we are contemplating leaving the Wednesday window for
1.21wmf8 to non-Wikipedia in place as a means of testing deployments
themselves.  Unlike previous core deployments (which are pretty
routine), we're reserving the right not to have that deployment, and
may delay the already-revised deployment calendar one more week if
things are still messy on Wednesday.  I'm guessing that the odds of
that deployment happen are pretty low (I'll say "20%" based on aerial
extraction).

So, to reiterate the plan with respect to deployments over the next
couple of weeks:

January 14-15 (Mon-Tue): deployments from fenari to Tampa cluster
using scap/sync-file/sync-dir as normal.
January 16 (Wed): 1.21wmf8 deployed to test, test2, and mediawiki.org
January 16-18 (Wed-Fri): 1.21wmf8 deployments using git-deploy from fenari
January 17 (Thu): Brown bag with Ryan Lane and Chris Steipp to talk
about git-deploy
January 21 (Mon): Deployment freeze (and U.S. holiday)
January 22-25 (Tue-Fri): Deployment freeze
January 23 (Wed): MAYBE 1.21wmf8 deployment to some or all non-Wikipedia sites.

I hope this all makes sense.  Questions/comments/concerns?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update on Ashburn data center switchover / migration – target date is week of 1/22/13

[Tilman Bayer]

Expect some public attention for this - already there is
http://www.datacenterknowledge.com/archives/2013/01/14/its-official-equinix-ashburn-is-wikimedias-home/

On Fri, Jan 11, 2013 at 12:07 PM, Ct Woo  wrote:
> All,
>
> The Migration team is in the last lap on completing the remaining tasks to
> ready our software stack and Ashburn infrastructure for the big switchover
> day.
>
> Per my last 
> update,
> with the Fundraising activity behind us now, the team has scheduled the *week
> of 22nd January*, 2013 to perform the switchover. We are going to block a
> 8-hour migration window on the *22nd, 23rd and 24**th*.  During those
> periods, *17:00 UTC to 01:00 UTC hours (9am to 5pm PST*), there will be
> intermittent blackouts and they will be treated as 'planned' outages.  You
> can follow the migration on irc.freenode.org in the #wikimedia-operations
> channel.
>
> The team is putting the finishing touches to the last few tasks and we will
> make the final Go/No decision on 18th Jan, 2013. An update will send out
> then. For those interested in tracking the progress, the meeting notes are
> captured on this wikitech
> page
> .
>
> *Please note that we will be restricting code deployment during that week,
> allowing only emergency and critical ones only.*
>
> Thanks.
>
> CT Woo
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Release Notes and ContentHandler

[Lee Worden]

On 01/13/2013 07:00 PM, wikitech-l-requ...@lists.wikimedia.org wrote:

From: Daniel Kinzler
To: Wikimedia developers
Subject: Re: [Wikitech-l] Release Notes and ContentHandler
Message-ID:<50f2abf9.4020...@brightbyte.de>
Content-Type: text/plain; charset=ISO-8859-1

On 13.01.2013 02:02, Lee Worden wrote:

>Yes, I think ContentHandler does some of what WW does, and I'll be happy to
>integrate with it.  I don't think we'll want to abandon the source-file tag,
>though, because on pages like
>http://lalashan.mcmaster.ca/theobio/math/index.php/Nomogram  and
>http://lalashan.mcmaster.ca/theobio/worden/index.php/Selection_Gradients/MacLev,
>it's good to be able to intertwine source code with the rest of the page's
>wikitext.

ContentHandler does not yet have good support for inclusion - currently, there's
just Content::getWikitextForInclusion(), which is annoying. It would be much
nicer if we had Content::getHTMLForInclusion(). That would allow us to
transclude any kind of content anywhere.

That would mean taht instead of Foo.tex, you could
just use {{:Foo.tex}} to transclude Foo.tex's content. Actually, you could
implement getWikitextForInclusion() to return
Foo.tex, I guess - but that's cheating ;)


It's not Foo.tex - that would be ridiculous. 
 If nothing else, I'd use . :)  [In 
fact, I do support that form, but it's hardly ever used.]


No, it's \documentclass{article} [...] 
\end{document}.  It stores the actual source code.  The 
file is not transcluded.  This may seem ridiculous at first blush, and 
you might never want to do that with long .tex files or Python modules, 
but think instead of explaining a concept by using a series of little 
4-line programs, to illustrate each step.  You can think of 
 as  with semantics behind it.  It 
displays a code listing, with highlighting, but it also lets you run the 
code, in context, and display the output.


There are plenty of use cases where you don't want to do that, you just 
want to put each source file on its own page, and I support that now, 
and I'll definitely support the use of ContentHandler when it's time, as 
I've been planning to all along.  But the ability to edit, run, test, 
and refine the code by pressing the Preview button, without saving your 
changes to the wiki until you're satisfied, even if the code is in 
multiple source files, is a valuable affordance, and we may not want to 
give it up.



>Also, in a multi-file project, for instance a simple LaTeX project with a .tex
>file and a .bib file, it's useful to put the files on a single page so you can
>edit and preview them for a while before saving.

That would not change when using the ContentHandler: You would have one page for
the .tex file, one for the .bib file, etc. The difference is that MediaWiki will
know about the different types of content, so it can provide different rendering
methods (syntax highlighted source or html output, as you like), different
editing methods (input forms for bibtext entries?).

>

Basically, you no longer need nasty hacks to work around MediaWiki's assumption
that pages contain wikitext, because that assumption was removed in 1.21.


Bundling several source files onto a single page, with wikitext 
interspersed, is a form of literate programming.  It's part of the same 
tradition as knitr, R markdown, sage notebooks, etc.  There are valuable 
uses for embedding code in free-form markup, and I think it's useful to 
be able to do it in MediaWiki.


LW


-- daniel


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Current state of the LTS

[David Gerard]

On 14 January 2013 19:09, Mark A. Hershberger  wrote:

> As a result, LTS is firming up:
> * Security patches supplied until May 2015.


\o/ THANK YOU. This is the necessary and sufficient condition.


> * Compatibility extension for those features that can be put into an
> extension.
> * Back porting of other features.  Where possible, we will only add
> hooks that the Compatibility extension can use.


But these are lovely and not to be sniffed at :-)


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] i18n deployment 2013-01-15

[Siebrand Mazeland (WMF)]

On Mon, Jan 14, 2013 at 7:58 PM, Matthew Walker wrote:

> do you have 30 minutes sometime
> this week where we could bash heads together and bring each other up to
> date on requirements/needs that sort of thing?
>

Thanks for the reply, Matt. I'll follow-up off list.

Cheers!

-- 
Siebrand Mazeland
Product Manager Language Engineering
Wikimedia Foundation

M: +31 6 50 69 1239
Skype: siebrand

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Current state of the LTS

[Mark A. Hershberger]

I've been looking at SMW's plans for the LTS and talking with other
people on-wiki and off.

As a result, LTS is firming up:

* Security patches supplied until May 2015.
* Compatibility extension for those features that can be put into an
extension.
* Back porting of other features.  Where possible, we will only add
hooks that the Compatibility extension can use.

Also updated:

https://www.mediawiki.org/wiki/Version_lifecycle

Thanks!

Mark.


-- 
http://hexmode.com/

Language will always shift from day to day. It is the wind blowing
through our mouths. -- http://hexm.de/np

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] i18n deployment 2013-01-15

[Matthew Walker]

Siebrand,

Mobile and Fundraising have been scheming for some time about various ways
to utilize what Varnish offers which may have been what you've heard about.
Mobile is further along the path than Fundraising in terms of utilizing
Edge Side Includes (ESI) -- but their approach as I understand it is not
yet portable to extensions beyond MobileFrontend. Ideally myself or Adam
will be able to start working on ESI wrt CentralNotice (and therefore
extensions to the rest of the site) sometime in the next 2 months but I
certainly wouldn't wait for us. Still - do you have 30 minutes sometime
this week where we could bash heads together and bring each other up to
date on requirements/needs that sort of thing?

I just created a document at [1] which started to outline our vision for
where Fundraising is going (but it's very rough).
[1]
http://www.mediawiki.org/wiki/Extension:CentralNotice/Caching_Overhaul_--_Edge_Side_Includes

~Walker

On Mon, Jan 14, 2013 at 4:18 AM, Siebrand Mazeland (WMF) <
smazel...@wikimedia.org> wrote:

> Hi Gerard. Interesting to hear from you.
>
> Op 14 jan. 2013 om 13:06 heeft Gerard Meijssen 
> het volgende geschreven:
>
> > Is there any idea when the ULS will be enabled on all projects ?
>
> No. "As soon as is realistic." There are no hard targets that are worth
> communicating.
>
> > What priority do the caching challenges have given the huge amount of
> > people who stand to benefit in the USA (never mind the people in the rest
> > of the world) ??
>
> I was told that "the Varnish solution" will be explored by someone right
> after the data centre migration. Someone else is working on getting a squid
> patch together and get that submitted to the squid cache project for a
> short term solution. No estimated times to fix their either.
>
> Siebrand
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
~Matt Walker
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to support MediaWiki

[Mark A. Hershberger]

(CC'd mediawiki-enterprise since it is relevant.)

On Mon 14 Jan 2013 11:56:50 AM EST, Dmitriy Sintsov wrote:
>> This does point to another possible way to backport the changes -- some
>> sort of compatibility extension.That allows the core to remain stable,
>> but allows people to use some newer extensions if they need the
>> features.
>>
> I am not sure Wikimedia would like to put their efforts on this.

Agreed.  I didn't say they should.

The WMF is focused on its vision (which doesn't include supporting
non-WMF users of MW).  In the mean time, they've made this software
available for the world to use.

> My own experience shows that most of site owners are quite greedy
> people. Maybe I am bad at business though.

People are people.

We're slipping off topic here, but in as far as this relates to users of
MediaWiki, I'll continue.

First, I should say that I've worked closely with people across the
spectrum of business.  I've worked with, and count as friends, several
small business owners who run on-line sites as their core business.

On the other "side", I have friends who work at or run non-profits or
charities including some at the WMF.

My friends who are site owners are, on the whole, no more
self-interested than any of my other friends.  They are focused on
maintaining the business just as my friends at the WMF is focused on
keeping Wikipedia and its sister sites running.

If we want something more from MediaWiki, we can ask the WMF for it,
but, since we have the GPL license on the software, we are also
empowered to do it ourselves if the WMF is not interested in helping.

Semantic MediaWiki is a great example of this happening and many non-WMF
users of MediaWiki use SMW.

I think MediaWiki core alone can (and does!) benefit many people outside
the Foundation in just the same way that SMW does.  We have the power to
make it more suitable for our own non-WMF uses.

-- 
http://hexmode.com/

Language will always shift from day to day. It is the wind blowing
through our mouths. -- http://hexm.de/np

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Rescheduled MobileFrontend deployment, open slot this Tuesday

[Arthur Richards]

The mobile team had to reschedule its regular MobileFrontend deployment
from Tuesday (1-3pm PST) to Thursday (3-5pm PST)[1]. So, there's a new open
slot on Tuesday if anyone needs it :)

[1]
http://wikitech.wikimedia.org/index.php?title=Deployments&diff=55333&oldid=55299
-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Željko Filipin presenting at FOSDEM

[Chris McMahon]

Željko Filipin, QA Engineer for WMF, will be giving a presentation at
FOSDEM in Brussels Feb 2 about our browser automation project.

Congratulations Željko, it looks like a great track to be part of.
https://fosdem.org/2013/schedule/track/testing_and_automation/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal: MediaWiki Group Promotion (was Marketing)

[Quim Gil]

On 01/14/2013 04:11 AM, Bence Damokos wrote:

Hi all,

I am happy to let you know that this group has been recognized as a user
group by the Affiliations Committee under the name MediaWiki Group
Promotion.

Congratulations!

Best regards,
Bence

(Chair, Affiliations Committee)



Thank you!

https://www.mediawiki.org/wiki/Groups/Promotion (was Marketing) got 
renamed after some discussion. I hope this group helps structuring, 
documenting and coordinating many promotion activities done here and there.


I'm really happy that Varnent accepted the invitation to be also a 
promoter of the group!


If you are interested watch/edit the page and the Discussion threads. We 
will keep using this list for bigger topics with wider implications.


--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extending the action=options API with storing arbitrary preferences

[Matma Rex]

On Mon, 14 Jan 2013 17:48:32 +0100, Brad Jorsch  wrote:


On Mon, Jan 14, 2013 at 9:49 AM, Matma Rex  wrote:

Well, these fields are BLOBs, so any length should work as long as you have
enough disk space. ;) The length of the key (which is a VARBINARY(255)) is
checked.


Not true, a BLOB can hold 65535 bytes maximum. That's short enough
that it probably is worth adding a length check to the API.


Huh. I guess I was under the mistaken impression that MySQL is reasonable. 
Thanks for the clarification.

(I just checked the default size limits for similar fields on SQLite and 
Postresql: 1 gigabyte for both. Yay for MySQL.)


--
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to support MediaWiki

[Dmitriy Sintsov]

14 Январь 2013 г. 19:59:01 пользователь Mark A. Hershberger 
(m...@everybody.org) написал:

On 01/14/2013 01:34 AM, Dmitriy Sintsov wrote:
> My own (already past) experience of developing MediaWiki extensions
> shows that it is much easier to keep the compatibility layer in
> extension itself rather than backporting large changes into older
> versions of core. 


This does point to another possible way to backport the changes -- some
sort of compatibility extension.    That allows the core to remain stable,
but allows people to use some newer extensions if they need the features.


I am not sure Wikimedia would like to put their efforts on this. In fact, if I 
was in Wikipedia, why would I spend my time helping lazy competitors? Wikimedia 
is too major and MediaWiki is primarily their tool which they generously offer 
to another people. It should be much simpler to persuade extension-level LTS.


> However there are major milestone versions, such as 1.17 with
> ResourceLoader and 1.21 with ContentHandler, and it's not easy to
> backport their functionality back [...]. So, the
> extensions probably has to be compatible to such "major milestone
> versions".

Agreed.    1.19 is (in retrospect) a good choice for an LTS version since
ResourceLoader has stabilized somewhat.


But it misses ContentHandler. And there was a lot of 1.17 installations as 
well. But yes, 1.17 does not support some things, like specifying to load css 
on top. Maybe more.


> But many of the sites the wikistats list have are quite large and thus
> earn enough of money to their owners. I wonder why do not they update
> their sites.

"Don't fix what isn't broke" is probably part of the thinking.


My own experience shows that most of site owners are quite greedy people. Maybe 
I am bad at business though.


> One guess I know that some admins consider newer versions
> are slower than old ones, do not know how much that is true.

Mariya Miteva [[mw:User:Mitevam]] is talking to non-WMF users of
MediaWiki and has found that some people are put off by the difficulty
of upgrading MediaWiki.

For example, many people have put in some effort to modify a skin for
their needs only to find gratuitous changes in the core made with (what
appears to be) little thought for backwards compatibility.


Skins are horrorful part of MediaWiki. They are deliberately made too much 
low-level to run fast (they probably sample performance). However after upgrade 
custom skinning could break or miss newly added parts. Daniel Friesen attempted 
to make skins template-based but I do not think it was accepted into the core.


So, if a site is working for me as it is, and the only reasons for me to
upgrade are some obscure security issues that I may never face, then I
will probably find a way to work around the issues instead of upgrading.


Maybe, somewhat.
Dmitriy

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Extension Bundles and Template Bundles

[vitalif]

On 01/14/2013 10:20 AM, Yuvi Panda wrote:
Is there a sort of 'Extension Bundle' that gets you baseline stuff 
that
people who are used to wikipedia 'expect'? ParserFunctions and Cite 
come to

mind, but I'm sure there are plenty others.


I don't know if this would be relevant to your question, but I have to 
say that in our company we maintain and use our own MediaWiki 
distribution "Mediawiki4Intranet" (http://github.com/mediawiki4intranet, 
http://wiki.4intra.net/) for all MW installations. It includes ~75 
extensions, the set is not totally similar to WMF one, but we think it's 
good for corporate (intranet) usage. You can try it out if you want, yet 
some extensions are documented only in russian :-)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extending the action=options API with storing arbitrary preferences

[Brad Jorsch]

On Mon, Jan 14, 2013 at 9:49 AM, Matma Rex  wrote:
> On Mon, 14 Jan 2013 15:42:35 +0100, Tyler Romeo 
> wrote:
>
>> Additionally, one thing we might want to change is at the very least doing
>> a quick length check on userjs- options just to make sure they fit in the
>> database, although it shouldn't really be an issue.
>
>
> Well, these fields are BLOBs, so any length should work as long as you have
> enough disk space. ;) The length of the key (which is a VARBINARY(255)) is
> checked.

Not true, a BLOB can hold 65535 bytes maximum. That's short enough
that it probably is worth adding a length check to the API.

See https://dev.mysql.com/doc/refman/5.0/en//blob.html for details.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Extension Bundles and Template Bundles

[Siebrand Mazeland (WMF)]

On Mon, Jan 14, 2013 at 5:17 PM, bawolff  wrote:

> On Mon, Jan 14, 2013 at 12:12 PM, Mark A. Hershberger 
> wrote:
> > On 01/14/2013 10:20 AM, Yuvi Panda wrote:
> >
> > ParserFunctions is already included, but I was going to bundle the
> > following extensions in 1.21:
> >
> > * LocalisationUpdate
>
> How do you plan to get users to set it up? AFAIK it requires setting
> up a cron job, so its not exactly something that can automatically be
> set up by the installer.
>

LU is also part of MLEB, which is released on a monthly basis:
https://www.mediawiki.org/wiki/MLEB. This page also contains brief
instructions on how to set things up. This bundle is maintained by the
Wikimedia Language Engineering team, more specifically Niklas Laxström.

Another bundle that I know of is SemanticBundle,
https://www.mediawiki.org/wiki/Semantic_Bundle, which is currently
maintained by Yaron Koren and Jeroen De Dauw.

Cheers!

-- 
Siebrand Mazeland
Product Manager Language Engineering
Wikimedia Foundation

M: +31 6 50 69 1239
Skype: siebrand

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Extension Bundles and Template Bundles

[bawolff]

On Mon, Jan 14, 2013 at 12:12 PM, Mark A. Hershberger  
wrote:
> On 01/14/2013 10:20 AM, Yuvi Panda wrote:
>
> ParserFunctions is already included, but I was going to bundle the
> following extensions in 1.21:
>
> * LocalisationUpdate

How do you plan to get users to set it up? AFAIK it requires setting
up a cron job, so its not exactly something that can automatically be
set up by the installer.

>
> As far as template bundles, I think this would be better served with an
> extension like LocalisationUpdate that could fetch a new copy of the
> desired templates from your chosen Wikipedia.
>
> Another area that could benefit most non-WMF wikis is a way to import
> some documentation for how to *use* a wiki.

Both of those two things would probably be solved if we had good
interwiki transclusion support.

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Extension Bundles and Template Bundles

[Mark A. Hershberger]

On 01/14/2013 10:20 AM, Yuvi Panda wrote:
> Is there a sort of 'Extension Bundle' that gets you baseline stuff that
> people who are used to wikipedia 'expect'? ParserFunctions and Cite come to
> mind, but I'm sure there are plenty others.

This was part of my reasoning behind bundling some core extensions with
MediaWiki.

ParserFunctions is already included, but I was going to bundle the
following extensions in 1.21:

* Cite
* InputBox
* LocalisationUpdate
* SyntaxHighlight_GeSHi

As far as template bundles, I think this would be better served with an
extension like LocalisationUpdate that could fetch a new copy of the
desired templates from your chosen Wikipedia.

Another area that could benefit most non-WMF wikis is a way to import
some documentation for how to *use* a wiki.

-- 
http://hexmode.com/

Language will always shift from day to day. It is the wind blowing
through our mouths. -- http://hexm.de/np

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update on Ashburn data center switchover / migration – target date is week of 1/22/13

[Jay Ashworth]

- Original Message -
> From: "Guillaume Paumier" 

> On Fri, Jan 11, 2013 at 10:48 PM, Jay Ashworth 
> wrote:
> > I have forwarded this to the Outages mailing list, so that people who
> > want to know/get complaints about such things have advance warning.
> 
> Thank you :)
> 
> For those, like me, who upon reading that message wondered if there
> was an "outages-l" among the gazillion Wikimedia mailing lists, Jay is
> referring to a third-party mailing list:
> https://puck.nether.net/mailman/listinfo/outages

Yeah; nerdview is even bad among nerds.

Outages is a collection of 3 mailing lists, a wiki, and a social media
report tracker run by Virendra Rode with some help from Frank Bulk and I;
Jared Mauch supplies the list reflectors.

Our wiki has, among other things, a page that collects useful network
testing and diagnostic tools, which I really need to groom again -- if you
look at it, and find something missing or broken, let me know.  :-)

It runs, of course, Mediawiki.  (Is there anything else?)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] How to support MediaWiki

[Mark A. Hershberger]

On 01/14/2013 01:34 AM, Dmitriy Sintsov wrote:
> My own (already past) experience of developing MediaWiki extensions
> shows that it is much easier to keep the compatibility layer in
> extension itself rather than backporting large changes into older
> versions of core. 

This does point to another possible way to backport the changes -- some
sort of compatibility extension.  That allows the core to remain stable,
but allows people to use some newer extensions if they need the features.

> However there are major milestone versions, such as 1.17 with
> ResourceLoader and 1.21 with ContentHandler, and it's not easy to
> backport their functionality back [...]. So, the
> extensions probably has to be compatible to such "major milestone
> versions".

Agreed.  1.19 is (in retrospect) a good choice for an LTS version since
ResourceLoader has stabilized somewhat.

> But many of the sites the wikistats list have are quite large and thus
> earn enough of money to their owners. I wonder why do not they update
> their sites.

"Don't fix what isn't broke" is probably part of the thinking.

> One guess I know that some admins consider newer versions
> are slower than old ones, do not know how much that is true.

Mariya Miteva [[mw:User:Mitevam]] is talking to non-WMF users of
MediaWiki and has found that some people are put off by the difficulty
of upgrading MediaWiki.

For example, many people have put in some effort to modify a skin for
their needs only to find gratuitous changes in the core made with (what
appears to be) little thought for backwards compatibility.

So, if a site is working for me as it is, and the only reasons for me to
upgrade are some obscure security issues that I may never face, then I
will probably find a way to work around the issues instead of upgrading.

-- 
http://hexmode.com/

Language will always shift from day to day. It is the wind blowing
through our mouths. -- http://hexm.de/np

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update on Ashburn data center switchover / migration – target date is week of 1/22/13

[Guillaume Paumier]

Hi,

On Fri, Jan 11, 2013 at 10:48 PM, Jay Ashworth  wrote:
> I have forwarded this to the Outages mailing list, so that people who
> want to know/get complaints about such things have advance warning.

Thank you :)

For those, like me, who upon reading that message wondered if there
was an "outages-l" among the gazillion Wikimedia mailing lists, Jay is
referring to a third-party mailing list:
https://puck.nether.net/mailman/listinfo/outages

-- 
Guillaume Paumier

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal: MediaWiki Group San Francisco

[Quim Gil]

On 01/14/2013 04:10 AM, Bence Damokos wrote:

Hi all,

I am happy to let you know that this group has now been recognized by the
Affiliations Committee as a user group.

Best regards,
Bence

(Chair, Affiliations Committee)


Thank you! The timing is perfect for the next Wikipedia Engineering 
Meetup this Thursday.  :)


http://www.meetup.com/Wikipedia-Engineering-Meetup/events/89239012/

--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Yuvi Panda returns to the Mobile Team

[Harsh Kothari]

Congrats Yuvi :)

Cheers
Harsh
---
Harsh Kothari
Research Fellow, 
Physical Research Laboratory(PRL).
Ahmedabad.


On 14-Jan-2013, at 6:41 PM, Sumana Harihareswara wrote:

> Welcome back to Wikimedia Foundaion, Yuvi!  :-)
> 
> -Sumana
> 
>  Original Message 
> Subject: Yuvi Panda returns to the Mobile Team
> Date: Sun, 13 Jan 2013 17:33:38 -0800
> From: Tomasz Finc 
> 
> 
> I'm very happy to announce that Yuvi Panda has rejoined the mobile
> department as a software developer. He'll be working directly with Brion
> Vibber within the newly created apps team. More info about the team will
> go out in the next weeks.
> 
> For those of you that have not worked with Yuvi before he's been
> responsible in some part for:
> 
> * Wiki Loves Monuments Android App
> * Signpost Android App
> * Wikipedia iOS/Android App
> * Multiple language tools
> * Numerous self run hackathons
> * ... and so much more
> 
> For the next six months Yuvi will be working with us remotely from India
> while he finishes up his degree. Upon completion of his studies and his
> visa being accepted he will move and work with us full time in SF.
> 
> The team is very excited to be working with him again.
> 
> Pleases join me in re-welcoming Yuvi to the mobile team!
> 
> --tomasz
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extending the action=options API with storing arbitrary preferences

[Matma Rex]

On Mon, 14 Jan 2013 15:42:35 +0100, Tyler Romeo  wrote:


About the two sister issues that are still open (bug 43959 and 43960),
unless somebody beats me to it, I will work on resolving those sometime
tonight or tomorrow night.


Thanks!



Additionally, one thing we might want to change is at the very least doing
a quick length check on userjs- options just to make sure they fit in the
database, although it shouldn't really be an issue.


Well, these fields are BLOBs, so any length should work as long as you have 
enough disk space. ;) The length of the key (which is a VARBINARY(255)) is 
checked.

--
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extending the action=options API with storing arbitrary preferences

[Tyler Romeo]

About the two sister issues that are still open (bug 43959 and 43960),
unless somebody beats me to it, I will work on resolving those sometime
tonight or tomorrow night.

Additionally, one thing we might want to change is at the very least doing
a quick length check on userjs- options just to make sure they fit in the
database, although it shouldn't really be an issue. :P

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com


On Mon, Jan 14, 2013 at 9:38 AM, Matma Rex  wrote:

> Yesterday, per the extended discussion on bug 40124, gerrit change
> I5f9ba5b0 has been merged. It extends the action=options API, essentially
> allowing user scripts, gadgets, and external editors to store arbitrary
> persistent private data in user preferences. [ https://bugzilla.wikimedia.
> **org/40124  /
> https://gerrit.wikimedia.org/**r/#q,I5f9ba5b0,n,z]
>
> This officially reenables the feature that was present, but undocumented
> and defective in MW 1.20 (saving preferences using Special:Preferences
> cleared any additional fields) and which has been disabled in 1.20.1 as a
> part of a security fix (bug 42202 / gerrit I98df55f2). [
> https://bugzilla.wikimedia.**org/42202/
> https://gerrit.wikimedia.org/**r/#q,I98df55f2,n,z]
>
> These semi-arbitrary options have only three limitations imposed on them:
> * the key must start with userjs- prefix (to avoid conflicting with new
> options being added in core or in extensions)
> * the length of the key must not exceed 255 bytes (this is a database
> schema limitation)
> * the key must consist only of ASCII letters, numbers, hyphens and
> underscores (a-z, A-Z, 0-9, _, -; for sanity)
>
> There are currently no hard limits on the length nor contents of the
> value, as well as on the number of additional preferences. The contents of
> these preferences are not escaped, sanitized nor validated in any way;
> script authors are expected to sanitize them themselves to prevent XSS
> attacks and other security vulnerabilities. Similar care should be taken if
> they are ever shown anywhere in the Special:Preferences interface.
>
> Two low-severity sister issues are left to be solved right now:
> * bug 43959 - action=options API should allow resetting of chosen
> preferences (instead of the all-or-nothing approach)
> * bug 43960 - Arbitrary userjs- preferences should be shown in the GUI,
> with the possibility of clearing them one-by-one
> [ 
> https://bugzilla.wikimedia.**org/43959/
> https://bugzilla.wikimedia.**org/43960]
>
> Overall, this could be a replacement for the current system of storing
> settings as global variables set in user's skin.js file, or in a separate
> .js file with gadget configuration, or in cookies / localStorage, which all
> have their drawbacks (clumsy, non-private, force an edit on-wiki to change
> prefs, volatile, possibly size-limited...). I'm quite looking forward to
> this happening :)
>
> --
> Matma Rex
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Extending the action=options API with storing arbitrary preferences

[Matma Rex]

Yesterday, per the extended discussion on bug 40124, gerrit change I5f9ba5b0 
has been merged. It extends the action=options API, essentially allowing user 
scripts, gadgets, and external editors to store arbitrary persistent private 
data in user preferences. [ https://bugzilla.wikimedia.org/40124 / 
https://gerrit.wikimedia.org/r/#q,I5f9ba5b0,n,z ]

This officially reenables the feature that was present, but undocumented and 
defective in MW 1.20 (saving preferences using Special:Preferences cleared any 
additional fields) and which has been disabled in 1.20.1 as a part of a 
security fix (bug 42202 / gerrit I98df55f2). [ 
https://bugzilla.wikimedia.org/42202 / 
https://gerrit.wikimedia.org/r/#q,I98df55f2,n,z ]

These semi-arbitrary options have only three limitations imposed on them:
* the key must start with userjs- prefix (to avoid conflicting with new options 
being added in core or in extensions)
* the length of the key must not exceed 255 bytes (this is a database schema 
limitation)
* the key must consist only of ASCII letters, numbers, hyphens and underscores 
(a-z, A-Z, 0-9, _, -; for sanity)

There are currently no hard limits on the length nor contents of the value, as 
well as on the number of additional preferences. The contents of these 
preferences are not escaped, sanitized nor validated in any way; script authors 
are expected to sanitize them themselves to prevent XSS attacks and other 
security vulnerabilities. Similar care should be taken if they are ever shown 
anywhere in the Special:Preferences interface.

Two low-severity sister issues are left to be solved right now:
* bug 43959 - action=options API should allow resetting of chosen preferences 
(instead of the all-or-nothing approach)
* bug 43960 - Arbitrary userjs- preferences should be shown in the GUI, with 
the possibility of clearing them one-by-one
[ https://bugzilla.wikimedia.org/43959 / https://bugzilla.wikimedia.org/43960 ]

Overall, this could be a replacement for the current system of storing settings 
as global variables set in user's skin.js file, or in a separate .js file with 
gadget configuration, or in cookies / localStorage, which all have their 
drawbacks (clumsy, non-private, force an edit on-wiki to change prefs, 
volatile, possibly size-limited...). I'm quite looking forward to this 
happening :)

--
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Yuvi Panda returns to the Mobile Team

[Sumana Harihareswara]

Welcome back to Wikimedia Foundaion, Yuvi!  :-)

-Sumana

 Original Message 
Subject: Yuvi Panda returns to the Mobile Team
Date: Sun, 13 Jan 2013 17:33:38 -0800
From: Tomasz Finc 


I'm very happy to announce that Yuvi Panda has rejoined the mobile
department as a software developer. He'll be working directly with Brion
Vibber within the newly created apps team. More info about the team will
go out in the next weeks.

For those of you that have not worked with Yuvi before he's been
responsible in some part for:

* Wiki Loves Monuments Android App
* Signpost Android App
* Wikipedia iOS/Android App
* Multiple language tools
* Numerous self run hackathons
* ... and so much more

For the next six months Yuvi will be working with us remotely from India
while he finishes up his degree. Upon completion of his studies and his
visa being accepted he will move and work with us full time in SF.

The team is very excited to be working with him again.

Pleases join me in re-welcoming Yuvi to the mobile team!

--tomasz

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] wikiCodeEditor - Code Editor for MediaWiki CSS and JavaScript pages

[Daniel Kinzler]

On 14.01.2013 00:16, MZMcBride wrote:
> Looks neat. :-)  But this is mostly already in progress at
> . This extension is
> live on Wikimedia wikis already (including Meta-Wiki and MediaWiki.org),
> but it has some outstanding issues and could definitely use some love
> before more widespread deployment.

Note that JS and CSS pages now (in 1.21) have their own page content model.
Perhaps it would make sens to hook into, or derive from,
JavaScriptContentHandler resp CSSContentHandler and provide a custom edit action
via the getActionOverrides() method.

On a related note, I have two patches pending review (needs some fixing) that
implement syntax highlighting for JS and CSS in a more generic way. With this in
place, it would be trivial to provide syntax highlighting also for e.g. Lua.
Have a look at  and
.

-- daniel


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] i18n deployment 2013-01-15

[Siebrand Mazeland (WMF)]

Hi Gerard. Interesting to hear from you.

Op 14 jan. 2013 om 13:06 heeft Gerard Meijssen  het 
volgende geschreven:

> Is there any idea when the ULS will be enabled on all projects ?

No. "As soon as is realistic." There are no hard targets that are worth 
communicating.

> What priority do the caching challenges have given the huge amount of
> people who stand to benefit in the USA (never mind the people in the rest
> of the world) ??

I was told that "the Varnish solution" will be explored by someone right after 
the data centre migration. Someone else is working on getting a squid patch 
together and get that submitted to the squid cache project for a short term 
solution. No estimated times to fix their either.

Siebrand
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal: MediaWiki Group Marketing

[Bence Damokos]

Hi all,

I am happy to let you know that this group has been recognized as a user
group by the Affiliations Committee under the name MediaWiki Group
Promotion.

Congratulations!

Best regards,
Bence

(Chair, Affiliations Committee)


On Thu, Dec 13, 2012 at 7:43 PM, Quim Gil  wrote:

> Hi, following the process for requesting the creation of a MediaWiki
> group, here is a proposal for
>
> MediaWiki Group Marketing
> http://www.mediawiki.org/wiki/**Groups/Proposals/Marketing
>
> Your endorsements, improvements and feedback are welcome at the wiki
> page. Thank you!
>
> PS: see also 
> http://www.mediawiki.org/wiki/**Groups/Proposals
>
> --
> Quim Gil
> Technical Contributor Coordinator @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/**User:Qgil
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal: MediaWiki Group San Francisco

[Bence Damokos]

Hi all,

I am happy to let you know that this group has now been recognized by the
Affiliations Committee as a user group.

Best regards,
Bence

(Chair, Affiliations Committee)


On Thu, Dec 13, 2012 at 12:25 AM, Quim Gil  wrote:

> Hi, following the process for requesting the creation of a MediaWiki
> group, here is a proposal for
>
> MediaWiki Group San Francisco
> http://www.mediawiki.org/wiki/**Groups/Proposals/San_Francisco
>
> Your endorsements, improvements and feedback are welcome at the wiki page.
> Thank you!
>
> --
> Quim Gil
> Technical Contributor Coordinator @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/**User:Qgil
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] i18n deployment 2013-01-15

[Gerard Meijssen]

Hoi,
Is there any idea when the ULS will be enabled on all projects ?? ULS is
said to be a prerequisite for making webfonts available.. This is of
particular relevance for the +/- 7% of the USA population ie some 20
million people who stand to benefit from the Open-Dyslexic font because of
their dyslexia.

What priority do the caching challenges have given the huge amount of
people who stand to benefit in the USA (never mind the people in the rest
of the world) ??
Thanks,
 GerardM


On 14 January 2013 11:15, Siebrand Mazeland (WMF)
wrote:

> On Mon, Jan 14, 2013 at 11:06 AM, Andre Klapper  >wrote:
>
> > Is there a vague deadline when to have Translate + ULS deployed to all
> > wikis that currently use Narayam + WebFonts (if that question makes
> > sense)?
>
>
> There are no plans for widespread deployment of the Translate extension,
> i.e. beyond multi lingual projects that request it.
>
> The end goal is to have ULS deployed on all Wikimedia wikis, for all users.
> That may take a while, though, because caching challenges in squid and/or
> Varnish have to be tackled first.
>
> Cheers!
>
> --
> Siebrand Mazeland
> Product Manager Language Engineering
> Wikimedia Foundation
>
> M: +31 6 50 69 1239
> Skype: siebrand
>
> Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] i18n deployment 2013-01-15

[Siebrand Mazeland (WMF)]

On Mon, Jan 14, 2013 at 11:06 AM, Andre Klapper wrote:

> Is there a vague deadline when to have Translate + ULS deployed to all
> wikis that currently use Narayam + WebFonts (if that question makes
> sense)?


There are no plans for widespread deployment of the Translate extension,
i.e. beyond multi lingual projects that request it.

The end goal is to have ULS deployed on all Wikimedia wikis, for all users.
That may take a while, though, because caching challenges in squid and/or
Varnish have to be tackled first.

Cheers!

-- 
Siebrand Mazeland
Product Manager Language Engineering
Wikimedia Foundation

M: +31 6 50 69 1239
Skype: siebrand

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] i18n deployment 2013-01-15

[Andre Klapper]

On Sat, 2013-01-12 at 12:35 +0100, Siebrand Mazeland (WMF) wrote:
> * Disable extensions Narayam[4] and WebFonts[5] on all wikis with
> extension Translate enabled (see list below). Functionality of these
> extensions is superseded by that of UniversalLanguageSelector. 

Thanks for the notice.

Is there a vague deadline when to have Translate + ULS deployed to all
wikis that currently use Narayam + WebFonts (if that question makes
sense)?

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] wikiCodeEditor - Code Editor for MediaWiki CSS and JavaScript pages

[SIBI]

MZMcBride  wrote:

> Hi.
>
> Looks neat. :-)  But this is mostly already in progress at
> . This extension is
> live on Wikimedia wikis already (including Meta-Wiki and MediaWiki.org),
> but it has some outstanding issues and could definitely use some love
> before more widespread deployment.
>
> For Wikimedia wikis specifically, the goal is to have CodeEditor enabled
> on user JS and CSS subpages and on site-wide JS/CSS pages soon
> (). I hope you can help out if
> you're interested.

Hi,

Didn't know that it already exists :)

Will try to look on it's code soon.

Sibi

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l