Hi,
I have a software using mediawiki api with Wikipedia. It uses general http
requests. Suddenly it stopped working several days ago (maybe a week, I
can't recall exactly). When I query a test query in a browsers, it
redirects to https, I see also that at the side sites that there's also 301
redirects. But I can not find any official information that http requests
no long work.
Please, let me know whether I have an option to continue work with http
requests or SSL now is mandatory
Thanks
Max Vlasov
Fyi
---------- Forwarded message ----------
From: "Yuvi Panda" <yuvipanda(a)gmail.com>
Date: Jun 12, 2015 6:05 PM
Subject: Labs bastions ssh key changes (affects all non-toollabs users)
To: <labs-announce(a)lists.wikimedia.org>
Cc:
Hello!
In the ongoing effort to make labs more reliable, we're upgrading
Labs' bastion hosts to Debian Jessie, and disabling NFS on them all.
This means two things:
1. On Monday June 15th 12:00 UTC, the ssh fingerprint of the labs
bastion (bastion.wmflabs.org) will change, and all active connections
via it will drop momentarily. The new keys are available at
https://wikitech.wikimedia.org/wiki/Help:SSH_Fingerprints/bastion.wmflabs.o…
2. Other bastion domains (bastion2.wmflabs.org,
bastion3.wmflabs.org) will stop working then. I've been privately
emailing people who have been using those, and I'm pretty sure I got
them all.
3. No more NFS on the bastion hosts, which means your current home
directory contents there will be 'missing'. They can be recovered for
you by a labs admin, but you shouldn't be having things in there
anyway...
https://phabricator.wikimedia.org/T95924 is the underlying task for this.
Thanks
--
Yuvi Panda T
http://yuvi.in/blog
This is a suggestion to change search, so it ignores
postfix accents.
Russian dictionaries (including Wiktionary) use accents to
indicate stress on syllables, but these accents are never
seen in plain text.
In Russian Wiktionary, the verb бороться has the
inflected form боритесь (imperative, plural),
which does not have an entry of its own, but
appears in a fact box (table) of inflected forms.
However, since this is a dictionary, the word in
the box is written with an accent: бори́тесь
https://ru.wiktionary.org/wiki/бороться
(I do realize that it would be possible to add
redirect entries for all such inflected forms,
but this has not been done in ru.wiktionary.)
Searching for бори́тесь (which nobody would do)
finds the relevant page,
https://ru.wiktionary.org/w/index.php?search=бори́тесь
but searching for боритесь (the normal thing)
does not find the relevant page,
https://ru.wiktionary.org/w/index.php?search=боритесь
Note that Unicode doesn't contain accented versions
of Cyrillic letters. Instead, the accent is made
by suffixing a separate accent sign.
$ echo "и" | od -c
0000000 320 270 \n
$ echo "и́" | od -c
0000000 320 270 314 201 \n
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
Hello everyone,
On Monday UTC morning, the software powering etherpad.wikimedia.org,
etherpad-lite, will be upgraded to version 1.5.6-2 from 1.4.1-3. This
upgrade sets us back on track with etherpad-lite releases. Changelogs for
the interested are here:
https://github.com/ether/etherpad-lite/blob/develop/CHANGELOG.md
The reason for this heads up is that after the upgrade, users will have to
force a full refresh in old pads they revisit in order to clear the browser
cache. Otherwise in some revisited pads, a corrupted interface will show up
with a message about a missing Cookie. The sequence for this is highly
dependent on the browser. Ctrl+F5, F5, Command+R depending on browser/OS
does the trick most times. Refer to your browser documentation for an
accurate shortcut if you don't already know it.
Regards,
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
When creating thumbnails I've been successful at selecting the particular
frame of a video to be shown as the thumbnail. Is there a way to do
something similar, to show a particular page of a PDF as the thumbnail in
an article?
Thanks,
Pine
I've been passing the last few days feverishly working on audio/video
stuff, cause it's been driving me nuts that it's not quite in working shape.
TL;DR: Major fixes in the works for Android, Safari (iOS and Mac), and
IE/Edge (Windows). Need testers and patch reviewers.
*== ogv.js for Safari/IE/Edge ==*
In recent versions of Safari, Internet Explorer, and Microsoft's upcoming
Edge browser, there's still no default Ogg or WebM support *but* JavaScript
has gotten fast enough to run an Ogg Theora/Vorbis decoder with CPU to
spare for drawing and outputting sound in real time.
The ogv.js decoder/player has been one of my fun projects for some time,
and I think I'm finally happy with my TimedMediaHandler/MwEmbedPlayer
integration patch <https://gerrit.wikimedia.org/r/#/c/165478/> for the
desktop MediaWiki interface.
I'll want to update it to work with Video.js later, but I'd love to get
this version reviewed and deployed in the meantime.
Please head over to https://ogvjs-testing.wmflabs.org/ in Safari 6.1+ or IE
10+ (or 'Project Spartan' on Windows 10 preview) and try it out!
Particularly interested in cases where it doesn't work or messes up.
*== Non-JavaScript fallback for iOS ==*
I've found that Safari on iOS supports QuickTime movies with Motion-JPEG
video and mu-law PCM audio <https://gerrit.wikimedia.org/r/#/c/217295/>.
JPEG and PCM are, as it happens, old and not so much patented. \o/
As such this should work as a fallback for basic audio and video on older
iPhones and iPads that can't run ogv.js well, or in web views in apps that
use Apple's older web embedding APIs where JavaScript is slow (for example,
Chrome for iOS).
However these get really bad compression ratios, so to keep bandwidth down
similar to the 360p Ogg and WebM versions I had to reduce quality and
resolution significantly. Hold an iPhone at arm's length and it's maybe ok,
but zoom full-screen on your iPad and you'll hate the giant blurry pixels!
This should also provide a working basic audio/video experience in our
Wikipedia iOS app, until such time as we integrate Ogg or WebM decoding
natively into the app.
Note that it seems tricky to bulk-run new transcodes on old files with
TimedMediaHandler. I assume there's a convenient way to do it that I just
haven't found in the extension maint scripts...
*== In progress: mobile video fixes ==*
Audio has worked on Android for a while -- the .ogg files show up in native
<audio> elements and Just Work.
But video has been often broken, with TimedMediaHandler's "popup
transforms" reducing most video embeds into a thumbnail and a link to the
original file -- which might play if WebM (not if Ogg Theora) but it might
also be a 1080p original which you don't want to pull down on 3G! And
neither audio nor video has worked on iOS.
This patch <https://gerrit.wikimedia.org/r/#/c/217485/> adds a simple
mobile target for TMH, which fixes the popup transforms to look better and
actually work by loading up an embedded-size player with the appropriately
playable transcodes (WebM, Ogg, and the MJPEG last-ditch fallback).
ogv.js is used if available and necessary, for instance in iOS Safari when
the CPU is fast enough. (Known to work only on 64-bit models.)
*== Future: codec.js and WebM and OGVKit ==*
For the future, I'm also working on extending ogv.js to support WebM
<https://brionv.com/log/2015/06/07/im-in-ur-javascript-decoding-ur-webm/>
for better quality (especially in high-motion scenes) -- once that
stabilizes I'll rename the combined package codec.js. Performance of WebM
is not yet good enough to deploy, and some features like seeking are still
missing, but breaking out the codec modules means I can develop the codecs
in parallel and keep the high-level player logic in common.
Browser infrastructure improvements like SIMD, threading, and more GPU
access should continue to make WebM decoding faster in the future as well.
I'd also like to finish up my OGVKit package
<https://github.com/brion/OGVKit> for iOS, so we can embed a basic
audio/video player at full quality into the Wikipedia iOS app. This needs
some more cleanup work still.
Phew! Ok that's about it.
-- brion
Do you use our search API? If so, I'd like to hear from you!
The Discovery Department
<https://wikimediafoundation.org/wiki/Staff_and_contractors#Discovery> at
the Wikimedia Foundation is tasked with building a path of discovery to
relevant and trusted knowledge. In line with that, one of our primary
responsibilities is to ensure that our search APIs are stable, fast, and
easy to use. We'd love to hear from the people that are using our APIs, so
we can learn what you love about them, what frustrates you, and what we can
do to improve them for you.
I'd prefer that you keep the comments about the API itself rather than the
relevance of the results it returns; I plan to start a separate thread
about the result relevance, since they're separate topics.
If you have some feedback, please reply in this thread or reach out to me
privately.
Thanks!
Dan
--
Dan Garry
Product Manager, Discovery
Wikimedia Foundation