Hey,
I just wanted to check in about the status of enabling JavaScript package
management usage in MediaWiki. I am basically talking about an equivalent
for JS to what we have with Composer for PHP.
Real-world example:
The "data-values/value-view" package[0] is defining
"jquery.event.special.eachchange.js":
ValueView/lib/jquery.event/jquery.event.special.eachchange.js
Now, recently I needed the same functionality in one of my extensions, so
I just copied it over. [1]
I know that this is the worst way one could do this, but as far as I can
see we don't have that much of a choice right now. Here are the alternative
options I can see:
Moving "jquery.event.special.eachchange.js" out of the
"data-values/value-view" package into its own "WMDE/jquery-eachchange"
package...
1. ... and using it in my extension via composer.
+ pro: two or more extensions or other packages requiring this package
will still result in having only one MW-wide installation..
- con: requires MW specific code which is actually not related to the
MW-independent package to feed the resource loader.
- con: using Composer to manage pure JavaScript packages! Uuuh, ugly!
2. ... and having a build step in other packages using the package, pulling
the "WMDE/jquery-eachchange" somewhere into the file structure of the
packages/extensions using it.
+ pro: don't need to abuse composer, we can use "npm", "Bower" or any
other arbitrary JS package manager here.
- con: got to tell resource loader somehow... (didn't think so much about
that yet)
- con: if more than one extensions or other packages require this package
we still end up with the same code twice or more often in one MW
installation.
3. Combining 1 and 2: Start with 2, using a JS package manager. Then going
to 1, creating a composer package and pulling the "WMDE/jquery-eachchange"
package in via some build script.
+ pro: The two pros from 1 + 2
+ pro: ^^
- con: still got to tell resource loader somehow...
- con: Overhead; We now create two packages where the Composer one is
just a bridge to the MW-world, still polluting packagist.org. Still kind of
ugly and more effort for publishing a package and therefore potentially
scaring programmers away from doing so since they've got better things to
do than doing work that could be automated.
I have not seen Approach 2 and 3 yet. Though I could imagine that the
VisualEditor team has used something like that.
Approach 1 is the way the "data-values/value-view" package itself is being
handled. And that package should actually be a MW independent pure JS
package but right now it contains MW specific code and uses composer for
distribution!
There is still another option but that had to be properly implemented:
4. Choose one native JS package manager for now and go with it (add support
for others later perhaps). Integrate it properly with MW (resource loader
to begin with), document how to use it and finally distribute JS code
coming from the MW world but useful for other projects in a way where it
can actually be used in a non-MW context.
This has already been bugging me when working on Wikidata. Now I'd like to
reuse some of the code I have written there without spending hours and
hours with option 3 because there should be support for option 4 rather
sooner or later.
So I am wondering; Does anyone have any thoughts, any alternatives perhaps
or is there any roadmap on anything like the option 4 that I have shown?
Cheers,
Daniel
[0]: https://packagist.org/packages/data-values/value-view
[1]:
https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses/blob/master/r…
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