Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 21/05/14 07:25, Bartosz Dziewoński wrote: * $IP/extensions/SkinName/ for everything, the rest as above. This makes the skin work exactly like an extension. The only example I could find on mediawiki.org is the Nostalgia skin [5]. I introduced this facility to core many years ago, and I still generally think it is a good idea. There are in fact at least another 6 skins that use this system: they are in mediawiki/extensions/skins in Gerrit -- a directory layout carried over from Subversion. Nostalgia should have been put there too. The main reason I think it is a good idea is code sharing. Treating skins as extensions means you can share automated distribution and installation systems. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 2014-05-20, 10:28 PM, Isarra Yos wrote:
On 20/05/14 23:05, Daniel Friesen wrote:
* The skinname you require is the same one assigned to $wgValidSkins
and set on $wgDefaultSkin and set on $skinname, and $stylepath.
* For all skins using the old autoload pattern the assets directory
remains them same, so nothing has to be re-cached.
But that sounds more like an oversight with the autoloader
implementation and class setup than an actual reason why it would be
good practice to use lowercase. Was there a particular design reason
to set those up to be that way?
I'm not sure which item, you think you're replying to but you might be
misunderstanding what I'm saying.
The key used for $wgValidSkins/$wgDefaultSkin/$skinname has always been
lowercase, and I haven't seen anyone suggesting that we start using
useskin=MonoBook, which would be a bad idea since this key is used in
i18n message keys and the skin- css class – places you don't want to use
upper case letters. Plus of course using upper case letters there is
just asking for a pile of brand new bugs as someone accidentally uses
the wrong case and hard to debug errors start popping up.
And for the bit on re-caching that is simple.
Assets for core skins like Vector and old skins that are implemented
using the autoloader are currently at:
{mediawiki}/skins/vector/*
If you change the directory structure so we load
$IP/skins/Vector/Vector.php (instead of $IP/skin/vector/vector.php) then
the path to assets becomes:
{mediawiki}/skins/Vector/*
Even though not a single one of the assets have changed the URL has, so,
re-cache.
ResourceLoader moves most CSS, JS, and some images to load.php but there
are still resources that are referred to with an actual URL, like
Vector's .htc file, all css images in IE without data: URI support, css
images that aren't marked with @embed (because they're too big, use
multi-backgrounds, etc...), anything in an img using
$skin-getSkinStylePath(...), and any stylesheet still loaded with
addStyle (IE stylesheets, etc...).
Two of those also apply to extensions in general - FooBar and Foo Bar.
Has this sort of inconsistency between name presentations ever posed a
problem there? And with skins in particular, why would the internal
handling of the skin name be coupled to the filename at all? And why
the case-sensitivity, especially when not all platforms that mw
supports even use case-sensitive filesystems? Is this just a holdover
from the autoloader implementation?
Two is fine, the problem is having three, or rather in essence inventing
a third just for skins.
Extensions have two names visible outside of the internal API of the
extension:
* FooBar is a canonical key, it's used in the dirname (plus the entry
file name) and usually (there is some inconsistency) the 'name'
key to extension credits (.
* Foo Bar is the human name, and well, sometimes it doesn't even exist
even when an extension name has multiple words.
There is some inconsistency in what we use in extension credits, we have
a 'name' key and sometimes a human name gets filled in there ('PDF
Handler', 'Central Auth', 'Abuse Filter', ...) and in others the
canonical key gets used (ParserFunctions, SyntaxHighlight, AntiBot,
TorBlock, MobileFrontend, ...), the most common behavior seems to be to
just use the canonical key, giving most extensions only one name. If we
were serious about human names for extensions we would make it possible
to i18n them.
Skins are different, they have two names visible outside of the internal
API of the skin:
* foobar is a canonical key it's used on the key that registers the
skin ($wgValidSkins['foobar'] = ...;), in useskin=foobar,
$wgDefaultSkin = 'foobar', the .skin-foobar css class, the skin's
MediaWiki:Foobar.css (it's ucfirst-ed but it's still foobar not
FooBar.css) and User:X/foobar.css, other i18n messages like
skinname-foobar that defines the skin's other name and messages like
foobar-action-addsection that allow the text used in tabs like Add
section to be controlled on a per-skin basis, and currently used by
every core skins and most 3rd party skins for the assets directory
in $IP/skins/.
* Foo Bar is a human name, this name is visible to all users on the
preference page and – unlike extensions' human name – this one has
full i18n support and is defined by practically every skin. This
name is defined by the skinname-foobar i18n message for the foobar skin.
So:
* Extensions often end up with one name not two.
* FooBar has never been exposed outside of the internal APIs for a
skin (SkinFooBar class names aren't visible anywhere and if
$IP/skins/FooBar.php is used it's autoloaded and not visible to anyone).
* If you did expose FooBar somewhere visible one skin now has three
different names for it.
* And to top that off by using FooBar as the dirname a skin now
basically has two different canonical names for
[Wikitech-l] Improvents to mathtable
Dear all, today a change was merged that changes the creation of the mathtable if it did not exist before.the mathtable. If it does not exist. https://gerrit.wikimedia.org/r/#/c/134326/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Improvents to mathtable
Dear all, today a change was merged that changes the creation of the mathtable if it did not exist before. https://gerrit.wikimedia.org/r/#/c/134326/ Please check if this can have effects to the production environment. Best Physikerwelt ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Square bounding boxes + typesafe enums
Le 21/05/2014 00:32, Sumana Harihareswara a écrit : we'll be talking about Andrew Green's Typesafe enums proposal https://www.mediawiki.org/wiki/Requests_for_comment/Typesafe_enums Hello, I will not be able to attend, but have a minor concern. The Typesafe enums RFC mentions PHP build in [SplEnum] class and dismiss it because it is unintuitive. Before reinventing the wheel, it would be nice to elaborate a bit more as to why SplEnum is unwanted. I am afraid of having to maintain yet another piece of custom code and make the MediaWiki learning curve slightly worth. Ideally we would work with upstream to enhance it and match our needs but I guess it is going to take too long (ie years before it land in production). [SplEnum] http://www.php.net/manual/en/class.splenum.php cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deployments of new, radically different default features
On Sat, May 17, 2014 at 2:55 PM, Rainer Rillke rainerril...@hotmail.comwrote: As some people do not care a lot for beta features or new features, do not read the mailing lists and overlook main discussion forums or are just unable to understand English, they were surprised and confused and wondered how they could disable the feature. Surprised and confused is a good description of how I feel when I visit the main page of Commons and my mouse cursor strays onto the picture of the day. A purple hazard light flares along the edges of the image, presumably intending to alert me to the gross misuse of JavaScript that is about to occur. Then the image pops out like some demented, angry Jack-in-the-box, only nominally larger then the original image (which is still visible below it), but transposed so that it obscures interface elements and page text. Commons has 17 gadgets enabled by default, more than any other wiki I am aware of. The Foundation could always do a better job. But as the saying goes: good manners begin at home. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [Reminder] Language Engineering IRC Office Hour on May 21, 2014 (Wednesday) at 1700 UTC
Hello This is a reminder that the Language Engineering IRC office hour is happening later today at 1700UTC on #wikimedia-office. Please see below for the original announcement and local time. Thanks Runa Monthly IRC Office Hour: == # Date: May 21, 2014 (Wednesday) # Time: 1700 UTC/1000PDT (Check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140521T1700) # IRC channel: #wikimedia-office # Agenda: 1. Content Translation project updates 2. Q A (Questions can be sent to me ahead of the event) -- Forwarded message -- From: Runa Bhattacharjee rbhattachar...@wikimedia.org Date: Mon, May 19, 2014 at 4:11 PM Subject: Language Engineering IRC Office Hour on May 21, 2014 (Wednesday) at 1700 UTC To: MediaWiki internationalisation mediawiki-i...@lists.wikimedia.org, Wikimedia Mailing List wikimedi...@lists.wikimedia.org, Wikimedia developers wikitech-l@lists.wikimedia.org, wikitech-ambassad...@lists.wikimedia.org [x-posted] Hello, The Wikimedia Language Engineering team will be hosting the next monthly IRC office hour on Wednesday, May 21 2014 at 1700 UTC on #wikimedia-office. The event is delayed this month as the team was traveling. In this office hour we will be discussing about our recent work, which has mostly been around the upcoming first release of the Content Translation tool[1]. We will also be taking questions during the session. Please see below for event details and local time. See you at the office hour. Thanks Runa [1] https://www.mediawiki.org/wiki/Content_translation Monthly IRC Office Hour: == # Date: May 21, 2014 (Wednesday) # Time: 1700 UTC/1000PDT (Check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140521T1700) # IRC channel: #wikimedia-office # Agenda: 1. Content Translation project updates 2. Q A (Questions can be sent to me ahead of the event) -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to show the page AND section for CirrusSearch search results
Ok, there might be a problem when a searched term appears in a section header and in other parts of a page. But we have another problem. We have long pages in our mediawiki. If a user search for a term he just receive the link to a page. On this page he has to search for the term again with the browsers search tool to find the right place with the term. We will make this easier and present always additionally a link to the section where the term is first found. I implemented this by adding the complete html text of all pages to the elasticsearch index. As search result I receive the highlighted text together with the complete html text. After extracting the highlighted term I extract the section header for this term from the html text and set sectionSnippet and sectionTitle in class CirrusSearch\Result. This works but is not really smart and not suitable for bigger wikis. Is there a better way? Is it possible to show all section links up the hierarchy (h1, h2, ...) too? Many Thanks! Henry ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deployments of new, radically different default features
Hi Ori, As some people do not care a lot for beta features or new features, do not read the mailing lists and overlook main discussion forums or are just unable to understand English, they were surprised and confused and wondered how they could disable the feature. Surprised and confused is a good description of how I feel when I visit the main page of Commons and my mouse cursor strays onto the picture of the day. A purple hazard light flares along the edges of the image, presumably intending to alert me to the gross misuse of JavaScript that is about to occur. Then the image pops out like some demented, angry Jack-in-the-box, only nominally larger then the original image (which is still visible below it), but transposed so that it obscures interface elements and page text. Unless I am mistaken, this is galleryZoomHover.js [1] It has never been made into a gadget. You and I are two of the mere 11 users (is Special:Search is to be trusted) to have activated this piece of JavaScript in their common.js :-) [1] https://commons.wikimedia.org/wiki/User_talk:Rillke/galleryZoomHover.js -- Jean-Frédéric ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 2014-05-21, 6:02 AM, Jon Robson wrote:
I've always found it silly that skins are installed in a different way
to extensions. It seems silly to teach a user 2 ways. To be honest I
still haven't got the hang of skin installation. I usually crudely
plop a folder in the skins directory which I'm pretty sure is wrong.
Thus, I would personally make skins installable in the same way.
If there is a need to manage that process better, I would steer
someone in the direction of writing a SkinInstaller extension. Such an
extension could protect the end user from the installation process and
could also provide lots of MediaWiki coolness such as reviewing skins,
updating skins and publishing skins.
This would be my vision to steer towards any how...
The current process for installing an extension is:
1. Plop a folder in the extensions directory.
2. Put require_once( $IP/extensions/{name}/{name}.php ); where {name}
is the name of that folder you just plopped in.
The process I'm suggesting for skins is:
1. Plop a folder in the skins directory.
2. Put require_once( $IP/skins/{name}/{name}.php ); where {name} is
the name of that folder you just plopped in, which is also the name
you will use in useskin= or $wgDefaultSkin.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Square bounding boxes + typesafe enums
From my read, SplEnum is a bit janky -- you still have to defibe integer constants and may have to pass them in. The proposal here is more php-natural in that you can say Month::$JANUARY similarly to how you'd use Month::JANUARY, whereas SplEnum recommends the more verbose new Month(Month::JANUARY) or such. You could still do that with SplEnum though by adding the properties, but SplEnum doesn't look like a really fancy wheel; there might not be any benefit to using it if we're just going to use it differently. -- brion On May 21, 2014 2:53 AM, Antoine Musso hashar+...@free.fr wrote: Le 21/05/2014 00:32, Sumana Harihareswara a écrit : we'll be talking about Andrew Green's Typesafe enums proposal https://www.mediawiki.org/wiki/Requests_for_comment/Typesafe_enums Hello, I will not be able to attend, but have a minor concern. The Typesafe enums RFC mentions PHP build in [SplEnum] class and dismiss it because it is unintuitive. Before reinventing the wheel, it would be nice to elaborate a bit more as to why SplEnum is unwanted. I am afraid of having to maintain yet another piece of custom code and make the MediaWiki learning curve slightly worth. Ideally we would work with upstream to enhance it and match our needs but I guess it is going to take too long (ie years before it land in production). [SplEnum] http://www.php.net/manual/en/class.splenum.php cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MW-Vagrant improvements at the Zürich Hackathon
On Fri, May 16, 2014 at 2:40 PM, Arthur Richards aricha...@wikimedia.org wrote: CentralAuth/Multiwiki: Bryan Davis, Chris Steipp, and Reedy spent a lot of time hacking on this, and we now have support for multiwiki/CentralAuth in Vagrant! There is still some cleanup work being done for the role to remove kludge/hacks/etc (see https://gerrit.wikimedia.org/r/#/c/132691/). The CentralAuth role and the associated puppet config that allows creation of multiple wikis as Apache virtual hosts on a single MediaWiki-Vagrant virtual machine have been merged! Go forth and debug/extend CentralAuth. :) I'd love to see additional roles created that use the multwiki::wiki Puppet define to add interesting things for testing/debugging like RTL wikis or other complex features such as WikiData that use a collaboration between multiple wikis in the WMF production cluster. If you're interested in working on something like this and get stuck with the Puppet code needed or find shortcomings in the setup that Chris and I developed I'd be glad to try and help work through the issues. Bryan -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID USA irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
I tend to agree that skins should be installed in exactly the same way as other extensions. This will also help make installation more automateable. -- brion On May 20, 2014 11:39 PM, Tim Starling tstarl...@wikimedia.org wrote: On 21/05/14 07:25, Bartosz Dziewoński wrote: * $IP/extensions/SkinName/ for everything, the rest as above. This makes the skin work exactly like an extension. The only example I could find on mediawiki.org is the Nostalgia skin [5]. I introduced this facility to core many years ago, and I still generally think it is a good idea. There are in fact at least another 6 skins that use this system: they are in mediawiki/extensions/skins in Gerrit -- a directory layout carried over from Subversion. Nostalgia should have been put there too. The main reason I think it is a good idea is code sharing. Treating skins as extensions means you can share automated distribution and installation systems. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 21 May 2014 13:01, Brion Vibber bvib...@wikimedia.org wrote: I tend to agree that skins should be installed in exactly the same way as other extensions. This will also help make installation more automateable. From a product perspective, +1 for this. Dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
But why create a new system to learn? What is the advantage of doing
this instead of just using the tried and tested extensions directory?
What stops a new user from plopping the folder into the extensions
directory by accident out of habit?
On Wed, May 21, 2014 at 5:42 PM, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
On 2014-05-21, 6:02 AM, Jon Robson wrote:
I've always found it silly that skins are installed in a different way
to extensions. It seems silly to teach a user 2 ways. To be honest I
still haven't got the hang of skin installation. I usually crudely
plop a folder in the skins directory which I'm pretty sure is wrong.
Thus, I would personally make skins installable in the same way.
If there is a need to manage that process better, I would steer
someone in the direction of writing a SkinInstaller extension. Such an
extension could protect the end user from the installation process and
could also provide lots of MediaWiki coolness such as reviewing skins,
updating skins and publishing skins.
This would be my vision to steer towards any how...
The current process for installing an extension is:
1. Plop a folder in the extensions directory.
2. Put require_once( $IP/extensions/{name}/{name}.php ); where {name}
is the name of that folder you just plopped in.
The process I'm suggesting for skins is:
1. Plop a folder in the skins directory.
2. Put require_once( $IP/skins/{name}/{name}.php ); where {name} is
the name of that folder you just plopped in, which is also the name
you will use in useskin= or $wgDefaultSkin.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MW-Vagrant improvements at the Zürich Hackathon
Awesome On Wed, May 21, 2014 at 9:55 AM, Bryan Davis bd...@wikimedia.org wrote: On Fri, May 16, 2014 at 2:40 PM, Arthur Richards aricha...@wikimedia.org wrote: CentralAuth/Multiwiki: Bryan Davis, Chris Steipp, and Reedy spent a lot of time hacking on this, and we now have support for multiwiki/CentralAuth in Vagrant! There is still some cleanup work being done for the role to remove kludge/hacks/etc (see https://gerrit.wikimedia.org/r/#/c/132691/). The CentralAuth role and the associated puppet config that allows creation of multiple wikis as Apache virtual hosts on a single MediaWiki-Vagrant virtual machine have been merged! Go forth and debug/extend CentralAuth. :) I'd love to see additional roles created that use the multwiki::wiki Puppet define to add interesting things for testing/debugging like RTL wikis or other complex features such as WikiData that use a collaboration between multiple wikis in the WMF production cluster. If you're interested in working on something like this and get stuck with the Puppet code needed or find shortcomings in the setup that Chris and I developed I'd be glad to try and help work through the issues. Bryan -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID USA irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
(Firstly, apologies for breaking threading, and not quoting things as fully as I normally would. I only just subscribed to this list, so don't have previous mails in my mail client.) I'm the main author of the Erudite skin[0], which Daniel Friesen helped a good deal with when shepherding it into the gerrit git system. So consider me biased to prefer the way that skin does everything ;) I think Bartosz' proposal to clean this stuff up is good and important. In particular, making the official skins use their own directories (and not skinname.php skinname/*) is nice for several reasons, not the least being to provide a good model for others developing skins to follow. Bartosz' second proposal, $IP/skins/SkinName/ for both assets and PHP files is a good one I think. I agree with Tyler and Bartosz' points regarding the extensions/ vs. skins/ directories; namely that the skins/ directory is a sensible place for skins, and the fact that they in practise aren't fundamentally different to extensions is largely irrelevant. To Tim Starling's point about making skin installation / upgrading automatable; that shouldn't be much more challenging at all using skins/ if they're in a separate directory to extensions; it can't really be a code reuse issue, unless it's really bad code ;) To Tyler Romeo's point about how skins are needlessly complex, and a templating system would be much nicer, I don't really agree. Being regular PHP gives a lot of flexibility, and in practise the vast majority of a skin can already be just HTML with ?php tags for inserting the appropriate content. Have a skim of the Erudite code to see what I mean[1]. Granted I'm probably a bit code-blind from having spent a long time with that bit of PHP, but to me it feels really clean and straightforward. I'm sure there is some work that could be done to reduce boilerplate code a bit (as Daniel mentioned), but beyond that I think it's quite a good system. As for the upper vs lower vs camel case issues, I'd like them to magically go away, but I don't have a good suggestion for that. Well, my suggestion would be lowercase everywhere, but that conflicts with general mediawiki style. So, again, I personally am inclined to generally agree with whatever Daniel says on the issue ;) Nick 0. https://www.mediawiki.org/wiki/Skin:Erudite 1. https://git.wikimedia.org/blob/mediawiki%2Fskins%2Ferudite/fc5b86835e7b942d7d95bd61fd3927f52c84ece1/Erudite.skin.php ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Square bounding boxes + typesafe enums
I gave SplEnum a quick read as well. It seems they are solving a different use case. SplEnum appears to be optimized for the case where you have some inherently-integer constants floating around your code (due to legacy or interoperation with C or network protocols or what-have-you), and you want to give them prettier names while facilitating safe conversion between the integers and the fancy names. For example, with SplEnum I can do: new HttpStatus($status) and it will throw an exception if $status isn't a valid http status code, otherwise it will give me HttpStatus::FOUR_OH_FOUR or what have you. The proposed MW enumeration class is when you don't want to think of your enumerated types as integers at all. --scott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Square bounding boxes + typesafe enums
On Tue, May 20, 2014 at 3:32 PM, Sumana Harihareswara suma...@wikimedia.org wrote: Hey, developers. This week - tomorrow, 2100 UTC on Wednesday - we'll be talking about Andrew Green's Typesafe enums proposal https://www.mediawiki.org/wiki/Requests_for_comment/Typesafe_enums I don't use enums in other languages and I probably won't use them in PHP either. Solution in search of a problem, imho. In fact, Do nothing, there's nothing inherently wrong with class constants is the first option under the list of options being considered. My vote is for that. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Square bounding boxes + typesafe enums
On Wed, May 21, 2014 at 12:48 PM, Brion Vibber bvib...@wikimedia.orgwrote: From my read, SplEnum is a bit janky -- you still have to defibe integer constants and may have to pass them in. Also, SplEnum is not built-in. It's a PECL extension, so we'd have to require users to install it alongside MediaWiki. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There seem to be three popular ways: * $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ for ... * $IP/skins/SkinName/ for both assets and PHP files ($IP/skins/skinname/SkinName.php etc.), using require_once in ... * $IP/extensions/SkinName/ for everything, the rest as above. This makes I'd go for a mixture of option 2 and 3: $IP/skins/SkinName/SkinName.php I agree that skins and extensions should be installed in the same way as much as possible. But I do not agree that this should go so far as to install them in the same directory. They are fundamentally different things - one concerns (ideally) the functionality of the wiki, the other (ideally) its presentation. But it can both be pulled in using require_once, let's put it in the same place. does not sound right to me. Using that reasoning you could just put all of MW in one directory (or in one file, even) and be done with it. At the same time I do not agree that the skin absolutely has be called the same in all contexts so admins do not get too confused. That's what installation instructions are for. Plop it into yaddayadda. Done. Activate it using blahdiblah. Done. And, incidentally, what's wrong with useskin=MonoBook? Btw: What stops a new user from plopping the folder into the extensions directory by accident out of habit? Three answers - 1 serious, 1 half-serious, 1 not helpful at all (you can pick which is which): 1. New user, out of habit? Umm... 2. Nothing. And any decently written skin should not care. 3. Composer. :P And a decent extension/skin manager built on top of that. (But that's a completely different discussion, agreed.) Cheers, Stephan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTfQ6iAAoJENc2Q4BsPGAQzloP/jBG5u79ArOGyo/YlAHoGSPV gDqOEoDqWTNwerLkP3XSAjjhyPxUo/Bu0QZIu4bzgekpW2thQLhKSXlvMgKpJ2KG 7Ro7P0H6DC9w1mS7ryyPWqJltdji2XjEWIuopo/0EwiOSYYIVwS+Uimsfn9MJmi3 VAqtLHm7e3E/DpnqAU4hoFW3c5SQjEsMKm1Y/SN5KoVd2xIf22NZE8cmdoRD/3D8 AG2x/plyNg6i3RmB3zpBf9ZNi/Mmw43ea3vOF+TaINBvTUP+sEH7PI0iTft8DCA5 NQadeAxHE1lAvOIJuTQBv0ESdKGapk35hw3OIDGpBEa3i630paAYJc45nK1eogqk qaG/82akwVtrgHLkdKaX0r8xNAKpGNW4Q3B4xQcOxH/U9XcCQnptnbJINQrOjkZ1 8eIxM+S6wXQpCNz/nqsvG0xPnPly267I2PKSD5VE45byDDxlwb15mDZcMY/tKxc5 Q2YX1kdJ8jRi9+M8eNYTaBpHjQMqgBBc7rgfwzBxZ6Im/7wPIF7eol8s8HWBWgTM L5OlCU1H5ZQAST0BvK10FsQxEArCS3ccT66PEq1H/7HKm9P/RPpQkKd+2ZxIswxX CeOrwMiRcvzE38KBo/1szsfElbaNaRGHMYL6JyS+ee6tsfuuFgGx35V6/sRpESQb npgqA+9sF7BlD73XaU+I =+KDs -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On Wed, May 21, 2014 at 1:38 PM, Stephan Gambke s7ep...@gmail.com wrote: Using that reasoning you could just put all of MW in one directory (or in one file, even) and be done with it. That's the most sensible idea I've read all week :D -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Square bounding boxes + typesafe enums
On 05/20/2014 06:32 PM, Sumana Harihareswara wrote: Hey, developers. This week - tomorrow, 2100 UTC on Wednesday - we'll be talking about Andrew Green's Typesafe enums proposal https://www.mediawiki.org/wiki/Requests_for_comment/Typesafe_enums , and looking to finish off the next step of C. Scott Ananian's Square bounding boxes RfC. https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes We'll be in #wikimedia-office - for YOUR time, try this: http://everytimezone.com/#2014-5-21,540,6bj Meeting page: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-21 This happens in about 30 minutes. -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] That you to anonymous users
Hi David, I am delighted that you are interested in extending the Thanks feature we released last year, so it can be used to thank more users. I am no longer working on this project, but am not aware of any changes that would make it easier to thank anonymous users: IP addresses are still as unreliable now as they were a year ago. But I have Cc:d Danny Horn, the new product manager for core features like Flow and Notifications, so he can chime in from his viewpoint. Personally, I would love to see the Thanks feature be used even more than it is today, as it seems like such a civilized way to show appreciation to each other :) Cheers, Fabrice On May 20, 2014, at 7:56 AM, David Gerard dger...@gmail.com wrote: On 20 May 2014 15:35, Strainu strain...@gmail.com wrote: I've recently noticed the Thank you feature is only available for signed-in users, while anons cannot receive thank yous. The anonymous users are often the ones that would need encouraging the most, so it would make sense to me to have this feature available to them too. Are there significant technical problems against such a change? I asked for this on the editor engagement list too. Fabrice said: [1] Sadly, we couldn't make this feature available for anonymous users, as you have to be registered to receive notifications right now. This is because IP addresses cannot be trusted to deliver notifications to the users they were intended to. I don't expect we'll change that anytime soon. We should all encourage anonymous user to register if they want to enjoy the same benefits as other members. Fabrice, is this still the case? Are there ways around this? * I suppose session cookies for anons just to possibly thank them is a bit excessive. * Could limit thanks to a short time after the edit (limiting either sending or receiving). Any other ways we could implement this with minimal false-positives on thanking people? If that's considered a problem :-) - d. [1] http://lists.wikimedia.org/pipermail/ee/2013-July/000525.html ___ Fabrice Florin Product Manager Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Process for proposing Wikimedia hackathons
Hi, in Zürich I took one action to define a process to propose and select Wikimedia hackathons. The topic came when discussing how to define the location of the next European hackathon, and it was also mentioned when discussing the possibility to start organizing an annual hackathon in India. There is a draft available at https://www.mediawiki.org/wiki/Hackathons Feedback welcome. The page includes guidelines for candidates proposing a hackathon. Even if this is a draft, I think they are already useful for anybody thinking on proposing the Wikimedia Hackathon 2015 in Europe, as well as a developer event in India or elsewhere. As soon as we agree on the basics of the draft, we will advertize it further at wikimedia-l to make sure that all chapters and other WM orgs are aware of it, and hopefully budget for it as organizers and/or travel sponsors. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GeoData now uses Elasticsearch
On Wed, Apr 9, 2014 at 6:04 PM, Max Semenik maxsem.w...@gmail.com wrote: Hi, today GeoData spatial searches were switched from Solr to Elasticsearch, for now only on testwiki. We're going to test it there for a while before proceeding to production wikis. And today we rolled it out everywhere--GeoData is now 100% powered by Elasticsearch. If you spot any problems please let me or Max know. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] That you to anonymous users
Fabrice, is this still the case? Are there ways around this? * I suppose session cookies for anons just to possibly thank them is a bit excessive. It sure sounds excessive. Setting a session cookie after an edit has been made by an anon might[1] be quite cheap in reality, or at least cheap enough to justify the cost. Privacy wise it also seems ok, but I might be overlooking some things on that regard as well. --Martijn Don't we already do this upon an anon visiting an edit page? Otherwise standard talk page messages wouldn't really work for anons, as the user wouldn't get past varnish. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] That you to anonymous users
If only I was a developer of any sort ;-) On 21 May 2014 21:56, Fabrice Florin fflo...@wikimedia.org wrote: Hi David, I am delighted that you are interested in extending the Thanks feature we released last year, so it can be used to thank more users. I am no longer working on this project, but am not aware of any changes that would make it easier to thank anonymous users: IP addresses are still as unreliable now as they were a year ago. But I have Cc:d Danny Horn, the new product manager for core features like Flow and Notifications, so he can chime in from his viewpoint. Personally, I would love to see the Thanks feature be used even more than it is today, as it seems like such a civilized way to show appreciation to each other :) Cheers, Fabrice On May 20, 2014, at 7:56 AM, David Gerard dger...@gmail.com wrote: On 20 May 2014 15:35, Strainu strain...@gmail.com wrote: I've recently noticed the Thank you feature is only available for signed-in users, while anons cannot receive thank yous. The anonymous users are often the ones that would need encouraging the most, so it would make sense to me to have this feature available to them too. Are there significant technical problems against such a change? I asked for this on the editor engagement list too. Fabrice said: [1] Sadly, we couldn't make this feature available for anonymous users, as you have to be registered to receive notifications right now. This is because IP addresses cannot be trusted to deliver notifications to the users they were intended to. I don't expect we'll change that anytime soon. We should all encourage anonymous user to register if they want to enjoy the same benefits as other members. Fabrice, is this still the case? Are there ways around this? * I suppose session cookies for anons just to possibly thank them is a bit excessive. * Could limit thanks to a short time after the edit (limiting either sending or receiving). Any other ways we could implement this with minimal false-positives on thanking people? If that's considered a problem :-) - d. [1] http://lists.wikimedia.org/pipermail/ee/2013-July/000525.html ___ Fabrice Florin Product Manager Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Square bounding boxes + typesafe enums
On 05/20/2014 06:32 PM, Sumana Harihareswara wrote: Hey, developers. This week - tomorrow, 2100 UTC on Wednesday - we'll be talking about Andrew Green's Typesafe enums proposal https://www.mediawiki.org/wiki/Requests_for_comment/Typesafe_enums , and looking to finish off the next step of C. Scott Ananian's Square bounding boxes RfC. https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes Summary logs: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-21#Summary_.26_logs We agreed not to use SplEnum, as it's not available by default, and to have Andrew benchmark setup and access performance for his proposal. Regarding square bounding boxes and upright, C. Scott will check in with Raimond Spekking, the original author of upright, and will work to ensure rollout doesn't cause deployment or scaler problems. Next week we will probably be talking about Pau Giner's grid system RfC https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system and about extension management, probably on Monday the 26th and probably at a time better for Australia and Asia. Still the plan. -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] wikibugs IRC down
Looks like something happened to the IRC bot. Havent seen a bug report in several hours ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] That you to anonymous users
On 2014-05-21, 3:29 PM, Brian Wolff wrote: Fabrice, is this still the case? Are there ways around this? * I suppose session cookies for anons just to possibly thank them is a bit excessive. It sure sounds excessive. Setting a session cookie after an edit has been made by an anon might[1] be quite cheap in reality, or at least cheap enough to justify the cost. Privacy wise it also seems ok, but I might be overlooking some things on that regard as well. --Martijn Don't we already do this upon an anon visiting an edit page? Otherwise standard talk page messages wouldn't really work for anons, as the user wouldn't get past varnish. --bawolff To be clear, we set a cookie on submit of the edit page, whether it results in an edit or not, but not on visit. But that is essentially what Martijn described. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 21/05/14 20:38, Stephan Gambke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There seem to be three popular ways: * $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ for ... * $IP/skins/SkinName/ for both assets and PHP files ($IP/skins/skinname/SkinName.php etc.), using require_once in ... * $IP/extensions/SkinName/ for everything, the rest as above. This makes I'd go for a mixture of option 2 and 3: $IP/skins/SkinName/SkinName.php I agree that skins and extensions should be installed in the same way as much as possible. But I do not agree that this should go so far as to install them in the same directory. They are fundamentally different things - one concerns (ideally) the functionality of the wiki, the other (ideally) its presentation. But it can both be pulled in using require_once, let's put it in the same place. does not sound right to me. Using that reasoning you could just put all of MW in one directory (or in one file, even) and be done with it. At the same time I do not agree that the skin absolutely has be called the same in all contexts so admins do not get too confused. That's what installation instructions are for. Plop it into yaddayadda. Done. Activate it using blahdiblah. Done. And, incidentally, what's wrong with useskin=MonoBook? Btw: What stops a new user from plopping the folder into the extensions directory by accident out of habit? Three answers - 1 serious, 1 half-serious, 1 not helpful at all (you can pick which is which): 1. New user, out of habit? Umm... 2. Nothing. And any decently written skin should not care. 3. Composer. :P And a decent extension/skin manager built on top of that. (But that's a completely different discussion, agreed.) Cheers, Stephan This. All of this. And, incidentally, what's wrong with useskin=MonoBook? I think the only thing really wrong with it is that support for it hasn't been implemented; the expected use on the user end is indeed the that, the normal capitalisation, and I've had a few regular users on my talkpage confused about it in the past, especially since everything else in the url string tends to be case-insensitive or may even automatically convert lowercase to camelcase in other instances. If the other internals all expect lowercase, internal functions should be more than capable of automatically converting the name for their use. This, however, has also not been implemented in core; as is most skin extensions just have an extra line in the definition file to convert it for those. Also some more on why putting skins in the extensions directory is a bad idea: From a sysadmin standpoint, the extensions repository/directory is basically a horrible pit of extreme darkness full of many things that that you basically have no idea what they are because their names are completely unhelpful. This is kind of not good, and we do not want to make it worse, because unlike extension names, which sometimes are helpful, skin names basically NEVER give the slightest indication what they are. Skin names are generally completely random things that sounded good, or seemed like a good idea at the time, or were made up as drunken placeholders that nobody got around to replacing. When they even resemble the appearance of the skin itself, it is often a complete coincidence (with a some exceptions - for instance I named a skin 'greystuff' once and indeed it is basically a bunch of grey stuff, but that was only because I did remember replace the original drunken placeholder). Whereas if we put them somewhere else, such as in 'skins', a place where people would probably expect to find skins, it is immediately clear what they are, both in the filesystem and in the settings files. This is very nice, and leads to fewer incidents of fellow sysadmins killing themselves with shovels. -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikibugs IRC down
I've nudged one of the developers on IRC (often the best bet, for an IRC bot bug ;) and he's looking into it. See https://www.mediawiki.org/wiki/Wikibugs for blame^Howners and future reference. On Wed, May 21, 2014 at 4:17 PM, John phoenixoverr...@gmail.com wrote: Looks like something happened to the IRC bot. Havent seen a bug report in several hours ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] tech sessions/hackathon at Wiki Conference USA, May 30-June 1, NYC
http://wikiconferenceusa.org Organizers have posted the schedule for Wiki Conference USA (New York City, 30 May-1 June). I'm giving the opening keynote address. Tech-related topics will include: Wikidata, video content, our API, the RAMP editor, Extension:Memento, graphics, Forward to Libraries, cybersecurity, handling multiple languages on Commons, the Internet Archive's interest in past revisions, and lessons for Wikimedia from OPW. And Sunday June 1st is an all-day hackathon. You can sign up for the waitlist since registration is full; we may see some more slots as people's plans firm up. http://wikiconferenceusa.org/wiki/FAQ#Accommodations and https://en.wikivoyage.org/wiki/New_york_city#Sleep might help you plan to come. -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Square bounding boxes + typesafe enums
On 05/21/2014 02:22 PM, C. Scott Ananian wrote: I gave SplEnum a quick read as well. It seems they are solving a different use case. SplEnum appears to be optimized for the case where you have some inherently-integer constants floating around your code (due to legacy or interoperation with C or network protocols or what-have-you), Which we do (with an emphasis on the 'legacy' one), so maybe we should have both, or include support for this use case in our implementation. I haven't looked at it in detail, just something to consider. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MW-Vagrant improvements at the Zürich Hackathon
On 05/21/2014 12:55 PM, Bryan Davis wrote: The CentralAuth role and the associated puppet config that allows creation of multiple wikis as Apache virtual hosts on a single MediaWiki-Vagrant virtual machine have been merged! Go forth and debug/extend CentralAuth. :) This is really great. GettingStarted can now use this, among many other use cases. Matt ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Hackathon in New York (with prizes!) on June 21
Hi. A coworker of mine passed this along today. I thought readers of this list might be interested. https://jibe-hackathon.eventbrite.com/ --- Saturday, June 21, 2014 from 10:00 AM to 10:00 PM (EDT) New York, NY Hack the Web! Join us for the Jibe Hackathon. Here at Jibe, we make the Web a better place. We build APIs where there are none, we present insights from opaque data sources, and we polish and simplify the user experience of decades-old technology. We want everyone to do the same, so we’re hosting a hackathon for making the web more useful. Hack the Web, build something awesome, and potentially win a prize! Prizes are as follows: * First place: $7,500 * Second place: $3,750 * Third place: $2,250 * Best HR-related hack: $1,500 Coding will start at 11AM and wrap up in time for demos at 8PM. Prizes will be announced around 9PM. There will be Jibe developers on hand to provide guidance and present on useful technologies and techniques like scraping, data visualization, and browser automation. Food and beverages will be provided. Full official rules can be found at http://jibe.com/hackathon-rules. Please feel free to reach out to hackat...@jibe.com with any questions! --- Unfortunately I know almost nothing about the sponsoring company, but it seems that while Jibe is primarily focused on human resources-related software, this hackathon is simply focused on creating a better Web. I imagine there are a few Wikimedia-related projects with the same goal. :-) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
