As part of a side project in my job at Redwerks[1], I've released an
early version of a mediawiki-extension cli tool.
https://github.com/redwerks/mediawiki-extension-command#readme
The tool requires Node.js (in addition to git and php to run clones and
composer).
It can be installed with `sudo npm install -g mediawiki-extension` and
then `mediawiki-extension setup`.
The command can download and upgrade any extension we have in Gerrit.
Extensions using composer will automatically be installed via composer
otherwise it'll be cloned from git. If available, release tags (like
"1.0.0" or "v3.0.0") will be used, otherwise master will be used.
You'll still need to require and configure the extension yourself. But
this is supposed to greatly simplify acquiring and bulk-updating
extensions via the cli.
Some examples of use.
Clone ParserFunctions from git.
$ mediawiki-extension download ParserFunctions
Install SemanticMediaWiki and SemanticForms with composer.
$ mediawiki-extension download SemanticMediaWiki SemanticForms
Clone Widgets with from git and checkout the most recent version tag.
$ mediawiki-extension download Widgets
Update all your MediaWiki extensions:
$ mediawiki-extension update --all
Switch an extension cloned from git master to the REL branch for the
installed version of MediaWiki.
$ mediawiki-extension switch ParserFunctions git-rel
[1] http://redwerks.org/
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
Please join for the following tech talk:
*Tech Talk**:* Nothing Left but Always Right: The Twisted Road to RTL
Support
*Presenter:* Moriel Schottlender
*Date:* November 02, 2015
*Time: *20:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+Nothi…>
Link to live YouTube stream <http://www.youtube.com/watch?v=qmLdHuFRGgM>
*IRC channel for questions/discussion:* #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/ck5ibgn8l2t056h5…>,
another
place for questions
*Summary: *There are roughly 500 million speakers of Right-to-Left
languages all over the world, and 16 RTL Wikipedias, but support of
right-to-left languages on the Web in general is so abysmal that it is hard
to find a single piece of software that properly supports all the necessary
behaviors. And yet, that's exactly what we're committed on doing for
Wikipedia's right-to-left users.
This talk will demonstrate the challenges that the web poses for Right to
Left languages, some of the solutions that are available, and some of the
work we've been doing to make RTL users' experience better.
Please join for the following tech talk:
*Tech Talk**:* The making of a MediaWiki skin
*Presenter:* Isarra
*Date:* November 03, 2015
*Time: *18:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+The+m…>
Link to live YouTube stream <http://www.youtube.com/watch?v=5b-8-_UpcQc>
*IRC channel for questions/discussion:* #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/cn511a81dbs7ijlf…>,
another
place for questions
*Summary: *MediaWiki's skins, or themes, are a lacking area that needs much
love, but much of the problem simply lies with how little it is known. In
this talk I will walk you through the process to create a skin and show you
how powerful MediaWiki's skinning system can be, even as it is now, going
from cloning the Example skin to a deployable implementation of
long-awaited product: Winter.
Hello all,
The deadline for possible candidates to submit their proposal on Outreachy
application system arrives in ~03 days ( Nov 02, 2015 07:00 UTC ).
Potential candidates are urged to submit their application at
https://outreachy.gnome.org well before the same, to avoid any last minute
surprise.
Currently, our Outreachy'11 board at
https://phabricator.wikimedia.org/tag/outreachy-round-11/ have :
1. 9 ideas in featured project with 8/9 projects with at-least 1
proposal submitted by a candidate
2. 11 proposals by 11 candidates submitted, and under review
As usual, the proposal in Phabricator will be evaluated by the mentors, and
candidates are free to polish it, past-deadline. All mentors and
co-mentors, please make sure that you are signing up in the Outreachy'11
portal [2], as a mentor. Community feedbacks are entertained in the
Outreachy projects and proposals so that none of them get stuck in between.
Editing efforts are also welcome at improving
https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_proje…
which is helping us a lot this term.
[2] https://phabricator.wikimedia.org/T116589
it has been
Thanks,
Tony Thomas <http://blog.tttwrites.in/>
ThinkFOSS <http://www.thinkfoss.com>
*"where there is a wifi, there is a way"*
Hi there,
I'm the primary developer of the VIKI
<https://www.mediawiki.org/wiki/Extension:VIKI> extension and its two
companion extensions, VikiSemanticTitle
<https://www.mediawiki.org/wiki/Extension:VikiSemanticTitle> and
VikiTitleIcon <https://www.mediawiki.org/wiki/Extension:VikiTitleIcon>.
I thought I'd take a look at converting these three extensions to the new
extension registration
<https://www.mediawiki.org/wiki/Manual:Extension_registration> format, but
I ran into a problem. According to the documentation, the new extension
registration does not support PHP constants
<https://www.mediawiki.org/wiki/Manual:Extension_registration/Limitations>.
I use a PHP constant to declare an explicit dependency on VIKI for
VikiSemanticTitle and VikiTitleIcon. In my VIKI.php file, I declare:
*define( 'VIKIJS_VERSION', '1.3');*
And then in VikiSemanticTitle and VikiTitleIcon, I have a check that looks
something like:
*if( !defined( 'VIKIJS_VERSION' ) ) {*
* die('Error: The extension VikiSemanticTitle requires VIKI to be
installed first.');*
*}*
(As an aside, I also happen to use VIKIJS_VERSION as my version number,
which I increment as I release new versions. But that's not as important.)
Because the new extension registration format doesn't support PHP
constants, this no longer works, and I can't run VikiSemanticTitle and
VikiTitleIcon alongside VIKI - the VIKIJS_VERSION constant is seemingly no
longer defined, so any page load dies with the error message above.
If I can't use PHP constants anymore, does anyone have a better
recommendation for declaring explicit dependencies? Or should I just avoid
migrating the VIKI extensions to the new registration format?
Thanks,
--
Jason Ji
jason.y.ji(a)gmail.com
Hi, I'd like to present a new RFC for your consideration:
https://www.mediawiki.org/wiki/Requests_for_comment/Minifier
It is about how we can shave 10-15% off the size if JavaScript
delivered to users.
Your comments are highly welcome!:)
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hi everyone,
The Community Tech team has a new alpha prototype for a RevisionSlider
feature/gadget, which you might be interested in. It's a slider on diff
pages that shows the last 50 revisions to the page, and it helps you
navigate through diffs without having to go back to the history page.
The prototype is super-alpha, really just a proof of concept to see if
people like it enough to spend more time on it. So if you've got a minute,
please come take a look and let us know what you think.
The info/discussion page is on Meta:
https://meta.wikimedia.org/wiki/Community_Tech/RevisionSlider
And you can see the prototype on Test.wikipedia:
https://test.wikipedia.org/w/index.php?title=Main_Page&diff=198918&oldid=19…
Thanks!
DannyH
Community Tech, WMF
Hi everyone,
My name is Akanksha (or akangupt if you've seen me on IRC). I intend to
participate in Outreachy round-11 for the project : Technology to
transclude git content into wiki pages. I have completed respective
microtask for this project and submitted the project proposal too.
Quick Summary : It’s convenient to get the information from wiki pages
directly rather than searching in git repositories for documentation and
code snippets. To facilitate this, developers end up dumping the git-docs
on wiki.
Many times Wiki pages of git-docs are outdated or wrong. This is intuitive
because developers are not required to keep track of every commit/merge in
corresponding repositories and then update the wiki-pages accordingly.
Solution:
In order to avoid outdated, wrong documentations and facilitate the ease of
inserting code snippets from git repositories to wiki, the proposal is to
create an extension, which would transclude the git content in wiki and
update them when corresponding git-docs get updated.
Project Proposal : https://phabricator.wikimedia.org/T117167
Thanks for taking the time to read this and thanks in advance for
any feedback.
Cheers,
Akanksha
Hi,
Going into rant mode...
It's been at least 6 months that CX (Content Translation) has been deployed
on production wikis, and after all this time, most of the articles created
with this tool contain many syntax problems.
Phabricator tasks have been created months ago, and almost nothing seems to
be done to fix this.
So, is there any plan to deactivate CX until major bugs are fixed (to stop
the creation of damaged articles) or any plan to fix the bugs quickly ?
I tried posting on the talk page for CX with this kind of questions months
ago : the answer was that the bug were almost fixed. Several months after
that : same situation, bugs still here, even with some new ones...
Examples by taking the last 5 CX edits on frwiki :
- David Borwein
<https://fr.wikipedia.org/w/index.php?title=David_Borwein&action=edit&oldid=…>
: almost no problems, but because the editor translated only one sentence,
the article is otherwise completely in English. Even with no edits, basic
problem of templates called with the {{Modèle:...}} prefix (equivalent to
{{Template:...) in English)
- Grande Riviere
<https://fr.wikipedia.org/w/index.php?title=Grande_Riviere&action=edit&oldid…>
: many problems : template prefix, nowiki tags in bad places, several
references with the same name and the same content duplicated (the goal of
the name is to have the content once, not in every reference), whitespace
included at the end of internal links (reason for some nowiki tags),
coordinates so badly handled that it results in several lines of span tags
and complex code
- Jozef Gregor-Tajovsky
<https://fr.wikipedia.org/w/index.php?title=Jozef_Gregor-Tajovsk%C3%BD&actio…>
: less than 500 bytes, but with stub category added directly instead of the
templates that should add them
- Silva Semadeni
<https://fr.wikipedia.org/w/index.php?title=Silva_Semadeni&action=edit&oldid…>
: trailing punctuation included in internal links, unnecessary div tags,
internal links with only nowiki tags as the displayed text (so invisible
links), unnecessary span tags, preceding whitespace included in internal
links
- David Steel
<https://fr.wikipedia.org/w/index.php?title=David_Steel&action=edit&oldid=11…>
: almost empty, but with internal CX data added
5 articles checked, not one correct.
Nico
Hi folks,
I wanted to let everyone know about the ArchCom RFC discussions we're
having on IRC in the #wikimedia-office channel. We're having both a
special one tomorrow, and the regularly scheduled one Wednesday UTC.
Tomorrow, we have Phab event E86 scheduled to discuss Task T88459
(Implementing the reliable event bus using Kafka).
Wednesday, we have Phab event E85 to discuss Task T105638
(Streamlining Composer usage)
Please don't wait for an RFC meeting to weigh in on either of these,
though. If you have something to say, comment on the appropriate Phab
task.
Links for those that want 'em:
https://www.mediawiki.org/wiki/User:RobLa-WMF#2015-10-29
Rob