[Wikitech-l] Performance issue with regard to JSON-based localisation format
Hi *, I recently investigated a performance issue with one of Wikibase's test cases. The test in question performed a formatting task for all known languages. While the first assertions ran as fast as expected, they rapidly got slower until finally taking seconds per assertion. I figured this was an actual performance bug (although hardly triggered in production) and started profiling. My findings, in short: * The shims for $wgExtensionMessagesFiles as generated by maintenance/generateJsonI18n.php register a handler for the hook LocalisationCacheRecache when included * For every new language loaded, all $wgExtensionMessagesFiles are included by LocalisationCache::recache * Afterwards, LocalisationCache::recache runs the hook LocalisationCacheRecache This leads to the obvious issue that there is a growing number of registered handlers, which slows down the hook, which slows down the test. From my point of view, this is a bug. The old approach and the current implementation of LocalisationCache assume that $wgExtensionMessagesFiles can be included multiple times. However, the $wgExtensionMessagesFiles shims as generated by maintenance/generateJsonI18n.php don't handle this case gracefully. I can imagine two solutions: * Fixing the caller (LocalisationCache) by making sure it does not include a single file twice (a simple, finite cache is already implemented in LocalisationCacheBulkLoad). * Fixing the callees ($wgExtensionMessagesFiles) by making sure they register the handler only once. This would need a change to all extensions which already switched to JSON-based localisation. What do you think? Adrian Lang ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] mGerrit - Gerrit for Android
As we all know, Gerrit doesn't have the best interface, but even more so, it's not very mobile friendly. There is however mGerrit [1] for Android which does a nice job. Also, we're not in the list of default supported Gerrit instannces (yes, I know WikiMedia is in CamelCase, this is already reported and fixed upstream). If you've any issues with the software emailing the developer directly is quite good at yielding responses. Sam [1] https://play.google.com/store/apps/details?id=com.jbirdvegas.mgerrit ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki Support for PhpStorm
There's been discussions before about being able to share code style settings between MediaWiki users for PhpStorm. To this end, I've started a PhpStorm plugin [1] that adds this functionality, allowing preferences to be set from a MediaWiki predefined style. Thanks to Siebrand and Physikerwelt for their example configurations. There is also functionality to search MediaWiki.org for selected text using the context menu. It can be installed using the inbuilt plugin manager in PhpStorm. More functionality to come, somewhat emulating the Wordpress plugin [2]. I imagine the Hook support would be quite useful for many people too. Code is currently on github [3], maybe should be moved to gerrit sometime in the future. Pull requests and issues happily accepted. Sam [1] http://plugins.jetbrains.com/plugin/7439 [2] http://blog.jetbrains.com/phpstorm/2014/03/wordpress-support-in-phpstorm-8-e ap/ [3] https://github.com/reedy/phpstorm-plugin-mediawiki ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Performance issue with regard to JSON-based localisation format
I think technically easiest solution is to modify the i18n.php files:
-$GLOBALS['wgHooks']['LocalisationCacheRecache'][] = function (
$cache, $code, $cachedData ) {
+$GLOBALS['wgHooks']['LocalisationCacheRecache'][__FILE__] = function
( $cache, $code, $cachedData ) {
This makes it so that if the file is included again, it will just
override the previous callback set in that file, instead of adding a
new one.
The downside of this approach is that someone needs to change this in
all the hundreds of extensions.
Modifying LC itself does not help users like you who are running older
versions of MediaWiki [1].
[1] The shims are only used in = 1.22.
-Niklas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Performance issue with regard to JSON-based localisation format
Hi, On Mon, Apr 14, 2014 at 2:33 PM, Niklas Laxström niklas.laxst...@gmail.com wrote: Modifying LC itself does not help users like you who are running older versions of MediaWiki [1]. you are right, although I'm not using an older version of MediaWiki, I'm on 77bc489c2731827b1c61a6509177eed23193d694 from 2014-04-11. Regards, Adrian ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Performance issue with regard to JSON-based localisation format
PleaseStand has already submitted a patch to mitigate this issue in
https://gerrit.wikimedia.org/r/#/c/125706/
Please review.
On Mon, Apr 14, 2014 at 2:33 PM, Niklas Laxström
niklas.laxst...@gmail.comwrote:
I think technically easiest solution is to modify the i18n.php files:
-$GLOBALS['wgHooks']['LocalisationCacheRecache'][] = function (
$cache, $code, $cachedData ) {
+$GLOBALS['wgHooks']['LocalisationCacheRecache'][__FILE__] = function
( $cache, $code, $cachedData ) {
This makes it so that if the file is included again, it will just
override the previous callback set in that file, instead of adding a
new one.
The downside of this approach is that someone needs to change this in
all the hundreds of extensions.
Modifying LC itself does not help users like you who are running older
versions of MediaWiki [1].
[1] The shims are only used in = 1.22.
-Niklas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Siebrand Mazeland
Kitano ICT
M: +31 6 50 69 1239
Skype: siebrand
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Performance issue with regard to JSON-based localisation format
2014-04-14 15:35 GMT+03:00 Adrian Lang adrian.l...@wikimedia.de: you are right, although I'm not using an older version of MediaWiki, I'm on 77bc489c2731827b1c61a6509177eed23193d694 from 2014-04-11. Is something loading the i18n files manually then? Or is there a missing $wgMessagesDirs definition matching $wgExtensionMessagesFiles? LC was made so that is skips loading PHP shims when JSON alternative is present. -Niklas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Performance issue with regard to JSON-based localisation format
The files are loaded, only the merging is skipped if JSON-based localisation data is present. On Mon, Apr 14, 2014 at 3:01 PM, Niklas Laxström niklas.laxst...@gmail.com wrote: 2014-04-14 15:35 GMT+03:00 Adrian Lang adrian.l...@wikimedia.de: you are right, although I'm not using an older version of MediaWiki, I'm on 77bc489c2731827b1c61a6509177eed23193d694 from 2014-04-11. Is something loading the i18n files manually then? Or is there a missing $wgMessagesDirs definition matching $wgExtensionMessagesFiles? LC was made so that is skips loading PHP shims when JSON alternative is present. -Niklas ___ 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] Keeping Code-Review votes across trivial changes of patch sets?
On Fri, Apr 11, 2014 at 4:08 PM, Daniel Friesen dan...@nadir-seen-fire.com wrote: I never liked this, over and over I point out a fatal issue with a commit sometimes fundamental to the idea itself and impossible to fix, so I -1 it, then when a new patchset comes out, completely ignores the concerns I've pointed out, my -1 with the idea suddenly disappears as if the changeset was supposed to fix it. That's what -2 is for. I think this is a social issue: we need to stop thinking of -2'ing a patch as a grave statement of disapproval. It should have a meaning matching its function: that is, a sticky -1 that isn't cleared automatically by a new revision. --scott -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Larger thumbnails for MediaWiki / Wikimedia wikis?
Note that https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes may be related, since we're talking about what size default thumbnails appear at. Also https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes has existed for a while, it would be nice to get some traction on that. --scott On Thu, Apr 10, 2014 at 9:31 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Apr 9, 2014 at 3:50 PM, Bartosz Dziewoński matma@gmail.comwrote: On Wed, 09 Apr 2014 21:45:05 +0200, James Forrester jforres...@wikimedia.org wrote: Proposal: - Make the default a nice proper size for the modern Web; I suggest 360px but could be argued up. - Remove all the other sizes from wgThumbLimits - Remove the user preferences for thumbnail size Despite the increase in screen sizes some people do still use 1024x768 and the like, so this seems a little radical to me, but it might be a reasonable option to consider if that's the only way. I hope that it isn't :) This. I for one keep my browser window sized at 1024x768 most of the time, which gives me plenty of extra screen room for other windows. I only maximize when dealing with sites that are designed for larger sizes only and degrade poorly, or occasionally for video calls if I feel like seeing people better. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Keeping Code-Review votes across trivial changes of patch sets?
On Mon, 14 Apr 2014 18:02:43 +0200, C. Scott Ananian canan...@wikimedia.org wrote: I think this is a social issue: we need to stop thinking of -2'ing a patch as a grave statement of disapproval. Nope (or not only), most people don't even have the ability to give out a -2 (it currently comes in a package with +2 rights). -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Keeping Code-Review votes across trivial changes of patch sets?
On Mon, Apr 14, 2014 at 9:07 AM, Bartosz Dziewoński matma@gmail.comwrote: On Mon, 14 Apr 2014 18:02:43 +0200, C. Scott Ananian canan...@wikimedia.org wrote: I think this is a social issue: we need to stop thinking of -2'ing a patch as a grave statement of disapproval. Nope (or not only), most people don't even have the ability to give out a -2 (it currently comes in a package with +2 rights). That's easily adjustable if people so desire. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Abandoning -1 code reviews automatically?
On Sun, Apr 13, 2014 at 1:37 PM, Marcin Cieslak sa...@saper.info wrote: 2) https://gerrit.wikimedia.org/r/#/c/11562/ My favourite -1 here is needs rebase. Well, obviously trivial rebases should be done automatically by the system (which OpenStack's system does), and changes that need a rebase due to conflicts should be fixed. Reviewer time is generally in short supply, so it makes sense to have the committer do any conflict resolution. Regarding Openstack policies: I'd say we should not follow them. I used to be #2 git-review contributor according to launchpad until recently. I gave up mainly because of my inability to propose some larger change to this relatively simple script. For a nice example of this, please see https://review.openstack.org/#/c/5720/ I have given up to contribute to this project some time after this, I have no time to play politics to submit a set of tiny changes and play the rebase game depending on the random order they might would have got reviewed. This seems like an odd change to use as an example. There seems to be no politics in play there. All of the reviews were encouraging, but it looked like there was a release happening during your reviews and it caused a number of merge conflicts. The change was automatically abandoned, but you could have restored it and pinged someone on the infra team. The next time I find time to improve Johnny the causual developer experience with gerrit I will just rewrite git-review from scratch. The amount of the red tape openstack-infra has built around their projects is simply not justifiable for such a simple utility like git-review. Time will tell if gerrit-based projects generally fare better than others. Maybe, until you start looking at their statistics: http://stackalytics.com/?release=icehousemetric=marksproject_type=openstackmodule=company=user_id= If you notice, this release cycle they had 1,200 reviewers. One organization had 20k reviews over the cycle, and the top 5 each had over 10k reviews. Their process scales way better than Wikimedia's, but that's also due to the way projects are split up and organized as well. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed body font stack for Latin
Erwin, I echo Erik's statement. Thanks for moving this along. In response to your suggestion that we need a font stack specific to the language I have compiled this patch [1] I envision this change should enable various other possibilities in styling our content better for other languages, starting initially with font families. As stated, I think this is a really good opportunity to talk with local communities and do an audit of the best fonts per language. The stack you suggested makes total sense to me and I've included it in that patch. We can debate it some more however and if necessary I can remove the change from the patchset - I just wanted to explain how it might work via code! Jon [1] https://gerrit.wikimedia.org/r/125760 On Sun, Apr 13, 2014 at 7:12 AM, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Apr 12, 2014 8:58 AM, Isarra Yos zhoris...@gmail.com wrote: On 11/04/14 19:30, Erwin Dokter wrote: First, I like to aplologize to anyone who I may have come over too passionate at some times. Frustration is known to get the better of me, even though I should control that. (I also quit smoking.) Not sure where a new font stack should be discussed, so I'm just throwing it in here. Also, note I propose this for Latin wikis only. Asuming we want the 'Helvetca' look for the body font: font-family: Nimbus Sans L, Helvetica Neue, Arial, Helvetica, sans-serif; Breakdown: Nimbus Sans L - for Linux. This is the defacto helv font on Linux systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L'). Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on Windows (or Linux for that matter), as those copies for Windows have differen font family names (like 'Helvetica Neue LT Com 55 Roman'). Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines. Helvetica - Generic Helvetica fallback for any system not matching any of the previous fonts. But same as the original font stack, the question remains - for everything but mac, what is this supposed to solve? What is the purpose of even having helvetica and arial there when they're already the defaults on their respective systems, and when on other systems they would likely be far worse than the defaults? And for linux, either they'll already be using nimbus sans (if they even have it), or it's not going to be what their renderers are optimised for. https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test tells me Linux now often gets DejaVu as default sans, and I understand we would rather force Nimbus if it is available as it is deemed better. Also, free font up front. --Martijn Every distro is different, with its own defaults and optimisations, and they are optimised based on their defaults. We should not be overriding those without very good reason. Only one default has been explained to have legitimate problems (I believe it was Daniel Friesen who went into this, so thank you) - helvetica on mac. Given that the fix appears to be a font that will only be present on macs in the first place, would it not be a better approach to simply address this and leave the others be? Thus: /* Override Helvetica default on macs to improve font legibility */ font-family: Helvetica Neue, sans-serif; This way it is clear what's going on in the source, ideologies are left alone, and everyone gets the best possible experience for their platform. I'd like to test this locally on the English Wikipedia, and I am quit confident this makes everyone happy because 1) every OS should end up using a native font, and 2) it promotes a free font at the beginning of the stack (not a high priority in my book though). Next up I may think about the headers font stack; While Georgia is a good serif; I detest its use of text figures. Problem with any serifs is that when using them with sans-serifs, the different fonts need to match each other with similar ratios and weights; sans-serif, serif, or otherwise, you can't just shove any two fonts together and call it a day. Linux libertine, for instance, is very pretty, but its thickness and dimensions simply do not match the body in helvetica et al; it's much more similar to a bold verdana-style font. Georgia may have similar problems (I don't have it so I couldn't say at present), so that might be something to look into there as well. -I ___ 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
[Wikitech-l] Adding fields to Signup form
Can anyone assist me in adding a dropdown list to the signup form using UserCreateForm hook and UsercreateTemplate::addInputItem class. I have figured out how to add a text field, but I'm not sure how to accomplish a dropdown menu. UsercreateTemplate::addInputItem ($name, $value, $type, $msg, $helptext); https://doc.wikimedia.org/mediawiki-core/master/php/html/classUsercreateTemplate.html Thanks, Dgennaro ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Keeping Code-Review votes across trivial changes of patch sets?
Le 11/04/2014 15:57, Christian Aistleitner a écrit : TL;DR: Gerrit would allow to keep Code-Review votes across * rebases and * commit message modifications of patch sets. Thereby dropping need to re-review “trivial” changes on patch sets. Shall we turn that feature on? snip Thank you Christian to raise this publicly :-] Gerrit knows about two different trivial changes: - trivial rebase: the new patchset is the same diff but the parent has changed. This is often fine but the new patch my not be working anymore. Though if that happens tests will catch it. - no code change: only the commit summary has changed. Ie the proposed code is exactly the same and should have the same behavior. Details: https://gerrit.wikimedia.org/r/Documentation/config-labels.html#label_copyAllScoresOnTrivialRebase I am fine reapplying scores for both types. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki Core Team plans for the coming quarter
Hi everyone, I wanted to give everyone a heads up on our plans for the next quarter. The long version is here: https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_review,_April_2014 The short version: we're planning to primarily focus on: * HHVM deployment. No promises that we'll get it done this quarter, but we'll try * Search. We should have everything moved over to CirrusSearch before the quarter is over, and we hope to make some user interface improvements in this area as well * SUL finalization - Also in the no promises category, but we plan to do work on this in the coming quarter * Scap improvements - a fair chunk of this work will be HHVM related, but there will probably still be other work that Bryan continues to do on this. * SecurePoll improvements - there's more work to do to make this more easily configurable, and for automating the voter verification step * Architecture/RFC review - continued work on review activities, as well as followup from the Architecture Summit on things like the Configuration Database conversations. The above is in addition to the work the ongoing work the team does on code and architecture review, consultations on security and performance, deployment mechanics as well as the first-responder role on deployment-related troubles. In addition to listing the projects we're going to tackle, we elaborated on a number that received serious consideration. If any of those projects that received consideration seem urgent, it's worth commenting. Even though it's unlikely we'll immediately change course, we'll likely revisit the list next quarter, so now may be the best time to start lining things up. Feel free to comment either on the talk page for the page above, or on this mailing list. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Keeping Code-Review votes across trivial changes of patch sets?
On 14 April 2014 12:06, Antoine Musso hashar+...@free.fr wrote: Le 11/04/2014 15:57, Christian Aistleitner a écrit : TL;DR: Gerrit would allow to keep Code-Review votes across * rebases and * commit message modifications of patch sets. Thereby dropping need to re-review “trivial” changes on patch sets. Shall we turn that feature on? snip Thank you Christian to raise this publicly :-] Gerrit knows about two different trivial changes: - trivial rebase: the new patchset is the same diff but the parent has changed. This is often fine but the new patch my not be working anymore. Though if that happens tests will catch it. - no code change: only the commit summary has changed. Ie the proposed code is exactly the same and should have the same behavior. Details: https://gerrit.wikimedia.org/r/Documentation/config-labels.html#label_copyAllScoresOnTrivialRebase I am fine reapplying scores for both types. It looks to me like we have rough consensus for doing this. Make it so? J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] REST and SOA within MediaWiki - is my understanding right?
On 04/11/2014 12:06 PM, Sumana Harihareswara wrote: So, just to clarify, this is NOT a discussion of overhauling the outward-facing MediaWiki web API -- that's taking place in https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap . The discussion is not about replacing the existing PHP API. We do however plan to complement it with an outward-facing REST content API as sketched in https://www.mediawiki.org/wiki/Requests_for_comment/Content_API. So the future might look like: the heart of MediaWiki core is PHP code that talks to the database No, ideally the only code that directly talks to the database would live in a storage service, which exposes a REST API. REST is very much about the definition of narrow interfaces, idempotence and statelessness. Its division of vocabulary into URL-addressed resources and orthogonal verbs also avoids the need to perform data access through specialized RPC-style objects [1]. It enforces the use of simple value objects, which in turn helps to keep interfaces narrow. Those values can -- but don't need to be -- embellished with wrapper objects or service classes for the consuming code's convenience. Gabriel [1]: https://www.mediawiki.org/wiki/Requests_for_comment/PHP_Virtual_REST_Service ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Documenting MediaWiki-Vagrant roles
Please help fill in https://www.mediawiki.org/wiki/MediaWiki-Vagrant/Roles:) It's hard to know what a role does precisely without more docs than are provided via the 'vagrant list-roles' command. Maybe we could add a description to the list there? First step would be getting content I guess. -- Steven Walling, Product Manager https://wikimediafoundation.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed body font stack for Latin
On 15-04-2014 00:55, Isarra Yos wrote: Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered... The purpose of a font stack is to let the browser use the website's font preference. So but Arial is already the default on Windows is not a valid retort; we _want_ the browser to use Arial, even is it is _not_ the default. Nimbus fonts come from URW++, a respected foundry, and their font are quite well engineered. They released some of their fonts under a free licence for the GhostScript project, but I do not know if the fonts are still maintained (but I suspect so, as GhostScript has active development). It all boils down to preference. Of cource people are used to how things look, but change is not always necessarily a bad thing. Regards, -- Erwin Dokter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RfC on Product Management Tools and Development Toolchain
Hi, as previously announced [1], we've been facilitating a collective review of Wikimedia's current product management tools and development toolchain. The most popular idea at the moment is to consolidate Wikimedia's product management and infrastructure tools (such as Bugzilla, Gerrit, RT, Mingle, Trello) into all-in-one Phabricator. We have therefore put together a Request for comment to bring this up for wider discussion. This discussion affects anyone who deals with bug reports, feature requests and code changes in Wikimedia, so it's critical that you test Phabricator for your own use and make your voice heard in the RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator We're compiling a list of Frequently asked questions at https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/FAQ ; You're welcome to add more and help answer them :) We'll host a few IRC discussions while the RFC is running to help answer questions, etc. Our tentative times and dates are at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Phabricator#IRC_discussions Thank you for your input! Guillaume and Andre [1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/074896.html -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Documenting MediaWiki-Vagrant roles
On Mon, Apr 14, 2014 at 4:35 PM, Steven Walling swall...@wikimedia.org wrote: Please help fill in https://www.mediawiki.org/wiki/MediaWiki-Vagrant/Roles:) It's hard to know what a role does precisely without more docs than are provided via the 'vagrant list-roles' command. Maybe we could add a description to the list there? First step would be getting content I guess. I took a shot at creating jenkins configuration [0] that would build and publish documentation based on puppet manifests themselves. This seems like a better long term solution to the problem. I'm all for documenting things on wiki but in my experience the closer the documentation is to the implementation the more likely it will be updated when the implementation changes. [0]: https://gerrit.wikimedia.org/r/#/c/125919/ -- 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
[Wikitech-l] TAssembly -- template intermediate language
tldr; Gabriel Wicke and I completed the first iteration last week of our intermediate templating language. The runtime is available in both JavaScript [1] *and* PHP [2]. We're still working on optimizing the PHP version, but the JS version is already the fastest of anything we've bench marked [3][4]. If you don't know what I'm talking about... :) For a while the foundation has been debating which templating language we should standardize on [5]. The basic requirements are that it needs to be able to render content in both JS and PHP, it needs to be fast, it needs to be small, and it needs to be secure. After considering all the existing solutions we determined that no solution fulfills all the desired requirements. Popular libraries like handlebars or hogan as used by Flow and Mobile are missing principled escaping, which leaves escaping of user-provided data to the template writer. XSS vulnerabilities need to be avoided with discipline and manual security review. We decided to see if we could make something with automatic escaping, that is more easily coupled into the MediaWiki enviornment, and address future uses in VisualEditor and reactive pages. Our solution comes in two parts; 1) a compiler into an intermediate language, and 2) an runtime to turn the intermediate language into HTML. This email is about the second part, TAssembly (template assembly language), which is a generic intermediate runtime which processes a JSON structure that can be quickly reassembled into HTML using only string replacement. Contextual information is placed into the structure at compile time to ensure proper escaping regardless of the source of the data. Other static details compiled into TAssembly, such as information about i18n strings and partial templates, can be extracted in order to help delivery systems like ResourceLoader more efficiently push content. The TAssembly runtimes are available at [1] and [2]. The javascript implementation of a KnockoutJS to TAssembly compiler is available at [6]. Although other compilers could be written, see the discussion about the benefits of KnockoutJS (syntax and optional runtime) and our rationale for using DOM based templating compiled to a string based intermediate at [7]. Our next steps will be: - to continue to iterate on improving performance - integrate with ResourceLoader for template blob delivery - write the Knockoff client library for mediawiki integration (i18n availability mostly) - port the compiler to PHP for better integration or provide some sort of service based compilation - support blessing of objects in the data model [1] https://github.com/gwicke/tassembly [2] https://github.com/mattofak/knockoff [3] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance [4] test framework: https://github.com/gwicke/TemplatePerf [5] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library [6] https://github.com/gwicke/tassembly [7] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly ~Matt Walker Wikimedia Foundation Fundraising Technology Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed body font stack for Latin
On 14/04/14 23:49, Erwin Dokter wrote: On 15-04-2014 00:55, Isarra Yos wrote: Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered... The purpose of a font stack is to let the browser use the website's font preference. So but Arial is already the default on Windows is not a valid retort; we _want_ the browser to use Arial, even is it is _not_ the default. A website can prefer what it wants; that doesn't make it a good practice. I keep asking WHY 'we' prefer this particular font because there generally should be a good reason when going out of our way to avoid responsive design; doing what works best for the platform is good practice. Hence why we have an entirely separate layout for mobile, for instance, and specific apps from some of them. Different desktop platforms, too, are different. Similarly, when people override their platform's defaults, generally they have a good reason to do so. Considering this, we should have an even better reason if we're going to go overriding those overrides - especially if this is simply back to the defaults. Nimbus fonts come from URW++, a respected foundry, and their font are quite well engineered. They released some of their fonts under a free licence for the GhostScript project, but I do not know if the fonts are still maintained (but I suspect so, as GhostScript has active development). It all boils down to preference. Of cource people are used to how things look, but change is not always necessarily a bad thing. Don't dismiss preference so blithely. The psychological processes that go into determining preferences are huge; when our brains are rearranging themselves based on what we're used to, dismissing that as 'just' preferring what we're used to makes no sense. The details of particular character forms are relatively minor, of course, but like how a language a person grew up on will shape all of their future interactions with all languages, even in the short term we do come to expect letters to be a certain way. So yes, different people prefer different things. This is good. It means we're still human. -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed body font stack for Latin
On Mon, Apr 14, 2014 at 3:55 PM, Isarra Yos zhoris...@gmail.com wrote: Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered... Design involves making choices on the behalf of users. What color should these buttons be? Where should this text go? We can't design for every person's individual taste. We have to design for what we think will do the most functional good for the most people. This is why the vast majority of sites a user will visit on a regular basis do not simply leave typography up to the browser defaults. Even MediaWiki, by choosing sans-serif for many years, forced users who might want everything to be serif to not get that. To be honest Isarra, the number of emails and on-wiki comments you have written with this exact same question is kind of mindblowing. You ask it every time the subject comes up, regardless of which particular font stack is under discussion or who is talking about it. No amount of detailed explanation ever seems enough for you. On Wikitech-l, Design-l, and in the extensive documentation on mediawiki.org, people have laid out highly objective rationales for why each font and the associated type sizing, spacing, leading, and more were selected to be harmonious with each other. If your objection is not to the particular choices made, but to the fact that we're making specific design choices at all, I don't really think there's much point in talking about it more. Steven ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed body font stack for Latin
On 15/04/14 01:54, Steven Walling wrote: On Mon, Apr 14, 2014 at 3:55 PM, Isarra Yos zhoris...@gmail.com wrote: Deemed better? Better how? But that's what I'm saying - if the configuration is optimised for dejavu sans, nimbus won't be better at all even if it is a better-engineered font (doubtful, though, it being an arial clone from what I understand). Letters will be too close together, sizes and hinting will be off, and that's not even going into the whole rabbit hole of messing with what people are used to, which seems to be the single biggest determining factor as to what they find easy to read once the basics are covered... Design involves making choices on the behalf of users. What color should these buttons be? Where should this text go? We can't design for every person's individual taste. We have to design for what we think will do the most functional good for the most people. This is why the vast majority of sites a user will visit on a regular basis do not simply leave typography up to the browser defaults. Even MediaWiki, by choosing sans-serif for many years, forced users who might want everything to be serif to not get that. Just because something is common doesn't mean it's a good idea. It may well be. But it may also just be something someone did that everyone else decided to copy, rather like big hair and leg warmers. Don't get me wrong, big hair can be awesome, but the maintenance, man, that's just killer. Looks ain't everything, and at some point you wind up just wanting your hair back. To be honest Isarra, the number of emails and on-wiki comments you have written with this exact same question is kind of mindblowing. You ask it every time the subject comes up, regardless of which particular font stack is under discussion or who is talking about it. No amount of detailed explanation ever seems enough for you. On Wikitech-l, Design-l, and in the extensive documentation on mediawiki.org, people have laid out highly objective rationales for why each font and the associated type sizing, spacing, leading, and more were selected to be harmonious with each other. If your objection is not to the particular choices made, but to the fact that we're making specific design choices at all, I don't really think there's much point in talking about it more. Steven So what is the explanation, then? What was so wrong with the defaults? Do you have any links? -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
