Yay :D
Sent from my HTC
----- Reply message -----
From: "Bartosz Dziewoński" <matma.rex(a)gmail.com>
To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
Subject: [Wikitech-l] FYI: HTMLForm is now available in OOUI format
Date: Wed, Jul 22, 2015 15:45
It took a while, but most of the issues are ironed out now. OOUI still
doesn't support subsections, as that would require some refactoring of
gnarly old code. Everything else should work well enough.
--
Bartosz Dziewoński
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi all - you've probably seen the reading-web, android, and ios related
boards in Phabricator, but I wanted to share another with you:
https://phabricator.wikimedia.org/tag/reading-admin/
This is a place the Reading management team adds and tracks more manager
oriented tasks.
As tasks get moved to Done, we will in the future probably actually want to
check into whether they should be moved farther left in the board to be
repeated / re-reviewed or figure out some appropriate lightweight workflow
for such things.
-Adam
As part of the on-going UI standardisation work[0], we have just merged
into MediaWiki master a patch that will allow users of HTMLForm[1] to
easily switch over to use OOUI[2]. This allows you to make your code use
the standard UI styling and components with very little effort, improving
consistency and accessibility.
To convert your code over from the existing styling of MediaWiki's HTMLForm
(or its VForm version), you can replace the instantiation command of
- $form = new HTMLForm( … );
- or:
- $form = HTMLForm::factory( 'vform', … );
-
with
- $form = HTMLForm::factory( 'ooui', … );
… and everything Should Just Work™.
This doesn't break anything for existing use of this code, and you can
explicitly retain the existing styling by using $form = HTMLForm::factory(
'table', … ); or 'div' or 'vform' instead if you wish. Feel free to add
your code to the epic task on Phabricator which is the central liaison
point for this work[3].
Finally, please be careful to check your interfaces after converting them –
although we have tested this and believe it works well, there may be some
edge cases where it doesn't quite work. We're still missing a few features
[4] (such as prettier radio buttons), which we're hoping to have ready in a
week or two. If do you find any such issues, please report them so we can
fix them. Also note that OOUI already implements the new "MediaWiki" theme
for all users, so please ensure you advertise the visual changes as they
roll out to minimise disruption.
[0] - https://phabricator.wikimedia.org/T49145
[1] - https://www.mediawiki.org/wiki/HTMLForm
[2] - https://phabricator.wikimedia.org/T85291
[3] - https://phabricator.wikimedia.org/T100270
[4] - https://phabricator.wikimedia.org/T100279
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hi,
Now that SULF is over, we have no need for the AccountAudit extension
anymore. If you have been relying on it for any statistics, please be
aware that a) it is going away soon and b) the data is generally
inaccurate for global users (which all users are now).
Please follow <https://phabricator.wikimedia.org/T105894> for updates.
Thanks,
-- Legoktm
Hi!
We're trying to use the collections (a beta wikipedia feature) on a
wikimedia external website, http://wikijourney.eu, which delivers
wikipedia-driven tourist tours.
In order to use the collections' API, we need the user to log in his
wikipedia account, and it would be nice to have a log-in form directly
on the website. Does anyone know if it's possible?
Hi all,
I have been working on a small VE plugin that provides the functionality of
adding SMW annotations. I am mostly done with the script but need to
understand some minor coding practices for VE plugins to complete it. Would
appreciate some help on these questions.
When the script makes some changes to the document model, sometimes the
"Save" button stays greyed out. Is there a way I should trigger the save
button to become active? Or maybe I am doing something in the wrong way.
The "undo" doesn't seem to automatically work for my code, what's the best
way to develop that functionality?
I have a couple more doubts, but these are the major ones right now.
Here's my code if needed, its a mess right now and needs lot of
refactoring, etc
https://en.wikipedia.org/wiki/User:Nischayn22/veSMW.js
Thanks and regards,
Nischay Nahata
There were a fair number of folks interested in video chatting at
Wikimania! A few quick updates:
* An experimental 'Schnittserver' ('Clip server') project has been in the
works for a while with some funding from ze Germans; currently sitting at
http://wikimedia.meltvideo.com/ (uses OAuth, has a temporary SSL cert, UI
is very primitive!) It is currently usable already for converting MP4 etc
source footage to WebM!
The Schnittserver can also do server-side rendering of projects using the
'melt' format such as those created with Kdenlive <https://kdenlive.org/>
and Shotcut <http://www.shotcut.org/> -- this allows uploading your
original footage (usually in some sort of MP4/H.264 flavor) and sharing the
editing project via WebM proxy clips, without generational loss on the
final rendering.
Once rendered, your final WebM output can be published up to Commons.
I would love to see some more support for this project, including adding a
better web front-end for managing projects/clips and even editing...
* Mozilla has an in-browser media editor thing called Popcorn.js
<http://popcornjs.org/>; they're unfortunately reducing investment in the
project, but there's some talk amon people working on it and on our end
that Wikimedia might be interested in helping adapt it to work with the
Schnittserver or some future replacement for it.
Unfortunately I missed the session with the person working on Popcorn.js,
will have to catch up later on it!
* I'm very close to what I consider a 1.0 release of ogv.js
<https://github.com/brion/ogv.js/>, my JavaScript shim to play Ogg (and
experimentally WebM) video and audio in Safari and MS IE/Edge without
plugins.
Recently fixed some major sound sync bugs on slower devices, and am
finishing up controls which will be used in the mobile view (when not using
the full TimedMediaHandler / MwEmbedPlayer interface which we still have on
the desktop).
Demo of playback at https://brionv.com/misc/ogv.js/demo2/
A slightly older version of ogv.js is also running on
https://ogvjs-testing.wmflabs.org/ with integration into TimedMediaHandler;
I'll update those patches with my 1.0 release next week or so.
* Infrastructure issues:
I had a talk with Faidon about video requirements on the low-level
infrastructure layer; there are some things we need to work on before we
really push video:
- seeking/streaming a file with Range subsets causes requests to bypass the
Varnish cache layer, potentially causing huge performance problems if
there's a usage spike!
- very large files can't be sharded cleanly over multiple servers, which
makes for further performance bottlenecks on popular files again
- VERY large files (>4G or so) can't be stored at all; which is a problem
for high-quality uploads of things like long Wikimania talks!
For derivative transcodes, we can bypass some of these problems by chunking
the output into multiple files of limited length and rigging up 'gapless
playback', as can be done for HLS or MPEG-DASH-style live streaming. I'm
pretty sure I can work out how to do this in the ogv.js player (for Safari
and IE) as well as in the native <video> element playback for Chrome and
Firefox via Media Source Extensions
<https://developer.mozilla.org/en-US/Apps/Build/Audio_and_video_delivery/Liv…>.
Assuming it works with the standard DASH profile for WebM, this is
something we can easily make work on Android as well using Google's
ExoPlayer <https://developer.android.com/guide/topics/media/exoplayer.html>.
DASH playback will also make it easier to use adaptive source switching to
handle limited bandwidth or CPU resources.
However we still need to be able to deal with source files which may be
potentially quite large...
* List and phab projects!
As a reminder there's a wikivideo-l list:
https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
and a Wikimedia-Video project tag in phabricator:
https://phabricator.wikimedia.org/tag/wikimedia-video/
Folks who are interested in pushing further work on video, please feel free
to join up. There's a lot of potential awesomeness!
-- brion
Is it possible to set up a universal spam filter that will apply for all
Wikimedia email lists? For example, would it be possible to have a master
list of blackslisted sender email addresses that all lists will check for
blocked senders before putting an email into the moderation queue for
individual lists?
Thanks,
Pine
Hi,
I am not sure if this is the correct mailinglist to write.
Every week on commons a bot is rotating hunderts of files, however this bot will stop working soon. In the last years tens of thousands files has been rotated.
Rotating files is a vital feature on commons and therefore indispensable. The bugreport [1] on phabricator is open since three years, but, unfortunately no dev is working on it. The bug has also a lot of +1 (tokens).
I am wonder if it is possible to enable and code review this feature asap.
:-)
Best,
Steinsplitter
[1] https://phabricator.wikimedia.org/T35186