[Wikitech-l] Check translations for a text in all languages
Hi all, When some text gets translated to different languages, the result can be very different in length depending on the languages involved. This has implications to both development and design, and sometimes we want to quickly check how long a specific translation can become. Since I was asked about this recently, I though it would be interesting to share two simple methods I use: The first one is to check all the translations for a given message at translatewiki.net (where MediaWiki gets translated): 1. Go to translatewiki.net 2. Search for an expression such as reply to, and you'll get a list of all messages that contain those terms across all the projects that get translated at translatewiki (you can filter to a specific project if you want to check a specific message in Mediawiki). 3. Click on edit translation. By clicking on the translation ID you can access the All translations option (as shown here http://i.imgur.com/GXNVAJv.png). That will provide access to the list of all available translations https://translatewiki.net/w/i.php?title=Special:Translationsmessage=Nocc%3AHtml+reply+to%2Fen for a given message. 4. Take a look at the list and check the different lengths for the translations (回复, Reply to, Antwoorden naar, ಉಲ್ಲದಕ್ಕೂ ಉತ್ತರಿಸು, இந்த முகவரிக்கு பதில் அளி...). Alternatively, for terms that exist on Wikipedia, Wikidata can be also used for that purpose: 1. Go to a Wikipedia article for the term you are interested in (e.g., Question) 2. At the end of the language list on the sidebar, click on edit links. That will gave you access to a list with the titles of the equivalent articles http://www.wikidata.org/wiki/Q189756#sitelinks-wikipedia in different languages. 3. Take a look a the the length of the terms in the list. None of the methods above are bulletproof since those depend on the availability of the content you are looking for (or something similar), but can be useful in different situations. Pau -- Pau Giner Interaction Designer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help in modifying Template:Extension to support user ratings
Isarra, I like the idea of endorsements. Of course the best endorsement to an extension is to have it installed and actively used in a wiki, and the more popular the wiki is, the bigger that endorsement can be considered. Wikiapiary has the building blocks for this in place, since they also track wikis (with various stats) that users can claim. And then you could also have the endorsement of pure users just giving a thumbs up. I wonder whether counter-endorsements aka thumbs down could help here as well. And thjis would ring us closer to ratings, but I get your point. On Thursday, August 21, 2014, James Forrester jforres...@wikimedia.org wrote: Lots of possibilities! Well, yes. I wonder whether Mark Markus or someone else would like to pick a first one and push it until deploying it. (BTW, some basic structured data about each extension would be great to expose for users for this purpose; maybe MediaWiki.org could be a potential future Wikibase target?) I asked/suggested this ( https://lists.wikimedia.org/pipermail/wikidata-l/2014-March/003588.html ) but the idea didn't fly. -- 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
[Wikitech-l] Template RFC
Kaldari, RobLa, Trevor and I met yesterday to discuss the template RFC [1]. Sadly Gabriel was not present. Kaldari and I are very concerned that we are blocking standardisation of a generic template library on the completion of Knockoff. Trevor, Kaldari and I identified that two things need to happen for the templating solution that currently lives in Mantle [2] to core: 1) We need some JavaScript API for using templates (in current form all we have is a standard way to ship templates from the server to the frontend). Trevor is working on a template widget for oojs which will make this possible 2) We need a standard template language 3) Better namespacing for templates - we identified that we will need to find better ways of uniquely identifying templates [3]. We questioned whether point 2 should be blocking, as we recognised that even if we decide to standardise on Knockoff in future, it should be trivial to write a script that converts Hogan/Handlebars template language to Knockoff. The Mantle ResourceLoader module in current form is template agnostic and currently works with both Hogan and Handlebars, so in theory should make it easy to transition from one template language to another. On this basis, I think the next step would be for the oojs development team to get a template widget up that can be used by Mantle. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library [2] https://www.mediawiki.org/wiki/Extension:Mantle [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=69916 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] OOjs, MobileFrontend and Flow
Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside the mobile and Flow projects. The following 3 patches kicks off moving MobileFrontend's class model towards that of oojs - many thanks for Roan for doing most of the legwork :-): https://gerrit.wikimedia.org/r/155593 https://gerrit.wikimedia.org/r/155589 https://gerrit.wikimedia.org/r/129336 On the long term we'd look to swap out the Class.js and eventemitter.js files in MobileFrontend for oojs, but this is going to be tricky and require some care, possibly mixing both oojs and MobileFrontend's class code in the repository at the same time. e.g. increasing JavaScript on the short term, but reducing it on the longterm. The MobileFrontend core development team will need to work out how best to manage this transition. Since Flow is very DOM-focused, as opposed to many smaller JavaScript modules with element management per the currently-accepted use of OOjs, it is unclear how we may go about integrating with OOjs fully. However, some potential use cases have been identified as candidates for implementing OOjs on an interim basis, primarily by abstracting some current FlowBoardComponent workflows, such as those which handle (re-)rendering of existing and new content fetched from the API. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
On Thu, 07 Aug 2014 01:41:58 +0200, Bartosz Dziewoński matma@gmail.com wrote: We have an mediawiki/extensions.git meta repository. To avoid conflicts with MediaWiki core's extensions directory (…) I always advocate people set up an extensions directory on their disk elsewhere (e.g. next to mediawiki-core, not inside), either as the meta repo clone or as your own container directory with git clones of individual extensions inside of it. Then simply configure $wgExtensionAssetsPath to point at localhost/git/extensions or whatever and require_once in LocalSettings from ../extensions instead. This is possible with skins in exactly the same way, but instead of $wgExtensionAssetsPath you configure $wgStylePath. The 'common' directory might be a bit problematic here. I think we should just get rid of it once and for all and put the assets in resources/ where they belong. I filed a bug to track this and I'm actively working on it. https://bugzilla.wikimedia.org/show_bug.cgi?id=69277 There is a bit of a problem as to where to put the static assets now; I have a pending patch where I try to introduce a directory for them: https://gerrit.wikimedia.org/r/#/c/155771/ – comments welcome. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Template RFC
On Fri, Aug 22, 2014 at 11:34 AM, Jon Robson jdlrob...@gmail.com wrote: 1) We need some JavaScript API for using templates (in current form all we have is a standard way to ship templates from the server to the frontend). Well, Mantle does have a basic template.add(), get(), and render() API. It seems OK. Before we know the API is right I would like to see proof-of-concept template compilation. Handlebars templates can/could be compiled in advance at commit-time, during a build process, on the server at request time, or on the client. Developers should not have to change code for this. ( https://bugzilla.wikimedia.org/show_bug.cgi?id=64735 for handlebars.) Trevor is working on a template widget for oojs which will make this possible Great, though I don't understand what this is. Is this a specific widget that uses a specifc template, or an platform widget that handles templating for other OOUI widgets? 2) We need a standard template language 3) Better namespacing for templates - we identified that we will need to find better ways of uniquely identifying templates [3]. We questioned whether point 2 should be blocking, as we recognised that even if we decide to standardise on Knockoff in future, it should be trivial to write a script that converts Hogan/Handlebars template language to Knockoff. The Mantle ResourceLoader module in current form is template agnostic and currently works with both Hogan and Handlebars, so in theory should make it easy to transition from one template language to another. On this basis, I think the next step would be for the oojs development team to get a template widget up that can be used by Mantle. Great, again I'm confused :) FWIW the pressing need of several teams is a dialog component with the Agora appearance to replace homebrew and jQuery UI dialogs. As I understand it, besides VE of course Media Viewer has an OOUI dialog in its Use this file pop-up. -- =S Page Features engineer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Roadmap and deployment highlights - week of August 25th
Hi all, Welcome to this week's deployment highlights! I'm pretending to be Greg today. The full log of planned deployments next week can be found at: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_Aug_25th A couple of notable items on Tuesday of next week * Global user CSS and JS will be enabled. More details in Legoktm's announcement: https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2014-August/000893.html * The in other projects sidebar will be enabled as a Beta Feature next week: https://www.mediawiki.org/wiki/Beta_Features/Other_projects_sidebar As usual, the release train keeps rolling. 1.24wmf18 (currently on test.wikipedia.org, test2.wikipedia.org and mediawiki.org) will be rolled out to the remainder of sites over the course of the week. https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf18 ...and 1.24wmf19 (currently still in active development) will be branched on Thursday and deployed to mediawiki.org then: https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf19 That's all for now. Greg will go back to pretending to be Greg on Monday. :-) Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Template RFC
On Fri, Aug 22, 2014 at 12:14 PM, S Page sp...@wikimedia.org wrote:
On Fri, Aug 22, 2014 at 11:34 AM, Jon Robson jdlrob...@gmail.com wrote:
Trevor is working on a template widget for oojs which will
make this possible
Great, though I don't understand what this is. Is this a specific widget
that uses a specifc template, or an platform widget that handles
templating for other OOUI widgets?
It will be a generic container for template rendering.
// Create a templatevar thing = new OO.ui.TemplateWidget( 'some way of
identifying the template' );// Render the template into thing.$element
thing.render( { /* some data */ } );// Add the template to the body
$( 'body' ).append( thing.$element );// Render it again with different
data, retaining the same this.$element reference
thing.render( { /* some different data */ } );
This will also allow you to extend TemplateWidget and add methods which
either change the data and either trigger re-rendering or just surgically
tweak the DOM as needed.
- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Extension idea
How feasible would it be to enable file access/linking to files on a given filesystem without having to upload them? Use case, I have a documentation system in /server/docs which I provide access internally via a file share to all users. However remote users are unable to access that share. How difficult/dangerous would it be to to have an extension that provided access to those files for our remote users. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Announcing #wikimedia-teampractices IRC channel
Join the Team Practices Group https://www.mediawiki.org/wiki/Team_Practices_Group in #wikimedia-teampractices on IRC https://en.wikipedia.org/wiki/Irc ( irc.freenode.net) to chat about software development practices, processes, theories, and philosophy - as they pertain to Wikimedia engineering and beyond. -- Arthur Richards Team Practices Manager [[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
[Wikitech-l] Using magic functions (e.g. __get) to deprecate class members
TL;DR: Please review [1] I was asked to discuss the topic on the mailing list, so here goes. Since some time Siebrand is making an effort to improve code quality by making it phpcs-strict compliant [0]. This involves explicitly declaring the visibility of class members. Alas, intended or not, in very many cases he did not only explicitly declare the class variable's visibility, but he also changed it from the implicit 'public' to explicit 'protected' or 'private', thus introducing a major API change without a proper deprecation period. Apparently this was not noticed (or at least not challenged) by the reviewers. I checked a few of his commits and they were all merged within hours. Now, to be clear about that, I appreciate both changes - the phpcs compliance as well as the more limited accessibility of class variables. This was long overdue. However, to introduce something like this a proper deprecation period is in my opinion essential, in particular considering the extent of the changes. I do believe that Siebrand checked that the variables he declared protected or private were not used by extensions. However, he missed one (EditPage::mTokenOk) which subsequently resulted in a bug in an extension (SemanticForms). Given the number of the now newly hidden variables I am quite sure, that there are other cases. If only because many extensions are not hosted on WMF servers, so they can not be checked. To keep the changes and still be able to properly deprecate the direct access to the member variables I submitted a patch [1] that makes use of PHP magic functions [2]. They provide access to the class members and issue a deprecation warning. The intention is to keep these functions for the custom two releases [3], i.e. until 1.26, and then remove them. This patch was shot down for three reasons: quote * it duplicates code * there is no tests * our code base barely use the magic methods and I am pretty sure Tim Starling commented a while back about them being nasty. /quote When I pointed out, that these functions are not re-entrant and thus Tims warning [4] did not apply the answer was I have merely copy pasted Tim comment without even attempting to understand what it means. I was subsequently asked to present this to the mailing list which I do with this mail. I would appreciate comments on the patch (preferably constructive), that would allow us to not revert Siebrand's changes and still properly deprecate formerly public class members. Thanks. Stephan [0] https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+branch:master+topic:phpcs,n,z [1] https://gerrit.wikimedia.org/r/#/c/151370/ [2] http://php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members [3] https://www.mediawiki.org/wiki/Deprecation [4] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85288#c17504 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using magic functions (e.g. __get) to deprecate class members
My opinion on this matter is that if you were using a variable prefixed with “m”, which is clearly one of our conventions for declaring variables private, you are asking for trouble. Just recently when the password hashing API patch was merged, it caused problems with CentralAuth since it tried accessing mPassword directly. In cases like this, I don’t think there’s any need for a deprecation period, because you are playing with fire in the first place. Obviously, for other variables that don’t start with “m” and are not documented as @private or @protected, then we need the grace period. -- Tyler Romeo 0x405D34A7C86B42DF From: Stephan Gambke s7ep...@gmail.com Reply: Wikimedia developers wikitech-l@lists.wikimedia.org Date: August 22, 2014 at 18:33:24 To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] Using magic functions (e.g. __get) to deprecate class members TL;DR: Please review [1] I was asked to discuss the topic on the mailing list, so here goes. Since some time Siebrand is making an effort to improve code quality by making it phpcs-strict compliant [0]. This involves explicitly declaring the visibility of class members. Alas, intended or not, in very many cases he did not only explicitly declare the class variable's visibility, but he also changed it from the implicit 'public' to explicit 'protected' or 'private', thus introducing a major API change without a proper deprecation period. Apparently this was not noticed (or at least not challenged) by the reviewers. I checked a few of his commits and they were all merged within hours. Now, to be clear about that, I appreciate both changes - the phpcs compliance as well as the more limited accessibility of class variables. This was long overdue. However, to introduce something like this a proper deprecation period is in my opinion essential, in particular considering the extent of the changes. I do believe that Siebrand checked that the variables he declared protected or private were not used by extensions. However, he missed one (EditPage::mTokenOk) which subsequently resulted in a bug in an extension (SemanticForms). Given the number of the now newly hidden variables I am quite sure, that there are other cases. If only because many extensions are not hosted on WMF servers, so they can not be checked. To keep the changes and still be able to properly deprecate the direct access to the member variables I submitted a patch [1] that makes use of PHP magic functions [2]. They provide access to the class members and issue a deprecation warning. The intention is to keep these functions for the custom two releases [3], i.e. until 1.26, and then remove them. This patch was shot down for three reasons: quote * it duplicates code * there is no tests * our code base barely use the magic methods and I am pretty sure Tim Starling commented a while back about them being nasty. /quote When I pointed out, that these functions are not re-entrant and thus Tims warning [4] did not apply the answer was I have merely copy pasted Tim comment without even attempting to understand what it means. I was subsequently asked to present this to the mailing list which I do with this mail. I would appreciate comments on the patch (preferably constructive), that would allow us to not revert Siebrand's changes and still properly deprecate formerly public class members. Thanks. Stephan [0] https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+branch:master+topic:phpcs,n,z [1] https://gerrit.wikimedia.org/r/#/c/151370/ [2] http://php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members [3] https://www.mediawiki.org/wiki/Deprecation [4] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85288#c17504 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l signature.asc Description: Message signed with OpenPGP using AMPGpg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using magic functions (e.g. __get) to deprecate class members
On 8/22/14, Stephan Gambke s7ep...@gmail.com wrote: TL;DR: Please review [1] I was asked to discuss the topic on the mailing list, so here goes. Since some time Siebrand is making an effort to improve code quality by making it phpcs-strict compliant [0]. This involves explicitly declaring the visibility of class members. Alas, intended or not, in very many cases he did not only explicitly declare the class variable's visibility, but he also changed it from the implicit 'public' to explicit 'protected' or 'private', thus introducing a major API change without a proper deprecation period. Apparently this was not noticed (or at least not challenged) by the reviewers. I checked a few of his commits and they were all merged within hours. Now, to be clear about that, I appreciate both changes - the phpcs compliance as well as the more limited accessibility of class variables. This was long overdue. However, to introduce something like this a proper deprecation period is in my opinion essential, in particular considering the extent of the changes. I do believe that Siebrand checked that the variables he declared protected or private were not used by extensions. However, he missed one (EditPage::mTokenOk) which subsequently resulted in a bug in an extension (SemanticForms). Given the number of the now newly hidden variables I am quite sure, that there are other cases. If only because many extensions are not hosted on WMF servers, so they can not be checked. To keep the changes and still be able to properly deprecate the direct access to the member variables I submitted a patch [1] that makes use of PHP magic functions [2]. They provide access to the class members and issue a deprecation warning. The intention is to keep these functions for the custom two releases [3], i.e. until 1.26, and then remove them. This patch was shot down for three reasons: quote * it duplicates code * there is no tests * our code base barely use the magic methods and I am pretty sure Tim Starling commented a while back about them being nasty. /quote When I pointed out, that these functions are not re-entrant and thus Tims warning [4] did not apply the answer was I have merely copy pasted Tim comment without even attempting to understand what it means. I was subsequently asked to present this to the mailing list which I do with this mail. I would appreciate comments on the patch (preferably constructive), that would allow us to not revert Siebrand's changes and still properly deprecate formerly public class members. Thanks. Stephan [0] https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+branch:master+topic:phpcs,n,z [1] https://gerrit.wikimedia.org/r/#/c/151370/ [2] http://php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members [3] https://www.mediawiki.org/wiki/Deprecation [4] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85288#c17504 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Well that's probably the first compelling use case I've heard for upping our version requirements to php 5.4. (yeah yeah, not going to happen until wmf cluster changes). Its not like SMW is the only thing that's been hit by changing member visibility, we've also got things like bug 65733 and db7be31e31987c6124 (albeit the second one was caught extremely quickly). It seems natural that we're not going to be able to catch every single possible use of such variables in existence no matter how hard we try. The most major objection I would have, is that the code would make all private/protected properties accessible, not just the recently deprecated. Otherwise the code kind of seems like a lesser evil. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using magic functions (e.g. __get) to deprecate class members
On 8/22/14, Tyler Romeo tylerro...@gmail.com wrote: My opinion on this matter is that if you were using a variable prefixed with “m”, which is clearly one of our conventions for declaring variables private, you are asking for trouble. Just recently when the password hashing API patch was merged, it caused problems with CentralAuth since it tried accessing mPassword directly. In cases like this, I don’t think there’s any need for a deprecation period, because you are playing with fire in the first place. Obviously, for other variables that don’t start with “m” and are not documented as @private or @protected, then we need the grace period. -- Tyler Romeo 0x405D34A7C86B42DF $mFoo was a historic coding convention for all member variables (including public variables). There are many explicitly public variables starting with $m: bawolff@Bawolff-L:/var/www/w/git/includes$ git grep 'public $m' |wc -l 266 I don't think we should treat $m variables any different from other variables. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using magic functions (e.g. __get) to deprecate class members
On 23 August 2014 01:56, Brian Wolff bawo...@gmail.com wrote: The most major objection I would have, is that the code would make all private/protected properties accessible, not just the recently deprecated. Otherwise the code kind of seems like a lesser evil. I thought about introducing arrays of allowed variables for that case, but decided against it. Currently there should be no code in existence that accesses previously private variables. If somebody now starts to access private variables through this mechanism that were not accessible before, it is their own fault. They would have to specifically find the __get/__set methods and decide to use them in spite of them being clearly marked as deprecated and in the full knowledge of them being removed in 12 months latest. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension idea
On 8/22/14, John phoenixoverr...@gmail.com wrote: How feasible would it be to enable file access/linking to files on a given filesystem without having to upload them? Use case, I have a documentation system in /server/docs which I provide access internally via a file share to all users. However remote users are unable to access that share. How difficult/dangerous would it be to to have an extension that provided access to those files for our remote users. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l The code is officially deprecated, but... try $wgForeignFileRepos[] = array( 'class'= 'FSRepo', 'name' = 'shared-folder', 'directory'= '/your/directory', 'hashLevels' = 0, 'url' = 'http://your.wiki.tld/path/to/media/', ); You can also specify other directories for the thumb directory, etc. Default is a subdirectory of your shared folder I believe. Thumb directory needs to be writable by the webserver. There will be some performance overhead. Probably somewhat similar to instant commons. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Thoughts about roles
Done in https://gerrit.wikimedia.org/r/155861 - your critique would be appreciated:) On Sat, Aug 9, 2014 at 6:40 PM, Max Semenik maxsem.w...@gmail.com wrote: Currently a lot of our extension Vagrant roles are working like Swiss knives: they do everything possible to imagine. For example, MobileFrontend always installs 3 optional dependencies while CirrusSearch includes its configuration for unit tests that among other things enforces $wgCapitalLinks = false which is untypical for most MW installs. I think many of these actually make development harder. Solution? Can we split some larger roles to basic and advanced parts, so that people who need an extension to play around or to satisfy a dependency will not be forced to emulate a significant part of WMF infrastructure? -- Best regards, Max Semenik ([[User:MaxSem]]) -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
