I wrote up how we're putting documentation files in git in
Manual:Coding_conventions [1]. It's nothing new, it mentions README.md,
.txt files, etc.
I would prefer extensions on files like COPYING and HISTORY, as it's
friendlier for Windows users and if the file actually uses Markdown or
wikitext markup it lets Diffusion, GitHub, and syntax highlighters do a
better job. I filed T116690 "Give text files in Git correct extensions".
I noticed two conventions for the extension of wikitext files in git:
.mediawiki and .wiki, e.g. tests/browser/README.mediawiki and
extensions/Wikibase/docs/lua.wiki. GitHub will render both kinds as
MediaWiki wikitext (of course it only implements a subset); it seems
Phabricator doesn't recognize either extension. I think we should be
consistent. .mediawiki is more precise (it's not MoinMoin or IkeWiki
markup) while .wiki is shorter. Maybe there are other arguments for one
extension over the other.
Thanks for any thoughts!
[1] https://www.mediawiki.org/wiki/Manual:Coding_conventions#Text_documents
--
=S Page WMF Tech writer
The reading team are keen to have watchstars in more places other than
just at the top right of the page you are viewing.
We already supporting adding things to the watchlist in search,
nearby, watchlist and gather.
We are working on a read more feature which will add a list of pages
with watchstars at the bottom of the page [1]
The code in desktop however is limited in that it is only written to
be usable by the page in question. It does various things such as use
the element id to reflect state (#ca-watch or #ca-unwatch) and runs
once on loading of the script.
We'd like to make this code more reusable so watchstars can be placed
in any interface but this comes with problems.
The model part is not too controversial but when it comes to creating
a reusable UI it becomes a little more complicated.
If we are to turn this into an OOjs UI widget, this would mean that
the OOjs UI library gets pulled in on every single page load. The OOjs
UI library, without styles or icon assets from what I can see is 226.5
kB (without gzip), (for comparisons Backbone is 69kb and React js is
559kb). This is not necessarily an issue, if all our code is built in
OOjs UI but right now we are very very far from that world, so we need
to find a strategy to getting there.
We know this is a problem. When Echo relaunched the new interface
there was a huge spike in first paint [2]. It seems the solution to
this was to render the button on the server side and defer load the
library to avoid this impact on first paint but the underlying problem
still remains - server side rendering is not an option for my team,
so to create a component the standard way we have to load this entire
library.
We have a similar problem with adopting OOJS UI in MobileFrontend. We
want to simply render/style a button on page load via JavaScript and
the library is too heavy weight for this, especially when right now we
don't have use cases for more complicated widgets such as layouts,
popups, windows, toolbars [3]... in fact we already have other
libraries that fulfill these needs that at some point will need to be
converted to oojs ui.
There's been some talk but little movement about cutting up the oojs
ui library into chunks to make it more adoptable by less complex
projects who just need buttons/inputs and other form elements. Is this
still an option? If so, how can we move this along? If not how can we
proceed?
I really think now is the time to talk about this, as adoption outside
the editing team still seems to be limited and from my point of view
this is one of the biggest barriers.
[1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Read_more
[2] https://phabricator.wikimedia.org/T112401
[3] https://www.mediawiki.org/wiki/OOjs_UI
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.
In the next RFC meeting, we will discuss the following RFC:
* Streamlining Composer usage
<https://phabricator.wikimedia.org/T105638>
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 22:00
* US PST: Wednesday 14:00
* Europe CET: Wednesday 23:00
* Australia AEDT: Thursday 09:00
-- Tim Starling
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,
I am happy to announce that the Software-Development Team at WMDE (TCB)
developed the so called “Deepcat” gadget [1] that is now ready to use not
only in German wikis but also internationally.
The possibility for intersection and subcategory search was one of the
top-wishes from the TOP20 of the Germany Community Technical Wishlist [2].
DeepCat acts as an interface between a graph database and MediaWiki's
search engine. The Wiki's category structure is stored via their page-ids
in the graph database while the Gadget does the translation of the search
string, retrieves the information from the database and sends it to the
search engine. Tool developers interested in exploring possibilities for
using the CatGraph database can find more information on the respective
infopage [3] or can approach us directly.
The Deepcat gadget allows to go deeper in the category search and generates
results not only for a certain category but also for its subcategories.
Furthermore, it supports intersection search (among others: searching for
articles or pictures that are in two different categories e.g. “Art” and
“Technology”). The gadget works on Wikipedia, on Wikimedia Commons, as well
as in many other wikis [4]. For performance and technical reasons there is
a search limitation of 15 categories in depth and 70 categories in total
that the gadget can search through (you will see a hint about that while
using the gadget). The gadget doesn’t load on mobile devices however once
you switch to desktop-view, it should work as usual.
The gadget can be used via typing the keyword “deepcat:” into the regular
search field. An instruction how to install Deepcat and a detailed
description of its functionality can be found on its infopage [5]. Bugs can
be reported on Phabricator [6].
We hope it will serve you well!
Cheers,
Kasia
[1] https://github.com/wmde/DeepCat-Gadget
[2]
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Technische_W%C3%BCnsche/To…
[3] https://wikitech.wikimedia.org/wiki/Nova_Resource:Catgraph
[4] https://tools.wmflabs.org/cgstat
[5] https://wikitech.wikimedia.org/wiki/Nova_Resource:Catgraph/Deepcat
[6]
https://phabricator.wikimedia.org/maniphest/task/create/?projects=DeepCat-G…
--
Kasia Odrozek
Product Manager
Software Development and Engineering
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. +49 (030) 219 158 260
Mobil: +49 151 46752534
http://wikimedia.de <http://www.wikimedia.de/>
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hi Subbu,
How hard would it for Parsoid to mark red links in a way that the Mobile
Content Service could detect them (e.g. add class="new")? I've filed
https://phabricator.wikimedia.org/T117519.
Thanks,
Bernd
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 all,
Sorry to be spamming this list due to my own incompetence. I'm basically
doing an upgrade-a-thon of our various extensions to the new extension
format, and therefore running into issues as I go.
In a previous email I discussed a problem I was having with the fact that
the new extension registration doesn't support PHP constants, which I was
using for explicit dependencies. Now I'm working on upgrading another
extension where I use PHP constants to allow users to configure options for
my extension.
My extension is called CommentStreams. In the old registration approach,
inside of CommentStreams.php, I had three constants defined:
define('NS_COMMENTSTREAMS', 1000);
define('CS_COMMENTS_EXPANDED', 0);
define('CS_COMMENTS_COLLAPSED', 1);
NS_COMMENTSTREAMS is a custom namespace I define using the
CanonicalNamespaces hook, but I wanted to expose this variable through a
PHP constant so users could configure the extension in LocalSettings.php,
for example for use with $wgNamespacesToBeSearchedDefault:
$wgNamespacesToBeSearchedDefault[NS_COMENTSTREAMS] = true;
(Of course I could just require the user of my extension to define
NS_COMMENTSTREAMS in their own LocalSettings.php, but I wanted to
encapsulate it in the extension so they wouldn't have to worry about it.)
The story with CS_COMMENTS_EXPANDED and CS_COMMENTS_COLLAPSED is similar -
internally defined constants that I wanted to expose for users to be able
to use to configure things in LocalSettings.php.
With the new extension registration, I tried to put these constant
definitions inside of the custom registration
<https://www.mediawiki.org/wiki/Manual:Extension_registration#Customizing_re…>
callback function, hoping that this callback would be called before the
rest of LocalSettings.php is parsed, so the usage could remain something
like this:
wfLoadExtension('CommentStreams');
$wgNamespacesToBeSearchedDefault[NS_COMMENTSTREAMS] = true;
// other configuration with CS_COMMENTS_EXPANDED or CS_COMMENTS_COLLAPSED
However, that doesn't seem to be the case - I get warnings of defined
constants all over the place, breaking my functionality.
Is there a way around this? Alternatively, if this is bad coding practice
(I do not profess to be well versed in good PHP convention, and I'm still
learning good MediaWiki convention), is there a better way to handle this?
Thanks for the assistance!
--
Jason Ji
jason.y.ji(a)gmail.com
Hi all -
The Discovery and Reading product/engineering verticals did a merged
showcase last week for people to demonstrate new work and experiments.
https://www.youtube.com/watch?v=LNAQD4RCeWM
Enjoy!
The first 7 minutes or so the opening slide deck isn't showing (the people
in the room are showing instead). See
https://upload.wikimedia.org/wikipedia/commons/b/be/IOS_Wikipedia_App_5.0_U…
for the corresponding, actually expanded, slide deck. Starting at 7:43 the
hands on demos begin.
-Adam