Re: [Wikitech-l] Prefs removal
Also note that, as explained in more detail on the ticket[1], gadgetizing will be a bad idea. We might as well not remove it at all. A preference is a lot better than a gadget because (at least for now) its label will be localised a lot better, and more importantly: The option will show up in the relevant preferences section. For reasons explained elsewhere, shipping gadgets by default with the Gadgets extension is not an option and generally counter-productive and bound to cause unwanted/unmaintained scripts to rot in wikis after being injected upon installation. That's now how the Gadgets extension work, and imho it should stay that way. Instead of gadgetization, a better option would be to move them into an extension (not the Gadgets extension). Which means the extension can: * add it to the preferences section where it used to be * use the same key as the old preference in core, so that users don't have to reset their preferences (as opposed to "gadget-foo"). Especially the latter is in my opinion a must-have for the smooth migration of any wiki that decides to install this "LegacyPreferences" extension after upgrading their MediaWiki-install. Besides, most of the preferences discussed here aren't worth a gadget (I guess most communities will not want them in the preferences section after voting to have them disabled/removed from core). They don't add any significant features, only silly visual options that someone afraid of change insisted on in the past. That is, of course, referring to preferences we would end up removing after some kind of consensus. I'm not talking about all preferences or any preference in particular . In other words: If the story is "remove them from core, add as default-available[2] gadget". Then please, *please*, keep them in core. Because that wouldn't be an improvement over the current situation. If we have good ground to remove them (because they're silly options that we don't want end-users to be thinking about), then we remove them. Don't move them from one junkyard to another. -- Krinkle [1] https://bugzilla.wikimedia.org/40346 [2] default-available != default-enabled ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Prefs removal
Le 09/10/12 01:52, Erik Moeller a écrit : > Do we have a more complete report than > https://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences > ? If not, could someone pull one? It would be ideal to not only have > prefs listed by frequency, but to also exclude users from the set > who've not been recently active. We have the maintenance/userOptions.php script which can give usage for all user preferences or just for a specific one. Example on my local development wiki: $ php userOptions.php --usage gender Usage for (default: 'unknown'): 2 user(s): 'female' 1 user(s): 'male' Done. $ It does not filter by user age though, but I guess that will be trivial to implement by using `user.user_touched`. Will be happy to review and validate any change made made to improve that script. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WebPlatform.org
Webplatform skin design is not consistent and catchy for languages like Malayalam, Tamil or Hindi as for English. But what, they've enabled even Narayam. :-) On Tuesday 09 October 2012 04:53:14 AM IST, Ryan Lane wrote: Can you explain? I find this project amazing (converging and optimizing documentation effort as opposed to keep building a dozen chapels and why not starting a new, flashy one?). And I'm very happy to see that MediaWiki has been put into use! If the Wikimedia Foundation has got a significant involvement I think it would be nice to share here and elsewhere. This site is going to be big in no time if all those orgs indeed point their web developers there. Sorry, that was me with my webplatform hat on. I've been helping them with infrastructure. We have a few more extensions that haven't been added to Gerrit yet. We plan on doing so sometime soon. - Ryan ___ 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] [Semediawiki-user] Maps and Semantic Maps 2.0 released!
Hey, > Nice Looking forward to demos at SMWCon :) There will indeed be demo's, see http://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2012/New_features_in_Maps_and_Semantic_Maps > BTW, is Semantic Bundle going to be updated with the latest maps soon? This depends, we've not seen a new Semantic Bundle for a while due to the git migration, and no one seems to be willing to update the build scripts. That should be rather simple though, so if any developers wants to help out here... > If not, are there any dependencies that will break if I upgrade to Maps 2.0? Maps 2.0 requires Validator 0.5. So if you have any extensions that use Validator, I'd recommend you get their latest version. There is a compatibility layer that should prevent breakage, but updating is still advisable. In particular Semantic MediaWiki and Semantic Result Formats. Both these extensions have not seen a new release yet using this version of Validator, but they are close to seeing a release, and should be pretty stable at this point. If you don't want to run beta versions you'll be better off waiting another month or so with upgrading your extensions. I'd recommend the same for anyone using OpenLayers and wants high stability, there are some non-trivial open issues which are also present in the 2.0 release. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Prefs removal
On Tue, Oct 9, 2012 at 3:53 AM, Krinkle wrote: > Instead of gadgetization, a better option would be to move them into an > extension (not the Gadgets extension). Which means the extension can: > * add it to the preferences section where it used to be > * use the same key as the old preference in core, so that users don't have to > reset their preferences (as opposed to "gadget-foo"). I'm not sure if making it a Gadget is a good idea (and you make a good case that it's not), but this idea would be worse in many cases. Many preferences, if removed from core, would require a hook in order for LegacyPreferences to handle it. A hook that we would then have to support for the foreseeable future. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Welcome Michelle Grover as QA to the Mobile Team!
Greetings all, I am pleased to announce that Michelle Grover joins WMF this week as a Mobile QA contractor. Michelle has worked as a Java Developer, Software Developer in Test, Release Engineer for Adobe, and Mobile QA Automation Lead for Crowdfusion (They developed The Daily, TMZ, Telepictures mobile applications). She's worked closely with agile teams (SCRUM and XP) over the past 7 + years, Implemented Kanban and setup and configured CI using Hudson,Team CIty and Cruise Control. She's been married 17 years and has a 6 year old son. Currently lives in Monument, CO and has spent a lot of time up in the mountains. Michelle will help both the community and mobile team build out a sound process for testing both the mobile web and our apps. The team would like to welcome her and wish her success. --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Welcome Michelle Grover as QA to the Mobile Team!
Welcome! Prepare to a lot of weird bugs that affect weird languages :) -- Amir Elisha Aharoni ። אָמִיר אֱלִישָׁע אַהֲרוֹנִי Localization developer ። מְפַתֵּחַ תְּמִיכָה רַב־לְשׁוֹנִית Wikimedia Foundation ። קֶרֶן וִיקִימֶדְיָה 2012/10/9 Tomasz Finc : > Greetings all, > > I am pleased to announce that Michelle Grover joins WMF this week as a > Mobile QA contractor. > > Michelle has worked as a Java Developer, Software Developer in Test, > Release Engineer for Adobe, and Mobile QA Automation Lead for > Crowdfusion (They developed The Daily, TMZ, Telepictures mobile > applications). She's worked closely with agile teams (SCRUM and XP) > over the past 7 + years, Implemented Kanban and setup and configured > CI using Hudson,Team CIty and Cruise Control. She's been married 17 > years and has a 6 year old son. Currently lives in Monument, CO and > has spent a lot of time up in the mountains. > > Michelle will help both the community and mobile team build out a > sound process for testing both the mobile web and our apps. The team > would like to welcome her and wish her success. > > --tomasz > > ___ > Wmfall mailing list > wmf...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Welcome Michelle Grover as QA to the Mobile Team!
Welcome! — Patrick On Tue, Oct 9, 2012 at 3:19 PM, Amir E. Aharoni wrote: > Welcome! > > Prepare to a lot of weird bugs that affect weird languages :) > > -- > Amir Elisha Aharoni ። אָמִיר אֱלִישָׁע אַהֲרוֹנִי > Localization developer ። מְפַתֵּחַ תְּמִיכָה רַב־לְשׁוֹנִית > Wikimedia Foundation ። קֶרֶן וִיקִימֶדְיָה > > > 2012/10/9 Tomasz Finc : > > Greetings all, > > > > I am pleased to announce that Michelle Grover joins WMF this week as a > > Mobile QA contractor. > > > > Michelle has worked as a Java Developer, Software Developer in Test, > > Release Engineer for Adobe, and Mobile QA Automation Lead for > > Crowdfusion (They developed The Daily, TMZ, Telepictures mobile > > applications). She's worked closely with agile teams (SCRUM and XP) > > over the past 7 + years, Implemented Kanban and setup and configured > > CI using Hudson,Team CIty and Cruise Control. She's been married 17 > > years and has a 6 year old son. Currently lives in Monument, CO and > > has spent a lot of time up in the mountains. > > > > Michelle will help both the community and mobile team build out a > > sound process for testing both the mobile web and our apps. The team > > would like to welcome her and wish her success. > > > > --tomasz > > > > ___ > > Wmfall mailing list > > wmf...@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wmfall > > ___ > 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] Welcome Michelle Grover as QA to the Mobile Team!
I am pleased to announce that Michelle Grover joins WMF this week as a Mobile QA contractor. Cool! It's always great to have more QA people around! Welcome, and we hope to see you around the list and IRC! :) -- Mark Holmquist Software Engineer, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Welcome Michelle Grover as QA to the Mobile Team!
On 10/09/2012 03:17 PM, Tomasz Finc wrote: > Michelle will help both the community and mobile team build out a > sound process for testing both the mobile web and our apps. The team > would like to welcome her and wish her success. This is so rockin'. Welcome, Michelle! Looking forward to seeing what you build and helping spread the word. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Welcome Michelle Grover as QA to the Mobile Team!
I'd like an excuse to get to the Front Range, though, hopefully Michelle and I could meet face-to-face at some point. http://goo.gl/maps/6m5yz It's been a real pleasure working with Michelle through the hiring process and orientation, and I am looking forward to the QA staff doing some nifty things in the very near future. -Chris On Tue, Oct 9, 2012 at 1:59 PM, Michelle Grover wrote: > Thanks everyone! and Yup I join the CO "office" though Chris is pretty far > away from where I live :) > > > On Tue, Oct 9, 2012 at 1:25 PM, Sangeeta Prashar > wrote: > >> Great to have you on board Michelle! >> Cheers, >> Sangeeta >> >> >> On Tue, Oct 9, 2012 at 12:17 PM, Tomasz Finc wrote: >> >>> Greetings all, >>> >>> I am pleased to announce that Michelle Grover joins WMF this week as a >>> Mobile QA contractor. >>> >>> Michelle has worked as a Java Developer, Software Developer in Test, >>> Release Engineer for Adobe, and Mobile QA Automation Lead for >>> Crowdfusion (They developed The Daily, TMZ, Telepictures mobile >>> applications). She's worked closely with agile teams (SCRUM and XP) >>> over the past 7 + years, Implemented Kanban and setup and configured >>> CI using Hudson,Team CIty and Cruise Control. She's been married 17 >>> years and has a 6 year old son. Currently lives in Monument, CO and >>> has spent a lot of time up in the mountains. >>> >>> Michelle will help both the community and mobile team build out a >>> sound process for testing both the mobile web and our apps. The team >>> would like to welcome her and wish her success. >>> >>> --tomasz >>> >>> ___ >>> Wmfall mailing list >>> wmf...@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wmfall >>> >> >> >> >> -- >> *Sangeeta Prashar* >> *Recruiting Manager >> spras...@wikimedia.org * >> *415-839-6885 ext. 6829* >> * >> * "Just Wikipedia it. " >> >> ___ >> Wmfall mailing list >> wmf...@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wmfall >> >> > > ___ > Wmfall mailing list > wmf...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wmfall > > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome Michelle Grover as QA to the Mobile Team!
W00t no more intercontinental debugging yay! Welcome, Michelle! :) -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Prefs removal
Just reiterating that discussing individual preferences (not to mention touching them) is a very bad idea before we have good criteria of some sort to evaluate them. Usage stats are a requirement but such criteria are not only about them because some preferences may be of small harm for many and of great use for "a few" (like thousands or dozens of thousands of users) who may also happen to be the most active users, making such prefs a net positive. Oh, and of course "gadgetization of preferences" means (almost) nothing. Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Prefs removal
On 10/9/12 5:25 PM, Federico Leva (Nemo) wrote: Just reiterating that discussing individual preferences (not to mention touching them) is a very bad idea before we have good criteria of some sort to evaluate them. Usage stats are a requirement but such criteria are not only about them because some preferences may be of small harm for many and of great use for "a few" (like thousands or dozens of thousands of users) who may also happen to be the most active users, making such prefs a net positive. Oh, and of course "gadgetization of preferences" means (almost) nothing. Admittedly, having started circa 2003, I've not revisited or reset most of those settings very often -- and didn't notice some even existed. But I don't usually run with JavaScript (rather, I use NoScript by default), so "gadgetization" seems like a terrible idea to me! You're not saving anything by moving from one place to another. It's just another chance for further bit-rot. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] subst: and Parser::preprocess not sending correct frame to tag extensions?
I'm not sure if this is by design, but it seems when using a tag extension
inside of a template, the tag extension is not passed the correct frame
information about the template when using subst: or Parser::preprocess
For example: The contents of Template:Test are:
{{{1}}}
When using {{subst:Test|Hello World}} You get
{{{1}}}
Even if SomeTagExtension is correctly using $parser->recursiveTagParse.
It seems the $frame value does not contain the template variables when
using subst or preprocess. The frame object type is PPFrame_DOM instead of
PPTemplateFrame_DOM.
Am I doing something wrong, is this by design, or is it a bug?
Thanks
Andrew
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] subst: and Parser::preprocess not sending correct frame to tag extensions?
On 10/09/2012 06:52 PM, Andrew Fitzgerald wrote:
I'm not sure if this is by design, but it seems when using a tag extension
inside of a template, the tag extension is not passed the correct frame
information about the template when using subst: or Parser::preprocess
For example: The contents of Template:Test are:
{{{1}}}
When using {{subst:Test|Hello World}} You get
{{{1}}}
Even if SomeTagExtension is correctly using $parser->recursiveTagParse.
It seems the $frame value does not contain the template variables when
using subst or preprocess. The frame object type is PPFrame_DOM instead of
PPTemplateFrame_DOM.
Am I doing something wrong, is this by design, or is it a bug?
Thanks
Andrew
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Extension tags are intentionally shielded from the parser and the
preprocessor. The lack of PSTs in extension tags is a long-standing bug:
< https://bugzilla.wikimedia.org/show_bug.cgi?id=2700>.
—Victor.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Scribunto API
Hello, Scribunto currently has only some basic APIs to do essential things like access the parser frame and write things into debug log. Intending to change it, I wrote an API specification for an in-script API, which Lua scripts should be able to use in order to access certain MediaWiki features and interfaces. I have previously submitted this specification during the hackathon early this summer to the mailing list: < https://www.mediawiki.org/wiki/Extension:Scribunto/API_specification> Now I have collected the feedback, fixed the specification accordingly and intend to move on and actually implement it, expect for the mw.query part (which require more benchmarking and more design considerations). If you have comments regarding the specification, I would highly appreciate them now, before I actually write the code. —Victor. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Prefs removal
William Allen Simpson wrote: > On 10/9/12 5:25 PM, Federico Leva (Nemo) wrote: >> Just reiterating that discussing individual preferences (not to mention >> touching them) is a very bad idea before we have good criteria of some sort >> to evaluate them. >> Usage stats are a requirement but such criteria are not only about them >> because some preferences may be of small harm for many and of great use for >> "a few" (like thousands or dozens of thousands of users) who may also happen >> to be the most active >> users, making such prefs a net positive. >> Oh, and of course "gadgetization of preferences" means (almost) nothing. >> > Admittedly, having started circa 2003, I've not revisited or reset most of > those settings very often -- and didn't notice some even existed. > > But I don't usually run with JavaScript (rather, I use NoScript by default), > so "gadgetization" seems like a terrible idea to me! > > You're not saving anything by moving from one place to another. It's just > another chance for further bit-rot. The virtue of gadgetization comes from the idea that MediaWiki, following the development of Wikipedia, contains a number of user preferences that were tailored to a specific problem or a specific need on (the English) Wikipedia that might be better handled nowadays by a local solution (such as a JavaScript gadget). Yes, of course, gadgetization ultimately moves the user preference from one tab to another and there are still code maintenance costs, but gadgetization can reduce the complexity of MediaWiki (in terms of code and UI clutter). I think the usage stats will be illuminating. And, of course, having global (Wikimedia-wide) gadgets or a gadgets repository for any MediaWiki installation to use would mitigate some of the other pitfalls of gadgetization. That doesn't mean it's evil, that just means gadgetization needs to be used sensibly. Much like anything else. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] HTML5 fallout: type=email now flows to browser, unexpected validation follows
Some MediaWiki forms have elements with type=email. Up until 2 weeks ago, en-wiki would strip that out as it's invalid in old-school HTML. But now that $wgHtml5 is true, it flows to the browser. A nifty result is mobile browsers will use a custom on-screen keyboard with @ and .com in it for type=email. A new result is HTML5 browsers will not submit a form with an invalid e-mail in it. A strange result is, Special:ChangeEmail [1] already does client-side validation of e-mail, so users on HTML5 browsers get duelling tooltips! (See screenshot [2] attached to Bug 40909 [3].) Other MediaWiki forms that use Html or HTMLForm to specify HTML5 field types will also have behavior changes. If you don't want the browser's validation, Munaf Assaf figured out you can disable it [4] or you can sort-of override the styles for the browser's validation tooltip [5]. Does anyone have experience of doing client-side validation in conjunction with the browsers' own validation? Ideally a jQuery plug-in would build up client-side validation on top of the browser's HTML5 support while hiding their big differences in implementation. Thanks in advance, [1] https://en.wikipedia.org/wiki/Special:ChangeEmail [2] http://bug-attachment.wikimedia.org/attachment.cgi?id=11173 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=40909 [4] http://www.w3.org/TR/html5/attributes-common-to-form-controls.html#attr-fs-novalidate [5] http://jsfiddle.net/trixta/qTV3g/ -- =S Page software engineer on E3 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Merging the ContentHandler into master
On 8 October 2012 19:33, Daniel Kinzler wrote: > Hi all! > > As discussed last week with Rob, I have no prepared a merge request that > introduces the ContentHandler into MediaWiki core. This is a major building > block for the Wikidata project. I hope the merge will be completed soon, since > this will grow stale fast. > > The merge request is here: https://gerrit.wikimedia.org/r/27194 > > Since Gerrit doesn't show nice diffs for merges, > here's a squashed version: https://gerrit.wikimedia.org/r/27191 > > Please let us know very soon if there are any serious problems. The branch has > been reviewed before, and I resolved several remaining issues over the last > days, so I hope there are no more big issues left. And it's merged. Congrats! I'm sure it is just an oversight, but some of the review comments in [1] were not addressed before the merge. For example MessagesEn.php (a fix has been submitted by someone else) and MessageCache.php [2]. [1] https://gerrit.wikimedia.org/r/#/c/25736/1 (took me a while to find that change anymore) [2] I see now that I misunderstood the code, but at least the comment needs to be updated. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin pages on MW.org, and Skin repos in Gerrit
On Wed, 26 Sep 2012 00:08:14 -0700, Krinkle wrote: A few random points: We should get some basic structure conventions in place before stuff goes wild. I like the idea of installing a Skin as an extension, but placing it in the core skins directory feels wrong because it currently does auto-discovery to some degree, and of course it means wgExtensionAssetsPath can't be used as skins as it is outside that directory view. Well, the outdated auto-discovery just applies to the skins/*.php pattern. It doesn't really affect this pattern at all. Actually on that topic. I haven't really thought of it much. But I wonder how long we should keep doing that. Any 3rd party skin using that auto-loading is inherently either an outdated not using RL or uses a hack to do so. I wonder if we should remove the auto-loading in a few releases. The way the skins in mediawiki/extensions/skins.git do it is by simply being installed as a completely valid extension. Another problem I found in the current setup is that its a bit counter-intuitive how to manage the directory structure for developers. I mean, most of us probably have this: - mediawiki - /core (clone mediawiki/core.git) - /extensions (directory with clones of individual extensions or clone of mediawiki/extensions.git tracking repo) * Set $wgExtensionAssetsPath accordingly * Use require_once( "$IP/../extensions/Foo/Foo.php"); (whether or not via a tmp variable) instead of require_once( "$IP/extensions/Foo/Foo.php"); But then, where to clone a skins repository (or mediawiki/skins.git tracking repo)? Interesting problem. I've been using the mediawiki/extensions/ repo. But I've been creating a symlink whenever I actually install something. You generally don't actually need a path to something till you actually use it. And you never really just install every extension (you wouldn't have the individual configuration) so creating a symlink for each one I actually use hasn't been an issue. Right now one way to work might be to do things the other way around. Instead of symlinking skin folders into skins/, symlink the few core stuff into the /skins tracking repo then point wgStylePath to the tracking repo. Though yes we might want to find another solution to that issue. Wherever it is, it needs to be scalable to more complex installations. A directory "skins" next to "extensions" next to "core" is not feasible as the paths would be incorrect (it wouldn't be in wgExtensionAssetsPath, nor in wgStylePath). I think it'd be a lot easier if skins were installed as extensions, not as a (currently, unhandleable) hybrid. Except skins aren't extensions. If you try to make a skin as an actual extension some skin features like getSkinStylePath and patterns using stylename don't work. And now instead of skins all being located in the same area they're scattered about. Some skins in an actual skin dir. While other skins are shoved into extensions/ among a huge pile of non-skins that make things impractical to handle. Tbh, while it's not typically acknowledged we pretty much have this same issue in extensions. We only skirt by and say it's not an issue because few extensions use assets and we don't have built-in extensions that are always included. We have wgExtensionAssetsPath but that's frankly not enough. That's not flexibility that's a restriction saying that all extensions must be in the same directory. Which goes against the reality that someone may want to put some common extensions into a common folder, and some other extensions into a local folder, or maybe a user folder separate from the global extensions. What we may want to consider doing is fixing our assets and skin paths so that different extensions/skins can properly have different paths. Putting skins inside of skins/ actually has a big advantage I want to take advantage of. Right now it's true that this skin pattern works the same way as an extension. But it's not going to stay that way in the long run. Skins are different than extensions. For extensions you need a lot of flexibility and control. Almost no extension is similar to another so you want complete control over all the configuration. But for skins you use the same patterns over and over. You setup the same things in each skin. The plan is to slowly start auto detecting conventions. Replace require_once with a method to abstractly install skins. Shorten the code needed to register modules. Start auto registering skin classes and i18n when we see certain patterns. Start moving stuff from php into an extension definition file. Maybe as proper extensions in mediawiki/extensions/SkinName.git (and drop mediawiki/skins/*.git). That would be the easier, though it is also nice to keep extensions and skins separate enough in that anything that adds preferences, special pages etc. is in a separate optional repository. Or perhaps agree that skins should be installed from mediawiki/skins/*.git repositories, bu
Re: [Wikitech-l] HTML5 fallout: type=email now flows to browser, unexpected validation follows
On Tue, 09 Oct 2012 21:29:45 -0700, S Page wrote: Some MediaWiki forms have elements with type=email. Up until 2 weeks ago, en-wiki would strip that out as it's invalid in old-school HTML. But now that $wgHtml5 is true, it flows to the browser. A nifty result is mobile browsers will use a custom on-screen keyboard with @ and .com in it for type=email. A new result is HTML5 browsers will not submit a form with an invalid e-mail in it. A strange result is, Special:ChangeEmail [1] already does client-side validation of e-mail, so users on HTML5 browsers get duelling tooltips! (See screenshot [2] attached to Bug 40909 [3].) Other MediaWiki forms that use Html or HTMLForm to specify HTML5 field types will also have behavior changes. If you don't want the browser's validation, Munaf Assaf figured out you can disable it [4] or you can sort-of override the styles for the browser's validation tooltip [5]. Does anyone have experience of doing client-side validation in conjunction with the browsers' own validation? Ideally a jQuery plug-in would build up client-side validation on top of the browser's HTML5 support while hiding their big differences in implementation. Bind an event handler for the browser's 'invalid' event. When fired use e.preventDefault() and apply your own invalid form input styling. Canceling the event will not disable the browser's validation (the form will still not be submitted) but it will disable the browser UI allowing you to do the styling yourself. It would actually be nice to re-do our validation. I'd like to see more of our forms that validate input using things like required and pattern to do validation that works using native UI when JS is disabled. The ideal would probably be: - Our server side form setups that do validation will provide ways to declare simple validation like required and pattern (as opposed to only offering a validity callback). These we will start exposing natively. - We offer a wrapper lib around the native validation API perhaps with some extras to abstract away some of the things about validation that aren't exposed natively. (eg: I'm thinking well probably want a custom way to define a validation callback instead of individual code having to manually listen to input. Also there's probably no 'valid' event to remove custom UI) - In that wrapper lib we include a shim that will implement pattern and require handling in place of the native browser in browsers that haven't implemented the form validation API yet. - The lib will include a way to do custom validation so we don't need other code to do that. - We should also take the notion of "Expensive validation" into account in the api. Some type of custom validation that depends on something expensive like a HTTP call so we have a native way to ask to fire an expensive validation callback with a promise but only after the library delays waiting to make sure the user isn't still typing the stuff in. - Using that expensive validation callbacks we should offer the option in some of our form defining code to automatically run a server side validation callback in the same form that defined the form output. Using that we could define a single username validation method that would automatically do server side form validation, output validation errors server side, and at the same time be used by a client side callback to tell you that the username is reserved before you even submit the form. (Though this might require an entirely new Form api anyways) - On top of that lib we'll include an extra MW specific lib that cancels out the native UI and does validation UI the way we're planning with the style guide (https://www.mediawiki.org/wiki/Style_guide/Forms) - We'll have a way for individual skins to hook into that lib so they can override the way that the form validation UI is done. In the absolute ideal. Even all our custom validity will be done entirely using the wrapper lib around the native form validation. Such that if for some reason we do not load the lib in charge of using the wrapper lib to create our custom validation UI (or if a skin finds some way to say it does not want us to load that UI) the entire system still works by using the browser's native validation UI. Thanks in advance, [1] https://en.wikipedia.org/wiki/Special:ChangeEmail [2] http://bug-attachment.wikimedia.org/attachment.cgi?id=11173 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=40909 [4] http://www.w3.org/TR/html5/attributes-common-to-form-controls.html#attr-fs-novalidate [5] http://jsfiddle.net/trixta/qTV3g/ -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
