Hi,
this is to let you know that we will start redirecting GET requests
with non-canonical titles to their canonical equivalent next week.
This is done to improve caching, and to ensure reliable purging of
cached responses.
The vast majority of clients handle redirects transparently, so at
most this will lead to a small slow-down from the redirect. To avoid
being redirected, make sure to use underscores instead of spaces, as
in "Main_Page".
Thanks,
Gabriel Wicke
Greetings,
Following up on the reading strategy.
<https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing>
The reading team is launching an experiment that supports early engagement
in ideation phase, with a wide variety of users.
This aims at allowing a public space, where editors, staff and readers, can
submit and discuss ideas around our how to enhance user interaction with
content and with each other on Wikipedia. We plan to run this for 4 weeks,
where after two weeks we can start to narrow down ideas and discuss them in
details. Please check the link below, and feel free to submit ideas, ask
questions or leave a comment, and help us spread the word.
https://www.mediawiki.org/wiki/User_Interaction_Consultation
Best,
Moushira
Hi,
With [1] now merged, the extension phpunit tests that are run by jenkins
will also validate loaded extension.json and skin.json files against the
formal JSON schema (docs/extension.schema.json in core).
To validate locally, you can either run the structure phpunit tests or
use the validateRegistrationFile.php maintenance script.
[1] https://gerrit.wikimedia.org/r/#/c/273751/
-- Legoktm
Thanks for the information lego and thanks for everyone involved getting all extensions pass the schema :)
Gesendet mit meinem HTC
----- Nachricht beantworten -----
Von: "Legoktm" <legoktm.wikipedia(a)gmail.com>
An: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
Betreff: [Wikitech-l] extension.json schema validation is now voting for extensions
Datum: Di., März 15, 2016 01:02
Hi,
With [1] now merged, the extension phpunit tests that are run by jenkins
will also validate loaded extension.json and skin.json files against the
formal JSON schema (docs/extension.schema.json in core).
To validate locally, you can either run the structure phpunit tests or
use the validateRegistrationFile.php maintenance script.
[1] https://gerrit.wikimedia.org/r/#/c/273751/
-- Legoktm
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello!
The 2017 Wikimedia Hackathon Committee and the WMF Developer Relations team
are very pleased to announce that Vienna, Austria has been chosen for the
location of the 2017 Wikimedia Hackathon. The unconfirmed but likely dates
for the hackathon are 19-21 May, 2017.
WMAT and the WMF Developer Relations team will be partnering to organize
and run the hackathon.
For now, you can find more details here:
https://phabricator.wikimedia.org/T127050
Eventually we will update the mediawiki page with more event information:
https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2017
To follow planning progress you can follow the following two projects on
Phabricator after they are created Wikimedia-Hackathon-2017 and
Wikimedia-Hackathon-2017-Organization
For information on the decision process that was followed please check
here:
https://www.mediawiki.org/wiki/Hackathons/2017_Decision_Processhttps://www.mediawiki.org/wiki/Hackathons#Hackathon_location_decision_proce…
If you have any questions about or suggestions for changes in the decision
process please either email me or comment here
https://phabricator.wikimedia.org/T124260.
Hope to see many of you in Jerusalem and again in Vienna!
Rachel Farrand
Engineering Events
Developer Relations (team)
Technical Collaboration (group)
Community Engagement (department)
Wikimedia Foundation
On Mon, Feb 8, 2016 at 2:05 PM, Rachel Farrand <rfarrand(a)wikimedia.org>
wrote:
> Hello!
>
> Is your organization interested in hosting and co-organizing the 2017
> Wikimedia Hackathon? We are looking for proposals!
>
> There is a whole lot of new information available about hackathons, if you
> see anything missing or that needs to be clarified let me know.
>
> Specific to the 2017 Hackathon:
>
> https://www.mediawiki.org/wiki/Hackathons/2017_Decision_Process
>
>
> https://www.mediawiki.org/wiki/Hackathons#Hackathon_location_decision_proce…
>
> All Hackathons:
>
> https://www.mediawiki.org/wiki/Hackathons
>
> https://www.mediawiki.org/wiki/Hackathon_101
>
> https://www.mediawiki.org/wiki/Hackathons/Hackathon_tips_for_organizers
>
> This year’s Wikimedia Hackathon 2016
> <https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016> will be held in
> Jerusalem in April. Ideally we will announce the host for 2017 before March
> 14th, 2016. If multiple chapters or organizations are interested, we hope
> to work together to figure out the the best solution.
>
> Any organizations interested in hosting should please create a Phabricator
> ticket and associate it with the Developer-Relations project.
>
> Example: https://phabricator.wikimedia.org/T96826
>
> Please include as much information as possible from: proposing a hackathon
> <https://www.mediawiki.org/wiki/Hackathons/Proposing_a_hackathon>
>
> Please email me at rfarrand(a)wikimedia.org with any questions or concerns.
> I am not on the chapters@ list, so if there are any responses there
> please remember to keep me on CC.
>
>
> Looking forward to hearing from you!
>
Hello!
Starting at 7pm UTC I will activate HTTPS on our elasticsearch cluster
[1]. This is only preliminary work to actually enable encryption, the
clients (mediawiki) will not be reconfigured until we have fully
tested this deployment.
This is part of the preliminary work for the eqiad -> codfw datacenter switch.
Again, this should have no impact, but I have been known to be wrong
before. If you see strange behaviour around search, please let me
know...
Guillaume
[1] https://gerrit.wikimedia.org/r/#/c/274711/
[2] https://wikitech.wikimedia.org/wiki/Switch_Datacenter
--
Guillaume Lederrey
Operations Engineer, Discovery
Wikimedia Foundation
I'm not the most active bug reporter, but when I report a bug it is usually
because something is broken in one of the non-english languages, and
usually Norwegian. A few of the devs seems to believe that the only
language that mater is English, and that their understanding of "English"
is "The only One".
There are a lot of languages, and solutions that work in English more often
than not does not work in other languages. Please start to handle incoming
bug reports with respect, there are people out there that tries to track
down bugs for you.
Thank you!
Then a small complaint about VisualEditor/Parsoid.
A lot of things are much simpler in VisualEditor, but a lot of stuff is
harder to do or simply does not work. It doesn't matter if things look
shiny if people use a lot more time doing the same task. One area is
editing from the keyboard, how can we do all the same things at least
equally fast - not just that we can do them?
We insert a lot of top-notices (article marks), and edit them, but how can
we do it fast? Yes we can add top-notices as templates, but they are hardly
fast to add that way.
We link and delink articles, but how can we do it fast? (And yes, the -
mumbles "shitty" - interface for linking articles is the reason why I ended
up writing this email)
To me it seems like a lot of work has gone into making the VE very user
friendly, with a constraint that it should be possible to do something, but
without the constraint that it should be fast to do this "thing". Because
of this we have ended up with a lengthy click-click-click (and some more
clickety-click-click-click) to end up with something we at least half the
time must fix with LessVisualEditingWikiText.
John Erling Blad
/grumpy-jeblad
Hi Sir/Madam,
I am Mohd Imran, studying Computer Science
Engineering in IIT Guwahati. I am beginner and i want to contribute to
Gsoc 2016. Can u help me out in getting started to get acquainted with
enough knowledge so that i can get started with the GSoC project.
Thanking you,
yours
sincerely,
Mohd Imran.
On 11 March 2016 at 10:52, ViswaPrabha (വിശ്വപ്രഭ) <vp2007(a)gmail.com> wrote:
>
> Failed my dream :(
>
> Any string in any language in any wikipedia project. How far is my dream?
>
I share your dream! :-)
Unfortunately, the dream is quite far away from reality. Querying every
search index would put a big performance strain on the search servers.
Additionally, it would likely return you a bunch of really irrelevant
results, so there's a lot of user experience implications that would need
to be figured out as well. Discovery is not actively working on this at
present.
Thanks,
Dan
--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation