Today we threw the big lever and turned on our new search backend at
mediawiki.org. It isn't the default yet but it is just about ready for you
to try. Here is what is we think we've improved:
1. Templates are now expanded during search so:
1a. You can search for text included in templates
1b. You can search for categories included in templates
2. The search engine is updated very quickly after articles change.
3. A few funky things around intitle and incategory:
3a. You can combine them with a regular query (incategory:kings peaceful)
3b. You can use prefix searches with them (incategory:norma*)
3c. You can use them everywhere in the query (roger incategory:normans)
What we think we've made worse and we're working on fixing:
1. Because we're expanding templates some things that probably shouldn't
be searched are being searched. We've fixed a few of these issues but I
wouldn't be surprised if more come up. We opened Bug 53426 regarding audio
tags.
2. The relative weighting of matches is going to be different. We're
still fine tuning this and we'd appreciate any anecdotes describing search
results that seem out of order.
3. We don't currently index headings beyond the article title in any
special way. We'll be fixing that soon. (Bug 53481)
4. Searching for file names or clusters of punctuation characters doesn't
work as well as it used to. It still works reasonably well if you surround
your query in quotes but it isn't as good as it was. (Bugs 53013 and 52948)
5. "Did you mean" suggestions currently aren't highlighted at all and
sometimes we'll suggest things that aren't actually better. (Bugs 52286 and
52860)
6. incategory:"category with spaces" isn't working. (Bug 53415)
What we've changed that you probably don't care about:
1. Updating search in bulk is much more slow then before. This is the
cost of expanding templates.
2. Search is now backed by a horizontally scalable search backend that is
being actively developed (Elasticsearch) so we're in a much better place to
expand on the new solution as time goes on.
Neat stuff if you run your own MediaWiki:
CirrusSearch is much easier to install than our current search
infrastructure.
So what will you notice? Nothing! That is because while the new search
backend (CirrusSearch) is indexing we've left the current search
infrastructure as the default while we work on our list of bugs. You can
see the results from CirrusSearch by performing your search as normal and
adding "&srbackend=CirrusSearch" to the url parameters.
If you notice any problems with CirrusSearch please file bugs directly for
it:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
Nik Everett
== HTTPS enabled by default for logged-in users on Wikimedia sites ==
Today, August 28, the Wikimedia Foundation is making a change to the
software that powers the Wikimedia projects: By default, all logged-in
users will now be using HTTPS to access Wikimedia sites. What this does
is encrypt the connection between the Wikimedia servers and the user's
browser so that the information sent between the two is not readable by
anyone else. This is in response to the recent concerns over the privacy
and security of our user community, and we explained the rationale for
this change in our post about the future of HTTPS at Wikimedia[0].
===What this means for you ===
How this works is simple: If a user wants to log in, they will be
redirected to use HTTPS for the login, thus keeping their username and
password secure. After they are logged in, they stay on the HTTPS
version of the Wikimedia site they are using.
=== Excluded Countries ===
Some users live in areas where HTTPS is not an easy option, most times
because of explicit blocking by a government. At the request of these
communities, we have made an explicit exclusion for users from those
affected countries. Simply put, users from China and Iran will not be
required to use HTTPS for logging in, nor for viewing any Wikimedia
project site
===Disabling===
Are you having a slow or unreliable experience while browsing Wikimedia
sites over HTTPS? Then you can turn HTTPS off in your user preferences,
under the "User profile" tab: Uncheck "Always use a secure connection
when logged in". You will need to log out and log in again for the
preference to take effect. But remember, you will still need to log in
using the secure HTTPS process.
===HELP!===
For further details, please see the HTTPS[1] page on Meta-Wiki, which is
available in several languages.
Are you unable to log in and edit a Wikimedia wiki after this change?
Please contact the Wikimedia Foundation Operations team via any means
you find comfortable, including this blog post's comments section, on
IRC in the #wikimedia-operations channel, or via the https(a)wikimedia.org
email address.
Greg Grossmeier
[0]
http://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects/
[1] http://meta.wikimedia.org/wiki/HTTPS
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hey,
I'm curious what the stance of WMF is on BSD, MIT and MPL licensed code. In
particular, could such code be deployed on WMF servers?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
Hey,
Two days ago I created a tag for Diff [0]. While I'm writing this mail, the
tag has yet to appear on the GitHub mirror [1]. I made a commit after I
first noticed the tag did not appear to see if replicating that would also
sync the tags, which turned out not to be the case, as the commit made it
onto GitHub, while the tag did not show up.
We do not appear to have an appropriate component on bugzilla for this
piece of our infrastructure, so reporting the issue here.
[0] tag "0.8"
https://git.wikimedia.org/tags/mediawiki%2Fextensions%2FDiff.git
[1] https://github.com/wikimedia/mediawiki-extensions-Diff/releases
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
Sumana Harihareswara <sumanah <at> wikimedia.org> writes:
>
> I've been accepted to Hacker School <https://www.hackerschool.com>, a
> writers' retreat for programmers in New York City. I will therefore be
> taking an unpaid personal leave of absence from the Wikimedia Foundation
> via our sabbatical program. My last workday before my leave will be
> Friday, September 27. I plan to be on leave all of October, November,
> and December, returning to WMF in January.
>
> During my absence, Quim Gil will be the temporary head of the
> Engineering Community Team. Thank you, Quim! I'll spend much of
> September turning over responsibilities to him. Over the next month I'll
> be saying no to a lot of requests so I can ensure I take care of all my
> commitments by September 27th, when I'll be turning off my wikimedia.org
> email.
>
> If there's anything else I can do to minimize inconvenience, please let
> me know. And -- I have to say this -- oh my gosh I'm so excited to be
> going to Hacker School in just a month! Going from "advanced beginner"
> to confident programmer! Learning face-to-face with other coders, 30-45%
> of them women, all teaching each other! Thank you, WMF, for the
> sabbatical program, and thanks to my team for supporting me on this. I
> couldn't do this without you.
>
Congratulations, Sumana! This sounds like a great opportunity for you. It
is so great that programs like Hacker School and OPW are springing up these
days to help people that are out of school get experience becoming better
programmers. I'm looking forward to hearing about your experiences there.
--Rachel
*Gnome FOSS Outreach Program for Women Intern
Browser Test Automation, Wikimedia Foundation*
hi,
yuvi said he is not able to add account creation to the wlm mobile app
because the mw api is not usable. there is a bug filed in march, now
approaching 6 months age:
https://bugzilla.wikimedia.org/show_bug.cgi?id=46072
with priority "high", which means according to andre klapper:
https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority
"Not the next task, but should be fixed soon. Depending on teams &
manpower this can take between one and six months."
who needs to do what to get this fixed?
(sorry for crossposting to wikitech, as i understood this is not a
mobile problem ...)
rupert.
On Sun, Sep 2, 2012 at 2:57 AM, Tomasz Finc <tfinc(a)wikimedia.org> wrote:
> Sadly not for this contest. The API to create accounts never reached
> enough maturity while this app was in development.
>
> Background info here : http://www.mediawiki.org/wiki/User:Akshay.agarwal
>
> Thats why we dont require it to save images for later upload. I agree
> that this would be great to have in the future.
>
> --tomasz
>
>
> On Sat, Sep 1, 2012 at 1:41 PM, Cristian Consonni
> <kikkocristian(a)gmail.com> wrote:
>> 2012/9/1 rupert THURNER <rupert.thurner(a)gmail.com>:
>>> hi philip,
>>>
>>> would it be possible to add an account creation screen to the wlm mobile app?
>>
>> I posted the same request here:
>> http://www.mediawiki.org/wiki/Wiki_Loves_Monuments_mobile_application/Feedb…
>>
>> a couple of days ago.
>>
>> Cristian
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Fri, Aug 23, 2013 at 6:39 PM, Greg Grossmeier <greg(a)wikimedia.org> wrote:
> == Thursday ==
> * CodeEditor support will be enabled for all JS and CSS on all wikis
>
Without fixing the bug which makes it use spaces instead of tabs? Seriously?
https://bugzilla.wikimedia.org/show_bug.cgi?id=39616
Helder
Hello,
This is a reminder that the Language Engineering team will be hosting
an hour long bug triage for R-T-L bugs later today, i.e. August 28,
2013 at 1700 UTC/1000 PDT on the IRC channel #mediawiki-i18n
(Freenode).
etherpad link: https://etherpad.wikimedia.org/p/BugTriage-i18n-2013-08
Thanks
Runa
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Fri, Aug 23, 2013 at 11:56 AM
Subject: Language Engineering bug triage session for RTL language bugs
- Aug 28th 2013, Wednesday 1700 UTC/1000PDT
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Wikimedia
Mailing List <wikimedia-l(a)lists.wikimedia.org>, MediaWiki
internationalisation <mediawiki-i18n(a)lists.wikimedia.org>
Hello,
The Wikimedia Language Engineering team will be hosting a bug triage
session on Wednesday, August 28th 2013 at 17:00 UTC (10:00 PDT) for
some of the bugs that exist in languages written from Right-to-Left
(RTL). During this 1 hour session we will be using the etherpad
linked below to collaborate. We have already listed some bugs, but
please feel free to add more bugs (or file new ones!), and comments
about what you’d like to see addressed during the session. You can
send questions directly to me on email or IRC (nick: arrbee). Please
see below for the event details.
Thank you.
regards
Runa
=== Event Details ===
# What: Bug triage session for RTL language bugs
# Date: August 28, 2013 (Wednesday)
# Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130828T1700
)
# IRC Channel: #mediawiki-i18n (Freenode)
# Etherpad: https://etherpad.wikimedia.org/p/BugTriage-i18n-2013-08
Questions can be sent to: runa at wikimedia dot org
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
I know this list isn't really for linking stuff, but I found this article
earlier today:
http://zenol.fr/site/2013/08/27/an-alternative-error-handling-strategy-for-…
It's about C++, but what it describes is very relevant to our error
handling since we use the exact same pattern (via the Status class) except
in PHP.
Right now MediaWiki is a big mix of the three patterns: sometimes functions
return false on error, sometimes they throw exceptions, and sometimes they
return a Status object with error info.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com