Hello,
I wrote a PHP based JSON linter which would bail out whenever a json
file can't be understood by PHP json_decode().
The linter will be able to the jslint Jenkins jobs which are already
running jshint. It would be nice to pass it on your repositories to
avoid failure when the job is enable which I plan to do next Monday on
March 17th.
The lint script is in integration/jenkins.git bin/json-lint.php which
you can fetch with:
curl
'http://git.wikimedia.org/raw/integration%2Fjenkins.git/master/bin%2Fjson-li…
'> /tmp/json-lint.php
Usage:
json-lint.php .
Example output:
./node_modules/es6-shim/bower.json: Syntax error
./node_modules/es6-shim/component.json: Syntax error
They are missing comma in dictionaries structures of the git repository
mediawiki/services/parsoid/deploy
I have passed the scripts against mediawiki/extensions/* and mw/core but
other repository would need to be verified if they have a jslint job
running.
Thanks!
--
Antoine "hashar" Musso
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.03. This bundle is compatible with MediaWiki 1.22.4 and
MediaWiki 1.21.7 releases.
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.03.tar…
* sha256sum: f3a253e05f6b7c4f451882a1a78a138a1dcaecd2777237d0c2b8af7c3ecced70
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CleanChanges ==
* Only localisation updates.
== CLDR ==
* Updated to CLDR 25.
* Localisation updates.
== LocalisationUpdate ==
LocalisationUpdate is rewritten for JSON file format support for
extensions. This is compatible with MediaWiki 1.19 and above.
* Extensions using JSON are fully supported and LocalisationUpdate
will pickup new languages as they appear.
* LocalisationUpdate will store translation using JSON file format. If
extension is not yet migrated to JSON, messages will be stored as PHP
file.
=== Configuration changes ===
==== Global Variables ====
====== $wgLocalisationUpdateRepository ======
Default repository source to fetch translation. MediaWiki's Github
mirror is set to default repository to fetch translations. This is
added with version 1.1.
===== $wgLocalisationUpdateRepositories =====
Array of repositories URLs from which to retrieve localisations for
core MediaWiki and extensions. Default is set to GitHub's MediaWiki
Git repositories and you should not change this unless you're using
this performance improvement or otherwise know what you're doing. This
is added with version 1.1.
==== Script parameters changes ====
With version 1.1,
--repoid: Fetch translations from repositories identified by this
==== Notes ====
* Once core MediaWiki switches to JSON format, all users must update
LU to keep receiving updates. They will need to update anyway because
older versions of LocalisationUpdate do not support JSON at all.
* If an extension switches to JSON, we will not be able to provide
updates until its local checkout is updated to such a version.
LocalisationUpdate does not know about the switch and will try to
fetch the PHP shim, which does not have translations any longer. This
is usually okay, as the PHP shims support old MediaWiki versions;
problems might appear if the extension has other incompatible changes
which prevent updating.
* For more details, also see:
https://www.mediawiki.org/wiki/Extension:LocalisationUpdate
== Translate ==
=== Noteworthy changes ===
* Added support for insertables with numbers in the end on translatable pages.
* Improvements in TUX shortcuts: Shortcut indicators are now more
visible. Fixed display in RTL. Added indicators for up/down arrows.
* characterEditStats.php: Mention the max age of recent changes
($wgRCMaxAge) limits.
* Added a notice about ULS extension dependency. On Special:Translate,
it will fail with MediaWiki error page if ULS is not installed.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Compacting the interlanguage links with the ULS as new Beta feature.
Displays a shorter version of the language list with the languages
that are more relevant to you. More info at:
https://www.mediawiki.org/wiki/Universal_Language_Selector/Design/Interlang…
* Bug 56081: Reset webfonts where inline css style found upon reset.
This fixes broken live preview for content font.
=== Fonts ===
* Updated Lohit Oriya font to new upstream version and renamed to Lohit Odia.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Hi Gryllida,
I am extremely sorry I took so long to reply to your mail, I was down with
typhoid and I am slowly recovering.
I made corrections as you suggested. Thanks a lot for sparing your time.
As instructed by you I included my full opensource contribution history and
just for the record I am stating it here as well.
I have four bug patches merged from last year. bug
45580<https://bugzilla.wikimedia.org/show_bug.cgi?id=45580>
, bug 43504 <https://bugzilla.wikimedia.org/show_bug.cgi?id=43504>,
bug 33438 <https://bugzilla.wikimedia.org/show_bug.cgi?id=33438> & bug 48197
<https://bugzilla.wikimedia.org/show_bug.cgi?id=48197>
This year due to my ill health I could only get two in.
https://gerrit.wikimedia.org/r/117854https://gerrit.wikimedia.org/r/121975
The last patch is relavant to my gsoc project as it deals with forms which
is kind of a part of the project that I applied to.
I would see to that these two get merged as well and if possible I will
send one more over the next weekend.
The only other open source project that I have contributed to is PHPMYADMIN
which has very high standards for patch acceptance and stringent code
reviews.
I have four patches merged in there as well. Of these one of those is 280
line patch that I talked about in my proposal as well.
The details of the rest of the patches could be found here:
https://github.com/phpmyadmin/phpmyadmin/commits?author=ganeshaditya1
Regards,
Aditya
Hi,
As part of our extension testing, we've set up varnish in accordance
with http://www.mediawiki.org/wiki/Manual:Varnish_caching
One of the things we've noticed is that our oldid URIs are cached,
whereas Wikipedia doesn't seem to cache those pages.
Is there a reason why Wikipedia doesn't do this? Is there some
threshold that Wikipedia uses for caching?
Thanks in advance,
Shawn M. Jones
Graduate Research Assistant
Department of Computer Science
Old Dominion University
I spent a little more time the last few weekends on ogv.js
(JavaScript-based player for Ogg Theora and Vorbis media in IE and Safari)
and have gotten two major things working:
* an all-Flash version -- should work in older IE and Safari versions that
can't run the JS code
* optional GPU acceleration with WebGL or Flash Stage3D where available
More details on my blog:
https://brionv.com/log/2014/03/29/ogv-js-now-in-webgl-and-flash-flavors/
The Flash version generally runs a bit faster than the JS version on IE
10/11, about the same as JS on Safari 6.1/7, and slower than JS on current
Chrome and Firefox. Note that the player demo page currently requires IE 9
or later although the player itself should work on IE 6/7/8.
I've also compared performance to the Cortado Java applet we currently use
-- Cortado is still a little faster in terms of CPU usage, but getting the
applet to actually *run* with the current version of Java is a nightmare --
even the signed version of the applet from theora.org requires adding a
security exception -- whereas JS or Flash "just works".
GPU acceleration in both JS and Flash combines YCbCr->RGB colorspace
conversion into the drawing step and can be a *huge* speed boost at higher
resolutions. At 360p or 160p it's a modest improvement of a couple
milliseconds per frame on my test machines. Note that WebGL is available in
IE 11, but is disabled by default in current versions of Safari (and cannot
be enabled on iOS without a jailbreak).
The main missing feature left is seeking, which I think can be left for
later. I expect to do a bit more performance tuning and code cleanup, but I
think it's time to devise some integration into TimedMediaHandler so people
can try it out "in-place" on Wikipedia & Commons...
-- brion
Hey,
I have been redoing the change email page with vforms and I kinda stuck at
a point where I have the following three choices.
If there is a special page already with two buttons, whose style I could
copy that am not aware of please notify me.
http://ux.stackexchange.com/questions/54894/button-choices-for-canceling-fr…
Also in the previous change email page you should have noticed that when I
enter a invalid email I cannot cancel out of that form. Is that the
expected behaviour( which I highly doubt ) or is that a bug that I could
probably fix.
https://gerrit.wikimedia.org/r/#/c/121975/ -> bug patch.
Regards,
Aditya
Hi all.
I apologize for cross-posting; I'm trying to reach all projects here, and encourage you to translate and spread this message to relevant village pumps. (I explain a tool here, some points, and provide you with a link where you can participate in the discussion I opened.)
The WMF Engineering Team is kindly working on Media Viewer, which would show a pop-up of some sort when you click an image. This tool is available for testing to those people who created an account, in Beta tab, on all projects. Like you may see the tool has a relatively high impact on average reader experience.
It came to my mind that the tool goes full-screen, which doesn't meet the "I stay on the article" expectation. I feel it may be important to an average reader to gain orientation.
I opened a discussion, with some people calling my idea a "metadata pop-up" rather than a "media viewer". I feel that may be good thing: the existing default opens a lot of image info and tells people what Commons is. I feel the media viewer should do something close to the same, with the advantage of not leaving the page, and some interactive means of viewing the image if the user clicks some buttons.
As opposed to that, a "Media Viewer" would show a bigger image and make use of space. But the mock I have is slightly bigger already, like the existing "File:*" page. I am not assuming that the reader wants a bigger image; I'm assuming he may also be interested (and it would be more transparent to) in reading some metadata, description, date, author.
Please see the discussion here and weigh in, basing on your preferences and Wikimedia projects experience. Your voice powers the future of the tool, and Wikimedia projects.
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Please_do…
Regards,
Gryllida.
Yesterday I have held lectures about Wikipedia at the School of Electrical and
Computer Engineering of Applied Studies in Belgrade
[http://www.viser.edu.rs/?lang=EN] and observed them trying to create a new
user
and save an article. Since all the students used the same IP, they have all
triggered captchas, so here are my general remarks. Note that these students
should be more computer literate than most students of their age (early 20s).
Some students have found the captchas to be difficult to read - for example
some
could not differ 'a' from 'x' or 'r' from 'y' - so perhaps captchas should not
be made even more difficult. Captcha localization could help here.
The warning that the article is not saved is not clearly visible, and some
students have managed to not save their articles without realizing that they
have not saved them. The warning could be made more visible, but I believe that
the best way of solving this would be to try to save the article by ajax, and
to
display the captcha on the article editing page itself.
Account creation is botched in several ways, and these are really beginners'
errors for which I don't understand how could they happen in age-old software
as
MediaWiki. Examples:
- If you enter a mismatched password, the error message will only appear after
you click on 'Create your account'. The mismatch could be checked in the
javascript after entering the passwords on the page itself, the same way
duplicate username is checked.
- If you enter the passwords right but the captcha wrong, you have to reenter
the passwords. Basically, whatever mistake you make, you have to reenter the
passwords. I see no reason to do this, the password fields could be pre-filled
with the entered passwords. Also, similar to article saving above, it would be
even better if the captcha would be verified via ajax on the page itself.
- The opposite: if you enter a password wrong but the captcha right, you have
to
reenter the passwords (good) AND reenter the captcha (bad). Some quick typers
have oscillated several times between entering one or the other wrong. I see no
need to have to reenter the captcha once you have entered it correctly - you
have already authenticated as a human.
Also, if I may ask for a wish, a special page where I could enter an IP and
free
it of all the spam filters and protections would be nice and all the
wikieducators would thank you :)