Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 21/05/14 07:25, Bartosz Dziewoński wrote: > * $IP/extensions/SkinName/ for everything, the rest as above. This > makes the skin work exactly like an extension. The only example I > could find on mediawiki.org is the Nostalgia skin [5]. I introduced this facility to core many years ago, and I still generally think it is a good idea. There are in fact at least another 6 skins that use this system: they are in mediawiki/extensions/skins in Gerrit -- a directory layout carried over from Subversion. Nostalgia should have been put there too. The main reason I think it is a good idea is code sharing. Treating skins as extensions means you can share automated distribution and installation systems. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 20/05/14 23:05, Daniel Friesen wrote: On 2014-05-20, 3:48 PM, Isarra Yos wrote: Out of curiosity, what are your reasons for advocating lowercase skin names over the standard camelcase format used throughout the rest of MediaWiki? I included those in my bullet points. * The skinname you require is the same one assigned to $wgValidSkins and set on $wgDefaultSkin and set on $skinname, and $stylepath. * For all skins using the old autoload pattern the assets directory remains them same, so nothing has to be re-cached. But that sounds more like an oversight with the autoloader implementation and class setup than an actual reason why it would be good practice to use lowercase. Was there a particular design reason to set those up to be that way? There's also a third reason. There are 3 names for a skin containing two words: * foobar * FooBar * Foo Bar Foo Bar is exposed to users in the interface as the human readable name. And foobar is exposed in &useskin= $wgDefaultSkin and the current directory asset structure, in essence it IS the canonical name of the skin. FooBar however generally isn't exposed anywhere. It exists exclusively for things like skin class names like SkinFooBar and optionally some filenames, both of which are internal to the skin. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] Two of those also apply to extensions in general - FooBar and Foo Bar. Has this sort of inconsistency between name presentations ever posed a problem there? And with skins in particular, why would the internal handling of the skin name be coupled to the filename at all? And why the case-sensitivity, especially when not all platforms that mw supports even use case-sensitive filesystems? Is this just a holdover from the autoloader implementation? Sorry for all the questions, but this all seems quite odd, and I never really had the opportunity to put much thought into it before. -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 2014-05-20, 3:48 PM, Isarra Yos wrote: > Out of curiosity, what are your reasons for advocating lowercase skin > names over the standard camelcase format used throughout the rest of > MediaWiki? I included those in my bullet points. * The skinname you require is the same one assigned to $wgValidSkins and set on $wgDefaultSkin and set on $skinname, and $stylepath. * For all skins using the old autoload pattern the assets directory remains them same, so nothing has to be re-cached. There's also a third reason. There are 3 names for a skin containing two words: * foobar * FooBar * Foo Bar Foo Bar is exposed to users in the interface as the human readable name. And foobar is exposed in &useskin= $wgDefaultSkin and the current directory asset structure, in essence it IS the canonical name of the skin. FooBar however generally isn't exposed anywhere. It exists exclusively for things like skin class names like SkinFooBar and optionally some filenames, both of which are internal to the skin. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "What should be the recommended / supported way to do [MediaWiki] skins? (A proposal.)" on wikitech-l
Am Dienstag, 20. Mai 2014, 18:24:03 schrieb Sumana Harihareswara: > Hey, folks! Since I believe all of you have written, modded, or > maintained MediaWiki skins, I thought you would want to see MatmaRex's > proposal and give him a "sure, ok" or a "wait no" or something in > between. :-) > > Best, > Sumana Hi Sumana, thanks for highlighting me :) I was not on that list, and as such my reply won't be threaded, but see below... (oh, and my main mail address changed) > > > tl;dr Let's adopt a better structure for skins. A more detailed proposal is > at the bottom. > > As you might know, I am doing a Google Summer of Code project aiming to > disentangle the mess of MediaWiki's skinning system a little bit, make > creating custom skins a bit less painful and improve the separation between > MediaWiki and its core skins [0] > (https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki). > > I want this thread to result in code changes :) > > > > So, MediaWiki supports skins, and apart from the four core ones there's a > couple dozen of skins available for installation [1]. And looking at them, > it seems as if every single one used a different directory structure, and > this a different installation method. > > I think this is bad, and that we should standardize on something – > preferably one of the widely used methods – and use it for the core skins > as well to provide a good example. > > > > There seem to be three popular ways: > > * $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ for > assets, using an autodiscovery mechanism to automagically make the skin > available after the files are copied in the right place. This is used by > all of the core skins (Vector has some special cases, but let's ignore that > for now), as well as many external skins (e.g. Cavendish [2]), at a glance > mostly older ones. * $IP/skins/SkinName/ for both assets and PHP files > ($IP/skins/skinname/SkinName.php etc.), using require_once in LocalSettings > like extensions to load the skin, manually adding an entry to > $wgValidSkinNames in the main PHP file. This seems to be the preferred > method among "modern" skins, for example Erudite [3] or Nimbus [4]. * > $IP/extensions/SkinName/ for everything, the rest as above. This makes the > skin work exactly like an extension. The only example I could find on > mediawiki.org is the Nostalgia skin [5]. From my own experience for KDE back then we indeed also used the old method #1, and tbh, it is quite messy, especially when you want to maintain core mw files/folders and have your own skin separate. In the end we used a merged repo for mediawiki and the skin, which had other benefits, as we also did mediawiki hacks. So i am also all for solution #3 > > > > The first one sounds like a no-go for me (in spite of being currently used > for core skins, ugh): > > * The directory structure makes it annoying to both manage and write such > skins (you need to copy/delete the PHP file and the directory separately, > many text editors provide additional features for files contained in a > single directory, and just look at our .gitignore file for skins oh god why > [6]). * The usage of autodiscovery, while making installation and testing a > bit simpler, makes it impossible or unpleasant to temporarily disable a > skin or to provide configuration settings for it (the last point doesn't > affect core skins). > > This leaves us with the two latter options: packaging skins similarly to > extensions and sticking them in /skins, or packaging them like extensions > and treating them like extensions. These two options are pretty similar and > discussing them will be a bit bikesheddy, but let's do it anyway. (Note > also that even if we wanted to, we can't stop anyone from using either of > these if they feel like it, as MediaWiki supports loading everything from > anywhere if you really want. We can, however, deprecate skin > autodiscovery.) Option #2 sounds rather messy to me, for the above reasons. All files below /skins/ makes it harder (again) to have separate repos (not even talking about the visual mess :P). I guess a lot of people have a custom skin as their only modification to mediawiki's functionality, and not everyone of them is a git hero, i guess, so it would be a very friendly attempt to go for #3 and having a separate directory for each skin. Besides (as already mentioned) every other system does it like that as well, and it is well known. > > > > Personally I'm leading towards the /skins/SkinName option. The pros are: > > * It seems to be more widely used, which means that it "felt right" to a lot > of people, and that shouldn't be underestimated. * It's less revolutionary, > and rather a simple improvement over the current system. * It's more > intuitive when compared to how other applications / projects works. > (Corollary: just because MediaWiki skins can do everything that extensions > can do, we sho
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 20/05/14 22:07, Daniel Friesen wrote: On 2014-05-20, 2:25 PM, Bartosz Dziewoński wrote: There seem to be three popular ways: * $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ for assets, using an autodiscovery mechanism to automagically make the skin available after the files are copied in the right place. This is used by all of the core skins (Vector has some special cases, but let's ignore that for now), as well as many external skins (e.g. Cavendish [2]), at a glance mostly older ones. I wouldn't say it's popular. It's just the way it was done in core and the only way anyone without knowledge of large swaths of MediaWiki could figure out. * $IP/skins/SkinName/ for both assets and PHP files ($IP/skins/skinname/SkinName.php etc.), using require_once in LocalSettings like extensions to load the skin, manually adding an entry to $wgValidSkinNames in the main PHP file. This seems to be the preferred method among "modern" skins, for example Erudite [3] or Nimbus [4]. You're misstating this pattern, the pattern goes: * $IP/skins/skinname/skinname.php * $IP/skins/skinname/* (assets) The directory name and entry file are both lowercase, not skins/SkinName/ nor skins/skinname/SkinName, this means: * The skinname you require is the same one assigned to $wgValidSkins and set on $wgDefaultSkin and set on $skinname, and $stylepath. * For all skins using the old autoload pattern the assets directory remains them same, so nothing has to be re-cached. * The same "entry filename = dirname + .php" pattern we've worked to make extensions follow is followed by skins, which will also help implement special loading for skins. This is the pattern described by the tutorial I wrote, used by Erudite, monaco-port, every custom skin I've developed for a client, and the pattern that should be used going forward. I had hoped to eventually add special behaviors in the loading of skins that would reduce the boilerplate needed to setup skins following this pattern. * $IP/extensions/SkinName/ for everything, the rest as above. This makes the skin work exactly like an extension. The only example I could find on mediawiki.org is the Nostalgia skin [5]. This was used for Nostalgia because the cluster didn't have any handling for $IP/skins/ like it does for $IP/extensions/. The only thing that should be using Nostalgia is https://nostalgia.wikipedia.org/. And no other skin should be using the pattern Nostalgia uses. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Out of curiosity, what are your reasons for advocating lowercase skin names over the standard camelcase format used throughout the rest of MediaWiki? -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Square bounding boxes + typesafe enums
Hey, developers. This week - tomorrow, 2100 UTC on Wednesday - we'll be talking about Andrew Green's "Typesafe enums" proposal https://www.mediawiki.org/wiki/Requests_for_comment/Typesafe_enums , and looking to finish off the next step of C. Scott Ananian's "Square bounding boxes" RfC. https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes We'll be in #wikimedia-office - for YOUR time, try this: http://everytimezone.com/#2014-5-21,540,6bj Meeting page: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-21 Next week we will probably be talking about Pau Giner's grid system RfC https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system and about extension management, probably on Monday the 26th and probably at a time better for Australia and Asia. -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On 2014-05-20, 2:25 PM, Bartosz Dziewoński wrote: > There seem to be three popular ways: > > * $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ > for assets, using an autodiscovery mechanism to automagically make the > skin available after the files are copied in the right place. This is > used by all of the core skins (Vector has some special cases, but > let's ignore that for now), as well as many external skins (e.g. > Cavendish [2]), at a glance mostly older ones. I wouldn't say it's popular. It's just the way it was done in core and the only way anyone without knowledge of large swaths of MediaWiki could figure out. > * $IP/skins/SkinName/ for both assets and PHP files > ($IP/skins/skinname/SkinName.php etc.), using require_once in > LocalSettings like extensions to load the skin, manually adding an > entry to $wgValidSkinNames in the main PHP file. This seems to be the > preferred method among "modern" skins, for example Erudite [3] or > Nimbus [4]. You're misstating this pattern, the pattern goes: * $IP/skins/skinname/skinname.php * $IP/skins/skinname/* (assets) The directory name and entry file are both lowercase, not skins/SkinName/ nor skins/skinname/SkinName, this means: * The skinname you require is the same one assigned to $wgValidSkins and set on $wgDefaultSkin and set on $skinname, and $stylepath. * For all skins using the old autoload pattern the assets directory remains them same, so nothing has to be re-cached. * The same "entry filename = dirname + .php" pattern we've worked to make extensions follow is followed by skins, which will also help implement special loading for skins. This is the pattern described by the tutorial I wrote, used by Erudite, monaco-port, every custom skin I've developed for a client, and the pattern that should be used going forward. I had hoped to eventually add special behaviors in the loading of skins that would reduce the boilerplate needed to setup skins following this pattern. > * $IP/extensions/SkinName/ for everything, the rest as above. This > makes the skin work exactly like an extension. The only example I > could find on mediawiki.org is the Nostalgia skin [5]. This was used for Nostalgia because the cluster didn't have any handling for $IP/skins/ like it does for $IP/extensions/. The only thing that should be using Nostalgia is https://nostalgia.wikipedia.org/. And no other skin should be using the pattern Nostalgia uses. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On Wed, May 21, 2014 at 12:25 AM, Bartosz Dziewoński wrote: > As you might know, I am doing a Google Summer of Code project aiming to > disentangle the mess of MediaWiki's skinning system a little bit, make > creating custom skins a bit less painful and improve the separation between > MediaWiki and its core skins [0] (https://www.mediawiki.org/ > wiki/Separating_skins_from_core_MediaWiki). > The skin system is likely rather intimidating for a newer developer; I know my way around it, and so do you and some other core MediaWiki developers, but we're not the target audience, since MW's default skin changes *very* rarely. As such, it'd be beneficial to everyone to make the skin system a bit friendlier and less of a gigantic mess, which is what it mostly is today. > * $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ for > assets, using an autodiscovery mechanism to automagically make the skin > available after the files are copied in the right place. This is used by > all of the core skins (Vector has some special cases, but let's ignore that > for now), as well as many external skins (e.g. Cavendish [2]), at a glance > mostly older ones. I'd say that this method is a remnant from darker ages and it'd be nice if we could forget it ever existed... > * $IP/skins/SkinName/ for both assets and PHP files > ($IP/skins/skinname/SkinName.php etc.), using require_once in > LocalSettings like extensions to load the skin, manually adding an entry to > $wgValidSkinNames in the main PHP file. This seems to be the preferred > method among "modern" skins, for example Erudite [3] or Nimbus [4]. I'm going to assume that the lowercase "skinname" in $IP/skins/skinname/SkinName.php is just a typo and you meant it to be CamelCased as "SkinName". If and when so, yes, this is what should be our recommended way of doing it. CamelCase is how we name things consisting of multiple words (i.e. BlueSky, DuskToDawn, HowTo, ...), so it's only reasonable to use CamelCase here too. Having written and cleaned up many skins myself, this is the naming convention I prefer and that seems natural right from the start. > * The usage of autodiscovery, while making installation and testing a bit > simpler, makes it impossible or unpleasant to temporarily disable a skin or > to provide configuration settings for it (the last point doesn't affect > core skins). This is why autodiscovery needs to go. > This leaves us with the two latter options: packaging skins similarly to > extensions and sticking them in /skins, or packaging them like extensions > and treating them like extensions. These two options are pretty similar and > discussing them will be a bit bikesheddy, but let's do it anyway. Bikeshedding? In wikitech-l? You must be new here. ;-) > The pros of using /extensions/SkinName are: > > [...] * All non-core code in one place. > While this is true and somewhat handy, there can be unexpected situations such as two independent developers (or teams) coming up with two different things that have...the exact same name -- this is true for "Nimbus"; there is an extension and a skin with that name; the skin likely predates the extension, but unlike the extension, the skin wasn't always FOSS. Thanks and regards, -- Jack Phoenix MediaWiki developer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On Tue, May 20, 2014 at 2:25 PM, Bartosz Dziewoński wrote: > > tl;dr Let's start putting all skins files in a single directory, and let's > use a grown-up structure with one class per file + separate init code for > them. Okay? > Sounds good to me. I agree with Tyler that there's more to wish for, but what you're proposing doesn't at all foreclose further innovation, so I think it's a practical way forward. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On Tue, May 20, 2014 at 5:25 PM, Bartosz Dziewoński wrote: > tl;dr Let's start putting all skins files in a single directory, and let's > use a grown-up structure with one class per file + separate init code for > them. Okay? I wouldn't consider this change to be truly revolutionary. Would would really be a great restructuring of the skinning system is if I could make a skin by just writing a couple of HTML templates (probably using Gabriel's DOM-based templating language), throw them in a directory and then tell MediaWiki where the directory is. However, staying on the topic that you brought up, I do agree with keeping skins in a separate directory than extensions. It implies a bit of control on our part concerning how skins need to be structured, whereas if they were extensions, we cannot place any requirements on the structure. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
tl;dr Let's adopt a better structure for skins. A more detailed proposal is at the bottom. As you might know, I am doing a Google Summer of Code project aiming to disentangle the mess of MediaWiki's skinning system a little bit, make creating custom skins a bit less painful and improve the separation between MediaWiki and its core skins [0] (https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki). I want this thread to result in code changes :) So, MediaWiki supports skins, and apart from the four core ones there's a couple dozen of skins available for installation [1]. And looking at them, it seems as if every single one used a different directory structure, and this a different installation method. I think this is bad, and that we should standardize on something – preferably one of the widely used methods – and use it for the core skins as well to provide a good example. There seem to be three popular ways: * $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ for assets, using an autodiscovery mechanism to automagically make the skin available after the files are copied in the right place. This is used by all of the core skins (Vector has some special cases, but let's ignore that for now), as well as many external skins (e.g. Cavendish [2]), at a glance mostly older ones. * $IP/skins/SkinName/ for both assets and PHP files ($IP/skins/skinname/SkinName.php etc.), using require_once in LocalSettings like extensions to load the skin, manually adding an entry to $wgValidSkinNames in the main PHP file. This seems to be the preferred method among "modern" skins, for example Erudite [3] or Nimbus [4]. * $IP/extensions/SkinName/ for everything, the rest as above. This makes the skin work exactly like an extension. The only example I could find on mediawiki.org is the Nostalgia skin [5]. The first one sounds like a no-go for me (in spite of being currently used for core skins, ugh): * The directory structure makes it annoying to both manage and write such skins (you need to copy/delete the PHP file and the directory separately, many text editors provide additional features for files contained in a single directory, and just look at our .gitignore file for skins oh god why [6]). * The usage of autodiscovery, while making installation and testing a bit simpler, makes it impossible or unpleasant to temporarily disable a skin or to provide configuration settings for it (the last point doesn't affect core skins). This leaves us with the two latter options: packaging skins similarly to extensions and sticking them in /skins, or packaging them like extensions and treating them like extensions. These two options are pretty similar and discussing them will be a bit bikesheddy, but let's do it anyway. (Note also that even if we wanted to, we can't stop anyone from using either of these if they feel like it, as MediaWiki supports loading everything from anywhere if you really want. We can, however, deprecate skin autodiscovery.) Personally I'm leading towards the /skins/SkinName option. The pros are: * It seems to be more widely used, which means that it "felt right" to a lot of people, and that shouldn't be underestimated. * It's less revolutionary, and rather a simple improvement over the current system. * It's more intuitive when compared to how other applications / projects works. (Corollary: just because MediaWiki skins can do everything that extensions can do, we shouldn't encourage that.) * Since it's still similar to how extensions work, adapting the current system (WMF deployments, tarball packaging, installation via web installer) should be straightforward. * Switching current skins to this system within the mediawiki/core repo will be trivial. The pros of using /extensions/SkinName are: * We already have a battle-tested system for doing things with extensions (WMF deployments, tarball packaging, installation via web installer). * All non-core code in one place. I would like to settle this within a week or two. Help! :) Thoughts? I will document the result and, if feasible, convert core skins to be closer to the recommended format afterwards. tl;dr Let's start putting all skins files in a single directory, and let's use a grown-up structure with one class per file + separate init code for them. Okay? [1] https://www.mediawiki.org/wiki/Category:Skin (this category tree is a mess, huh) [2] https://www.mediawiki.org/wiki/Skin:Cavendish [3] https://www.mediawiki.org/wiki/Skin:Erudite [4] https://www.mediawiki.org/wiki/Skin:Nimbus [5] https://www.mediawiki.org/wiki/Extension:Nostalgia [6] https://git.wikimedia.org/blob/mediawiki%2Fcore/master/skins%2F.gitignore -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Transcluding non-text content as HTML on wikitext pages
On 05/20/2014 02:46 AM, Daniel Kinzler wrote: > My main reason for recycling the tag was to not introduce a new tag > extension. may occur verbatim in existing wikitext, and would break > when the tag is introduces. The only existing mentions of this are probably us discussing it ;) In any case, it's easy to grep for it & nowikify existing uses. > Other than that, I'm find with outputting whatever tag you like for the > transclusion. Great! > Implementing the tag is something else, though - I could implement > it so it will work for HTML transclusion, but I'm not sure I understand the > original domparse stuff well enough to get that right. Would domparse be in > core, btw? Yes, it should be in core. I believe that a very simple implementation (without actual DOM balancing, using Parser::recursiveTagParse()) would not be too hard. The guts of it are described in [1]. The limitations of recursiveTagParse should not matter much for this use case. >> Now back to the syntax. Encoding complex transclusions in a HTML parameter >> would be rather cumbersome, and would entail a lot of attribute-specific >> escaping. > > Why would it involve any escaping? It should be handled as a tag extension, > like > any other. Transclusions can contain quotes, which need to be escaped in attribute values to make sure that the attribute is in fact an attribute. Since quotes tend to be more common than tags this means that there's going to be more escaping. I also find it harder to scan for quotes ending a long attribute value. Tags are easier to spot. >> $wgRawHtml is disabled in all wikis we are currently interested in. >> MediaWiki does properly report the extension tag from siteinfo when >> $wgRawHtml is enabled, so it ought to work with Parsoid for private wikis. >> It will be harder to support the > transclusion=""> exception. > > I should try what expandtemplates does with with $wgRawHtml enabled. > Nothing, probably. It will just come back containing raw HTML. Which would be > fine, I think. Yes, that case will work. But $wgRawHtml enabled is the exception, and not something I'd like to encourage. > By the way: once we agree on a mechanism, it would be trivial to use the same > mechanism for special page transclusion. My patch actually already covers > that. > Do you agree that this is the Right Thing? It's just transclusion of HTML > content, after all. Yes, that sounds good to me. Gabriel [1]: https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_do_I_render_wikitext_in_my_extension.3F ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MW-Vagrant improvements at the Zürich Hackathon
On 05/16/2014 04:40 PM, Arthur Richards wrote: > Just wanted to send out an update on the progress we made around MW-Vagrant > improvements at the Zürich Hackathon. Our primary goal was to make some key > production services available in MW-Vagrant in order to make local > development/testing easier/more reliable. We made some excellent headway, > focussing on a few key services: SSL, Varnish, CentralAuth/Multiwiki. Rock! > Varnish: > This is proving to be much more difficult than anticipated, however some > progress was made and work is ongoing, spearheaded by Andrew Otto. The plan > is to set up varnish VCLs for mw-vagrant similar to what is set up for text > varnishes in production, with a frontend and backend instance running in > vagrant. Andrew is in the midst of refactoring the production varnish > module, to make it usable in Vagrant. Andrew, I am looking forward to featuring this in https://www.mediawiki.org/wiki/Performance_profiling_for_Wikimedia_code#Starting_in_your_development_environment ! -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!
Update. There is now a Special:Map which when passed API parameters can construct a map from the corresponding API request. This would give us the opportunity to create maps around existing data. This would support a Nearby map view. See this link for more: http://wikimaps-ext.wmflabs.org/wiki/Making_maps_via_the_API All of this is very prototypal and can be removed if there is no need. I plan to get this off Github and on to Gerrit sometime next week. On Tue, May 20, 2014 at 6:48 PM, Dan Andreescu wrote: >> >> FYI, Limn is also sort of taken in the MediaWiki/WMF namespace: >> https://www.mediawiki.org/wiki/Analytics/Limn > > > Yep, but that Limn is dying slowly. If we do this new extension properly, > it will take its place. As Erik said, this is not staffed for success > right now but it would address many shared needs. > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] SF meetup: Making Wikipedia fast
Wikimedia tech San Francisco meetup tomorrow at 7pm Pacific: Making Wikipedia Fast by Ori Livneh and Aaron Schulz Session co-organized with the San Francisco & Silicon Valley Web Performance Group http://www.meetup.com/SF-Web-Performance-Group/events/182182062/ Live streaming and video will be available at https://plus.google.com/events/ce6kihklfld2p10ep28p5ia7klg http://www.youtube.com/watch?v=0PqJuZ1_B6w Questions at #wikimedia-dev* IRC* -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC and OPW Q&A at the ECT meeting
On Sun, May 18, 2014 at 1:47 PM, Quim Gil wrote: > The Engineering Community team will devote its monthly IRC meeting to answer > any questions from interns and mentors and to discuss any related topics. > > Tuesday 20 at 16:00 UTC at #wikimedia-office > https://www.mediawiki.org/wiki/Engineering_Community_Team/Meetings/2014-05-20 The logs of the meeting are available at the wiki page. Thank you for a very interesting discussion! -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Output from Zurich Hackathon - yet another maps extension!
> > Sorry, but "Limn" sounds pretty pretentious, and it is hard to pronounce. > no problem at all, you're not hurting my feelings :) Sounds like people don't like the name, so let's drop it. The top contender right now is Visual: and I'll ping the Visual Editor folks right now to see if they mind. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Output from Zurich Hackathon - yet another maps extension!
Sorry, but "Limn" sounds pretty pretentious, and it is hard to pronounce. On Tue, May 20, 2014 at 11:53 AM, Dan Andreescu wrote: >> >> Overall this is very exciting work with lots of potential future >> > applications. I don't think it's resourced for success yet, but let's >> > figure out where it should sit in our roadmap since it would address >> > many shared needs if done right. >> > >> >> True! It would be nice to talk about it during Wikimania, from my side I >> started a community consultation here: >> >> https://meta.wikimedia.org/wiki/Requests_for_comment/How_to_deal_with_open_datasets > > > Thanks for the interest Micru, and especially that RFC. I am not scheduled > to attend Wikimania but I could fly myself there if you think this topic > will receive attention. (Also, I don't know how Wikimania works :)) > ___ > 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] Output from Zurich Hackathon - yet another maps extension!
> > Overall this is very exciting work with lots of potential future > > applications. I don't think it's resourced for success yet, but let's > > figure out where it should sit in our roadmap since it would address > > many shared needs if done right. > > > > True! It would be nice to talk about it during Wikimania, from my side I > started a community consultation here: > > https://meta.wikimedia.org/wiki/Requests_for_comment/How_to_deal_with_open_datasets Thanks for the interest Micru, and especially that RFC. I am not scheduled to attend Wikimania but I could fly myself there if you think this topic will receive attention. (Also, I don't know how Wikimania works :)) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!
> > FYI, Limn is also sort of taken in the MediaWiki/WMF namespace: > https://www.mediawiki.org/wiki/Analytics/Limn Yep, but that Limn is dying slowly. If we do this new extension properly, it will take its place. As Erik said, this is not staffed for success right now but it would address many shared needs. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] That you to anonymous users
On May 20, 2014 4:57 PM, "David Gerard" wrote: > > On 20 May 2014 15:35, Strainu wrote: > > > I've recently noticed the "Thank you" feature is only available for > > signed-in users, while anons cannot receive "thank yous". The > > anonymous users are often the ones that would need encouraging the > > most, so it would make sense to me to have this feature available to > > them too. > > Are there significant technical problems against such a change? > > > > I asked for this on the editor engagement list too. Fabrice said: [1] > > "Sadly, we couldn't make this feature available for anonymous users, > as you have to be registered to receive notifications right now. This > is because IP addresses cannot be trusted to deliver notifications to > the users they were intended to. I don't expect we'll change that > anytime soon. We should all encourage anonymous user to register if > they want to enjoy the same benefits as other members." > > Fabrice, is this still the case? Are there ways around this? > > * I suppose session cookies for anons just to possibly thank them is a > bit excessive. It sure sounds excessive. Setting a session cookie after an edit has been made by an anon might[1] be quite cheap in reality, or at least cheap enough to justify the cost. Privacy wise it also seems ok, but I might be overlooking some things on that regard as well. --Martijn [1] I haven't measured and aren't used to thinking Wikipedia scale, so I might be massively mistaken. My wholly untrustworthy intuition however thinks that if it's only set with an edit, the performance hit is limited, especially compared to the resources the edit itself costs. > ___ > 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] Bot flags and human-made edits
On Tue, May 20, 2014 at 6:05 AM, Jon Robson wrote: > I'm confused. Why wouldn't you just mark a user account as being a bot and > simply determine bot edits from username alone? > Volume? Cluebot does a high volume of edits, but as mentioned, doesn't want the edit hidden from RC. > > Any other mechanism seems prone to abuse or being inaccurate... > On 20 May 2014 07:36, "Amir Ladsgroup" wrote: > > > Thank you legoktm for exampling, > > Another case that happened in Persian Wikipedia, is creating > bot-generated > > articles by user request this task is too contervisal to be marked as bot > > and we didn't mark it but other edits of my bot is marked as bot > > > > Best > > > > > > On Tue, May 20, 2014 at 11:01 AM, Legoktm > >wrote: > > > > > > > > On 5/19/14, 6:39 PM, Dan Garry wrote: > > > > > >> On 19 May 2014 19:36, Amir Ladsgroup wrote: > > >> > > >> As a bot operator I think API parameter about flagging bot or not is > > >>> necessary > > >>> > > >>> Sure, but as I'm not a bot operator, can you explain why and what > you > > >> use > > >> this for, to help me understand? :-) > > >> > > > > > > If the edits should show up in users watchlists/recentchanges for > humans > > > to look at. An example would be ClueBot NG on enwp which doesn't flag > > it's > > > edits with the bot flag so humans can review them. > > > > > > Another case where this recently came up is in MassMessage (bug 65180). > > > Some edits like those to user talk pages should be marked as a bot > since > > > the user will receive a notification regardless, but ones that are made > > to > > > Project (or other) namespaces, should not be flagged as bot so users > will > > > see them in their watchlists. > > > > > > -- Legoktm > > > > > > > > > ___ > > > Wikitech-l mailing list > > > Wikitech-l@lists.wikimedia.org > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > > > > -- > > Amir > > ___ > > 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 > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] That you to anonymous users
Using two words I'd say "dynamic IPs". Though a reasonable time limit (a hour?) would work too. Vito Inviato con AquaMail per Android http://www.aqua-mail.com Il 20 maggio 2014 16:36:02 Strainu ha scritto: Hi, I've recently noticed the "Thank you" feature is only available for signed-in users, while anons cannot receive "thank yous". The anonymous users are often the ones that would need encouraging the most, so it would make sense to me to have this feature available to them too. Are there significant technical problems against such a change? Thanks, Strainu ___ 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] That you to anonymous users
On Tue, 2014-05-20 at 17:35 +0300, Strainu wrote: > I've recently noticed the "Thank you" feature is only available for > signed-in users, while anons cannot receive "thank yous". The > anonymous users are often the ones that would need encouraging the > most, so it would make sense to me to have this feature available to > them too. > > Are there significant technical problems against such a change? https://bugzilla.wikimedia.org/show_bug.cgi?id=61022 (if arguments are missing, adding them in a comment is welcome). andre -- 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] That you to anonymous users
On 20 May 2014 15:35, Strainu wrote: > I've recently noticed the "Thank you" feature is only available for > signed-in users, while anons cannot receive "thank yous". The > anonymous users are often the ones that would need encouraging the > most, so it would make sense to me to have this feature available to > them too. > Are there significant technical problems against such a change? I asked for this on the editor engagement list too. Fabrice said: [1] "Sadly, we couldn't make this feature available for anonymous users, as you have to be registered to receive notifications right now. This is because IP addresses cannot be trusted to deliver notifications to the users they were intended to. I don't expect we'll change that anytime soon. We should all encourage anonymous user to register if they want to enjoy the same benefits as other members." Fabrice, is this still the case? Are there ways around this? * I suppose session cookies for anons just to possibly thank them is a bit excessive. * Could limit "thanks" to a short time after the edit (limiting either sending or receiving). Any other ways we could implement this with minimal false-positives on thanking people? If that's considered a problem :-) - d. [1] http://lists.wikimedia.org/pipermail/ee/2013-July/000525.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] That you to anonymous users
Hi, I've recently noticed the "Thank you" feature is only available for signed-in users, while anons cannot receive "thank yous". The anonymous users are often the ones that would need encouraging the most, so it would make sense to me to have this feature available to them too. Are there significant technical problems against such a change? Thanks, Strainu ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bot flags and human-made edits
On Mon, May 19, 2014 at 7:09 PM, Dan Garry wrote: >1. When editing via the API, allows the user to choose whether or not to >flag an edit as a bot edit using the bot parameter. >2. When editing via the standard editing interface, flags all edits >(i.e. all human made edits) as bot edits. > Note for #2, it's possible to submit the edit with a "bot=0" parameter to avoid the edit being marked as "bot". This also works for logged actions (which someday need to be fixed in the API to be able to be non-flagged, much as was done for edits in r29540). I've always thought the reasons for this disparate behavior are primarily historical: Way back, there was no editing API and the bot userright forced edits from the account to be marked as bot edits. But people discovered, as mentioned elsewhere in this thread, that some edits by accounts that should have the bot flag shouldn't be hidden from Watchlists and RecentChanges; on enwiki at least, this led to some bot accounts not being flagged as such. And eventually things were changed so that the flagging of the edit was optional rather than a requirement. For index.php edits this had to be done in a "specify that you don't want this edit flagged" manner to avoid breaking all the existing code. But for the new editing API it could be done more directly, so it was. As for the lack of a UI for "bot=0" in index.php edits, I expect it's both because others don't want to clutter the UI either and because the editing API now exists for actual bots. 1. What's the user story for including the edit-level granularity for >bot accounts in the API? > "bot" flagging of edits essentially controls whether the edits are hidden by default in Watchlists and RecentChanges. Many bots make a mixture of edits that should be hidden and edits that should not be. 2. What's the user story for making it so that every edit made by a >human on a bot account is flagged as bot edit? > I don't know of one, besides historical reasons as mentioned above. I don't know about the policies on other wikis, but on enwiki a human editing with a bot-flagged account is explicitly doing so to have those edits hidden from RecentChanges and is supposed to use a "regular" account for their normal editing. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Output from Zurich Hackathon - yet another maps extension!
FYI, Limn is also sort of taken in the MediaWiki/WMF namespace: https://www.mediawiki.org/wiki/Analytics/Limn DJ On Thu, May 15, 2014 at 3:51 PM, Dan Andreescu wrote: >> >> 2014-05-14 19:43 GMT+03:00 Dan Andreescu : >> > For the short term, I think further exploration of the Map namespace is >> > great, but I think generic visualization work could go into the >> > Visualization namespace. My suggestion for a name for this namespace may >> > seem a bit obscure. It's a word that means "to illuminate": Limn [5]. >> >> 3) It's a word that is difficult to translate. >> > > I'm open to alternatives, but my original choice (WikiViz) was taken > ___ > 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] Bot flags and human-made edits
On Tue, May 20, 2014 at 5:41 PM, Jon Robson wrote: > So bot tasks are sometimes performed from user accounts that don't belong > to bots... o_O why?! > No, some of bots tasks needs to be seen and reviewed by others, for example there are bots that do task per user request in a page (like an automated vending machine that people can go to a page and request things and bots do it automatically), or automated reverts (that are being made by clue bot NG) or other things that people exampled before in this discussion > > (forgive my naivety I come into this conversation as an outside with no > prior knowledge of how this stuff works) > On 20 May 2014 14:09, "Amir Ladsgroup" wrote: > > > On Tue, May 20, 2014 at 5:35 PM, Jon Robson wrote: > > > > > I'm confused. Why wouldn't you just mark a user account as being a bot > > and > > > simply determine bot edits from username alone? > > > > > > Any other mechanism seems prone to abuse or being inaccurate... > > > > > People gave several examples of bot tasks that needs to be seen in RC and > > they weren't abuse > > > > > > > On 20 May 2014 07:36, "Amir Ladsgroup" wrote: > > > > > > > Thank you legoktm for exampling, > > > > Another case that happened in Persian Wikipedia, is creating > > > bot-generated > > > > articles by user request this task is too contervisal to be marked as > > bot > > > > and we didn't mark it but other edits of my bot is marked as bot > > > > > > > > Best > > > > > > > > > > > > On Tue, May 20, 2014 at 11:01 AM, Legoktm < > legoktm.wikipe...@gmail.com > > > > >wrote: > > > > > > > > > > > > > > On 5/19/14, 6:39 PM, Dan Garry wrote: > > > > > > > > > >> On 19 May 2014 19:36, Amir Ladsgroup wrote: > > > > >> > > > > >> As a bot operator I think API parameter about flagging bot or not > > is > > > > >>> necessary > > > > >>> > > > > >>> Sure, but as I'm not a bot operator, can you explain why and > what > > > you > > > > >> use > > > > >> this for, to help me understand? :-) > > > > >> > > > > > > > > > > If the edits should show up in users watchlists/recentchanges for > > > humans > > > > > to look at. An example would be ClueBot NG on enwp which doesn't > flag > > > > it's > > > > > edits with the bot flag so humans can review them. > > > > > > > > > > Another case where this recently came up is in MassMessage (bug > > 65180). > > > > > Some edits like those to user talk pages should be marked as a bot > > > since > > > > > the user will receive a notification regardless, but ones that are > > made > > > > to > > > > > Project (or other) namespaces, should not be flagged as bot so > users > > > will > > > > > see them in their watchlists. > > > > > > > > > > -- Legoktm > > > > > > > > > > > > > > > ___ > > > > > Wikitech-l mailing list > > > > > Wikitech-l@lists.wikimedia.org > > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > > > > > > > > > > > > > > -- > > > > Amir > > > > ___ > > > > 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 > > > > > > > > > > > -- > > Amir > > ___ > > 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 > -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bot flags and human-made edits
So bot tasks are sometimes performed from user accounts that don't belong to bots... o_O why?! (forgive my naivety I come into this conversation as an outside with no prior knowledge of how this stuff works) On 20 May 2014 14:09, "Amir Ladsgroup" wrote: > On Tue, May 20, 2014 at 5:35 PM, Jon Robson wrote: > > > I'm confused. Why wouldn't you just mark a user account as being a bot > and > > simply determine bot edits from username alone? > > > > Any other mechanism seems prone to abuse or being inaccurate... > > > People gave several examples of bot tasks that needs to be seen in RC and > they weren't abuse > > > > On 20 May 2014 07:36, "Amir Ladsgroup" wrote: > > > > > Thank you legoktm for exampling, > > > Another case that happened in Persian Wikipedia, is creating > > bot-generated > > > articles by user request this task is too contervisal to be marked as > bot > > > and we didn't mark it but other edits of my bot is marked as bot > > > > > > Best > > > > > > > > > On Tue, May 20, 2014 at 11:01 AM, Legoktm > > >wrote: > > > > > > > > > > > On 5/19/14, 6:39 PM, Dan Garry wrote: > > > > > > > >> On 19 May 2014 19:36, Amir Ladsgroup wrote: > > > >> > > > >> As a bot operator I think API parameter about flagging bot or not > is > > > >>> necessary > > > >>> > > > >>> Sure, but as I'm not a bot operator, can you explain why and what > > you > > > >> use > > > >> this for, to help me understand? :-) > > > >> > > > > > > > > If the edits should show up in users watchlists/recentchanges for > > humans > > > > to look at. An example would be ClueBot NG on enwp which doesn't flag > > > it's > > > > edits with the bot flag so humans can review them. > > > > > > > > Another case where this recently came up is in MassMessage (bug > 65180). > > > > Some edits like those to user talk pages should be marked as a bot > > since > > > > the user will receive a notification regardless, but ones that are > made > > > to > > > > Project (or other) namespaces, should not be flagged as bot so users > > will > > > > see them in their watchlists. > > > > > > > > -- Legoktm > > > > > > > > > > > > ___ > > > > Wikitech-l mailing list > > > > Wikitech-l@lists.wikimedia.org > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > > > > > > > > > -- > > > Amir > > > ___ > > > 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 > > > > > > -- > Amir > ___ > 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] Bot flags and human-made edits
On Tue, May 20, 2014 at 5:35 PM, Jon Robson wrote: > I'm confused. Why wouldn't you just mark a user account as being a bot and > simply determine bot edits from username alone? > > Any other mechanism seems prone to abuse or being inaccurate... > People gave several examples of bot tasks that needs to be seen in RC and they weren't abuse > On 20 May 2014 07:36, "Amir Ladsgroup" wrote: > > > Thank you legoktm for exampling, > > Another case that happened in Persian Wikipedia, is creating > bot-generated > > articles by user request this task is too contervisal to be marked as bot > > and we didn't mark it but other edits of my bot is marked as bot > > > > Best > > > > > > On Tue, May 20, 2014 at 11:01 AM, Legoktm > >wrote: > > > > > > > > On 5/19/14, 6:39 PM, Dan Garry wrote: > > > > > >> On 19 May 2014 19:36, Amir Ladsgroup wrote: > > >> > > >> As a bot operator I think API parameter about flagging bot or not is > > >>> necessary > > >>> > > >>> Sure, but as I'm not a bot operator, can you explain why and what > you > > >> use > > >> this for, to help me understand? :-) > > >> > > > > > > If the edits should show up in users watchlists/recentchanges for > humans > > > to look at. An example would be ClueBot NG on enwp which doesn't flag > > it's > > > edits with the bot flag so humans can review them. > > > > > > Another case where this recently came up is in MassMessage (bug 65180). > > > Some edits like those to user talk pages should be marked as a bot > since > > > the user will receive a notification regardless, but ones that are made > > to > > > Project (or other) namespaces, should not be flagged as bot so users > will > > > see them in their watchlists. > > > > > > -- Legoktm > > > > > > > > > ___ > > > Wikitech-l mailing list > > > Wikitech-l@lists.wikimedia.org > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > > > > -- > > Amir > > ___ > > 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 > -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bot flags and human-made edits
Bot flags are only given out to people that are trusted to not abuse it. I'd say this works quite well, because cases of people abusing the fact that the bot flag hides edits from recent changes are almost entirely unheard of. Dan On 20 May 2014 09:05, Jon Robson wrote: > I'm confused. Why wouldn't you just mark a user account as being a bot and > simply determine bot edits from username alone? > > Any other mechanism seems prone to abuse or being inaccurate... > On 20 May 2014 07:36, "Amir Ladsgroup" wrote: > > > Thank you legoktm for exampling, > > Another case that happened in Persian Wikipedia, is creating > bot-generated > > articles by user request this task is too contervisal to be marked as bot > > and we didn't mark it but other edits of my bot is marked as bot > > > > Best > > > > > > On Tue, May 20, 2014 at 11:01 AM, Legoktm > >wrote: > > > > > > > > On 5/19/14, 6:39 PM, Dan Garry wrote: > > > > > >> On 19 May 2014 19:36, Amir Ladsgroup wrote: > > >> > > >> As a bot operator I think API parameter about flagging bot or not is > > >>> necessary > > >>> > > >>> Sure, but as I'm not a bot operator, can you explain why and what > you > > >> use > > >> this for, to help me understand? :-) > > >> > > > > > > If the edits should show up in users watchlists/recentchanges for > humans > > > to look at. An example would be ClueBot NG on enwp which doesn't flag > > it's > > > edits with the bot flag so humans can review them. > > > > > > Another case where this recently came up is in MassMessage (bug 65180). > > > Some edits like those to user talk pages should be marked as a bot > since > > > the user will receive a notification regardless, but ones that are made > > to > > > Project (or other) namespaces, should not be flagged as bot so users > will > > > see them in their watchlists. > > > > > > -- Legoktm > > > > > > > > > ___ > > > Wikitech-l mailing list > > > Wikitech-l@lists.wikimedia.org > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > > > > -- > > Amir > > ___ > > 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 > -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bot flags and human-made edits
I'm confused. Why wouldn't you just mark a user account as being a bot and simply determine bot edits from username alone? Any other mechanism seems prone to abuse or being inaccurate... On 20 May 2014 07:36, "Amir Ladsgroup" wrote: > Thank you legoktm for exampling, > Another case that happened in Persian Wikipedia, is creating bot-generated > articles by user request this task is too contervisal to be marked as bot > and we didn't mark it but other edits of my bot is marked as bot > > Best > > > On Tue, May 20, 2014 at 11:01 AM, Legoktm >wrote: > > > > > On 5/19/14, 6:39 PM, Dan Garry wrote: > > > >> On 19 May 2014 19:36, Amir Ladsgroup wrote: > >> > >> As a bot operator I think API parameter about flagging bot or not is > >>> necessary > >>> > >>> Sure, but as I'm not a bot operator, can you explain why and what you > >> use > >> this for, to help me understand? :-) > >> > > > > If the edits should show up in users watchlists/recentchanges for humans > > to look at. An example would be ClueBot NG on enwp which doesn't flag > it's > > edits with the bot flag so humans can review them. > > > > Another case where this recently came up is in MassMessage (bug 65180). > > Some edits like those to user talk pages should be marked as a bot since > > the user will receive a notification regardless, but ones that are made > to > > Project (or other) namespaces, should not be flagged as bot so users will > > see them in their watchlists. > > > > -- Legoktm > > > > > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > -- > Amir > ___ > 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] Transcluding non-text content as HTML on wikitext pages
Am 19.05.2014 23:05, schrieb Gabriel Wicke: > I think we have agreement that some kind of tag is still needed. The main > point still under discussion is on which tag to use, and how to implement > this tag in the parser. Indeed. > Originally, was conceived to be used in actual page content to > wrap wikitext that is supposed to be parsed to a balanced DOM *as a unit* > rather than transclusion by transclusion. Once unbalanced compound > transclusion content is wrapped in tags (manually or via bots > using Parsoid info), we can start to enforce nesting of all other > transclusions by default. This will make editing safer and more accurate, > and improve performance by letting us reuse expansions and avoid > re-rendering the entire page during refreshLinks. See > https://bugzilla.wikimedia.org/show_bug.cgi?id=55524 for more background. Ah, I though you just pulled that out of your hat :) My main reason for recycling the tag was to not introduce a new tag extension. may occur verbatim in existing wikitext, and would break when the tag is introduces. Other than that, I'm find with outputting whatever tag you like for the transclusion. Implementing the tag is something else, though - I could implement it so it will work for HTML transclusion, but I'm not sure I understand the original domparse stuff well enough to get that right. Would domparse be in core, btw? > Now back to the syntax. Encoding complex transclusions in a HTML parameter > would be rather cumbersome, and would entail a lot of attribute-specific > escaping. Why would it involve any escaping? It should be handled as a tag extension, like any other. > $wgRawHtml is disabled in all wikis we are currently interested in. > MediaWiki does properly report the extension tag from siteinfo when > $wgRawHtml is enabled, so it ought to work with Parsoid for private wikis. > It will be harder to support the transclusion=""> exception. I should try what expandtemplates does with with $wgRawHtml enabled. Nothing, probably. It will just come back containing raw HTML. Which would be fine, I think. By the way: once we agree on a mechanism, it would be trivial to use the same mechanism for special page transclusion. My patch actually already covers that. Do you agree that this is the Right Thing? It's just transclusion of HTML content, after all. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
