[Wikitech-l] Disable module mediawiki.searchSuggest in MW 1.20+
Hi everybody! I'm writing an extension that needs to replace/disable the build-in suggestion feature of the search box. In earlier versions this could be archived by setting $wgEnableMWSuggest (http://www.mediawiki.org/wiki/Manual:$wgEnableMWSuggest) to false. But with 1.20 this option is no longer available. In includes/OutputPage.php:2484 it seems that $wgUseAjax is the only condition (despite of user settings) that is evaluated to decide whether to add the module mediawiki.searchSuggest or not. But I don't want to disable the ajax features completely. ResourceLoader doesn't offer me any hooks or interfaces that would allow my extension to remove the module programmatically. Any hints on this? Thanks in advance! Best regards, Robert Vogel Social Web Technologien Softwareentwicklung Hallo Welt! - Medienwerkstatt GmbH __ Residenzstraße 2 93047 Regensburg Tel. +49 (0) 941 - 66 0 80-198 Fax +49 (0) 941 - 66 0 80-189 www.hallowelt.bizhttp://www.hallowelt.biz/ vo...@hallowelt.bizmailto:vo...@hallowelt.biz Sitz: Regensburg Amtsgericht: Regensburg Handelsregister: HRB 10467 E.USt.Nr.: DE 253050833 Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Željko Filipin presenting at FOSDEM
Hello, On Mon, Jan 14, 2013 at 7:04 PM, Chris McMahon cmcma...@wikimedia.org wrote: Željko Filipin, QA Engineer for WMF, will be giving a presentation at FOSDEM in Brussels Feb 2 about our browser automation project. Congratulations Željko, it looks like a great track to be part of. https://fosdem.org/2013/schedule/track/testing_and_automation/ Congratulations for your talk. It's nice to see a MediaWiki involvement in this conference. -- Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] The ultimate bikeshed: typos in commit messages
Hey, I have observed a difference in opinion between two groups of people on gerrit, which unfortunately is causing bad blood on both sides. I'm therefore interested in hearing your opinion about the following scenario: Someone makes a sound commit. The commit has a clear commit message, though there is a single typo in it. Is it helpful to -1 the commit because of the typo? 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] The ultimate bikeshed: typos in commit messages
On 15/01/13 12:44, Jeroen De Dauw wrote: I have observed a difference in opinion between two groups of people on gerrit, which unfortunately is causing bad blood on both sides. I'm therefore interested in hearing your opinion about the following scenario: Someone makes a sound commit. The commit has a clear commit message, though there is a single typo in it. Is it helpful to -1 the commit because of the typo? This intricate, complex and important question deserves a long and thoughtful answer. In my opinion, if the typo is trivial (f.e. someone typed fo instead of of), there is no need to -1 the commit, however if the typo pertains to a crucial element of the commit (f.e. someone typed fixed wkidata bug) perhaps it should, since otherwise people who search through commit messages won't be able to find commits that contain word wikidata. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
On 15.01.2013 12:44, Jeroen De Dauw wrote: Hey, I have observed a difference in opinion between two groups of people on gerrit, which unfortunately is causing bad blood on both sides. I'm therefore interested in hearing your opinion about the following scenario: Someone makes a sound commit. The commit has a clear commit message, though there is a single typo in it. Is it helpful to -1 the commit because of the typo? Yes, I have noticed the same. My very personal opinion: No, a -1 is not justified because of a typo in a commit message. Doing that just causes a lot of overhead for extremely little benefit. If someone is really bothered by it, they can fix it themselves. It's like reverting a Wikipedia edit because of a type. You don't do that. You fix it or leave it. The only semi-valid argument I have heard in support is that commit messages (may) go into the release notes. But release notes are edited, formatted and spell-checked anyway, and they don't include all commit messages. Not even all tag lines. Personally, if I do a quick fix of a bug I find somewhere, and the fix gets a -1 for a typo in the commit message, I'm tempted to just walk away and let it rot. I'm immature like that I guess... and I'm pretty sure I'm not the only one. -- daniel PS: note that this is about typos. A commit with an incomprehensible or plain wrong commit message should indeed get a -1. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
On 15.01.2013 12:58, Nikola Smolenski wrote: In my opinion, if the typo is trivial (f.e. someone typed fo instead of of), there is no need to -1 the commit, however if the typo pertains to a crucial element of the commit (f.e. someone typed fixed wkidata bug) perhaps it should, since otherwise people who search through commit messages won't be able to find commits that contain word wikidata. Ok, full text search might be an argument in some cases (does that even work on gerrit?). But in that regard, wouldn't it be much more important to enforce (bug 12345) links to bugzilla by giving a -1 to commits that don't have them (though they clearly have, or should have, a bug report?) I'm still in favor of requiring every tag line to contain either (bug n) or (minor), so people are reminded that bugs should be filed and linked for anything that is not trivial. That's not what I want to discuss here - it just strikes me as much more relevant than typos, yet people don't seem to be too keen to enforce that. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to support MediaWiki
On Mon, 14 Jan 2013 08:56:50 -0800, Dmitriy Sintsov ques...@rambler.ru wrote: 14 Январь 2013 г. 19:59:01 пользователь Mark A. Hershberger (m...@everybody.org) написал: On 01/14/2013 01:34 AM, Dmitriy Sintsov wrote: One guess I know that some admins consider newer versions are slower than old ones, do not know how much that is true. Mariya Miteva [[mw:User:Mitevam]] is talking to non-WMF users of MediaWiki and has found that some people are put off by the difficulty of upgrading MediaWiki. For example, many people have put in some effort to modify a skin for their needs only to find gratuitous changes in the core made with (what appears to be) little thought for backwards compatibility. Skins are horrorful part of MediaWiki. They are deliberately made too much low-level to run fast (they probably sample performance). However after upgrade custom skinning could break or miss newly added parts. Daniel Friesen attempted to make skins template-based but I do not think it was accepted into the core. No... I never finished. Said system is still incomplete, in bits, pieces, and documents full of plans. Dmitriy -- ~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] The ultimate bikeshed: typos in commit messages
On Tue, Jan 15, 2013 at 6:44 AM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, I have observed a difference in opinion between two groups of people on gerrit, which unfortunately is causing bad blood on both sides. I'm therefore interested in hearing your opinion about the following scenario: Someone makes a sound commit. The commit has a clear commit message, though there is a single typo in it. Is it helpful to -1 the commit because of the typo? This is a non issue in the very near future. Once we upgrade (testing now, planning for *Very Soon* after eqiad migration), we'll have the ability to edit commit messages and topics directly from the UI. I think this will save people a lot of time downloading/amending changes just to fix typos. Personally, I think all typos should be fixed, since this becomes an immutable part of the history once submitted. But hopefully this will be much easier for people soon :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
Le 15/01/13 12:44, Jeroen De Dauw wrote: I have observed a difference in opinion between two groups of people on gerrit, which unfortunately is causing bad blood on both sides. I'm therefore interested in hearing your opinion about the following scenario: Someone makes a sound commit. The commit has a clear commit message, though there is a single typo in it. Is it helpful to -1 the commit because of the typo? Yup -1 anything that is wrong, even if it is the must trivial error ever encountered. We have a pre commit review workflow exactly for that. If you feel brave enough, you could edit it yourself: - download the change - amend it - sent patchset back - leave a message (fixed typo) - removed yourself from the reviewer list Done :-] I wanted to have a spell checker to lint the commit message, but eventually gave up because of the number of false positives. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Problem to get an article's content in MW 1.20.2
Hi, I'm using MW 1.20.2 and I want to get the content of a page for further parsing in a PHP application. The PHP application is triggered via a special page (Special:MobileKeyV1) and parses nature guides for mobile devices. I tried to get the content via getArticleID() ... $titleObj=Title::newFromText(Existing page); $articleID=$titleObj-getArticleID(); Article::newFromID($articleID)-fetchContent(); etc. ... but it returns $articleID=0 although the page exits. With MW 1.18 this approach worked fine, but after upgrade to MW 1.20.2 it does not any more. How do I get the page content correctly? Article::newFromID($titleObj-getArticleID())-fetchContent(); does not work because getArticleID() returns 0 or -1 although the page exits Or can sombody post a hint, what I'm doing wrong? Is there any context class needed? Or where there some big changes (MW 1.18 → 1.20) that are not described yet on http://www.mediawiki.org/wiki/Manual:Title.php ? I did also a sudo php ./maintenance/rebuildall.php --conf ./LocalSettings.php But it did not help either Thanks for your help! Kind regards Andreas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
I agree with Antoine. Commit messages are part of the permanent history of this project. From now until MediaWiki doesn't exist anymore, anybody can come and look at the change history and the commit messages that go with them. Now you might ask what the possibility is of somebody ever coming across a single commit message that has a typo in it, but when you're using git-blame, git-bisect, or other similar tools, it's very possible. Also, a -1 is not a -2. It won't block the change from being merged; it's just a notification that something needs to be fixed, however minor. I'm still in favor of requiring every tag line to contain either (bug n) or (minor), so people are reminded that bugs should be filed and linked for anything that is not trivial. That's not what I want to discuss here - it just strikes me as much more relevant than typos, yet people don't seem to be too keen to enforce that. I'm not so sure about *every* commit, but I definitely agree that this needs to be enforced more. If you're fixing something or adding a new feature, there should be a bug to go with it. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Jan 15, 2013 at 8:37 AM, Antoine Musso hashar+...@free.fr wrote: Le 15/01/13 12:44, Jeroen De Dauw wrote: I have observed a difference in opinion between two groups of people on gerrit, which unfortunately is causing bad blood on both sides. I'm therefore interested in hearing your opinion about the following scenario: Someone makes a sound commit. The commit has a clear commit message, though there is a single typo in it. Is it helpful to -1 the commit because of the typo? Yup -1 anything that is wrong, even if it is the must trivial error ever encountered. We have a pre commit review workflow exactly for that. If you feel brave enough, you could edit it yourself: - download the change - amend it - sent patchset back - leave a message (fixed typo) - removed yourself from the reviewer list Done :-] I wanted to have a spell checker to lint the commit message, but eventually gave up because of the number of false positives. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problem to get an article's content in MW 1.20.2
Hi Andreas
Try this
$someobj = WikiPage::newFromId( $ID );
if(is_object( $someobj ) ){
$text = $someobj-getRawText(); or you can use $text =
$someobj-getText();
}
else{
return true;
}
Thanks
Harsh
---
Harsh Kothari
Research Fellow,
Physical Research Laboratory(PRL).
Ahmedabad.
On 15-Jan-2013, at 7:14 PM, Andreas Plank wrote:
Hi,
I'm using MW 1.20.2 and I want to get the content of a page for
further parsing in a PHP application. The PHP application is triggered
via a special page (Special:MobileKeyV1) and parses nature guides for
mobile devices.
I tried to get the content via getArticleID() ...
$titleObj=Title::newFromText(Existing page);
$articleID=$titleObj-getArticleID();
Article::newFromID($articleID)-fetchContent();
etc.
... but it returns $articleID=0 although the page exits. With MW 1.18
this approach worked fine, but after upgrade to MW 1.20.2 it does not
any more.
How do I get the page content correctly?
Article::newFromID($titleObj-getArticleID())-fetchContent(); does
not work because getArticleID() returns 0 or -1 although the page
exits
Or can sombody post a hint, what I'm doing wrong? Is there any context
class needed?
Or where there some big changes (MW 1.18 → 1.20) that are not
described yet on http://www.mediawiki.org/wiki/Manual:Title.php ?
I did also a
sudo php ./maintenance/rebuildall.php --conf ./LocalSettings.php
But it did not help either
Thanks for your help!
Kind regards
Andreas
___
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] Problem to get an article's content in MW 1.20.2
I think the best thing to do would be to just avoid getting the article ID
in the first place. If you have a Title object, you can just pass that
object directly to either Article::newFromTitle or to WikiPage::factory.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Tue, Jan 15, 2013 at 9:11 AM, Harsh Kothari harshkothari...@gmail.comwrote:
Hi Andreas
Try this
$someobj = WikiPage::newFromId( $ID );
if(is_object( $someobj ) ){
$text = $someobj-getRawText(); or you can use $text =
$someobj-getText();
}
else{
return true;
}
Thanks
Harsh
---
Harsh Kothari
Research Fellow,
Physical Research Laboratory(PRL).
Ahmedabad.
On 15-Jan-2013, at 7:14 PM, Andreas Plank wrote:
Hi,
I'm using MW 1.20.2 and I want to get the content of a page for
further parsing in a PHP application. The PHP application is triggered
via a special page (Special:MobileKeyV1) and parses nature guides for
mobile devices.
I tried to get the content via getArticleID() ...
$titleObj=Title::newFromText(Existing page);
$articleID=$titleObj-getArticleID();
Article::newFromID($articleID)-fetchContent();
etc.
... but it returns $articleID=0 although the page exits. With MW 1.18
this approach worked fine, but after upgrade to MW 1.20.2 it does not
any more.
How do I get the page content correctly?
Article::newFromID($titleObj-getArticleID())-fetchContent(); does
not work because getArticleID() returns 0 or -1 although the page
exits
Or can sombody post a hint, what I'm doing wrong? Is there any context
class needed?
Or where there some big changes (MW 1.18 → 1.20) that are not
described yet on http://www.mediawiki.org/wiki/Manual:Title.php ?
I did also a
sudo php ./maintenance/rebuildall.php --conf ./LocalSettings.php
But it did not help either
Thanks for your help!
Kind regards
Andreas
___
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
[Wikitech-l] Somebody Explain File Repositories
Hey, Are there any resources that explain how MediaWiki's file repositories work? I've been going through the code, but between the various FileRepo classes and their corresponding File classes, it's way too confusing. I'm trying to make a new FileRepo/File class to allow storage of uploads on a different device. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
On 15.01.2013 15:06, Tyler Romeo wrote: I agree with Antoine. Commit messages are part of the permanent history of this project. From now until MediaWiki doesn't exist anymore, anybody can come and look at the change history and the commit messages that go with them. Now you might ask what the possibility is of somebody ever coming across a single commit message that has a typo in it, but when you're using git-blame, git-bisect, or other similar tools, it's very possible. And then they see a typo. So what? If you look through a mailing list archive or Wikipedia edit comments, you will also see typos. I'm much more concerned about scaring away new contributors with such nitpicking. I'm not so sure about *every* commit, but I definitely agree that this needs to be enforced more. If you're fixing something or adding a new feature, there should be a bug to go with it. Every commit that is not trivial. This would be so much nicer if we had good integration between bug tracker and review system :/ -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
On 15.01.2013 13:39, Chad wrote: This is a non issue in the very near future. Once we upgrade (testing now, planning for *Very Soon* after eqiad migration), we'll have the ability to edit commit messages and topics directly from the UI. I think this will save people a lot of time downloading/amending changes just to fix typos. Oh yes, please! -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
Its not that difficult to read through the text before you commit, right? At least try to remove the most obvious spelling errors. Perhaps I just find to much BS I should have given a -1 or even a -2 in some cases. John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
-- - Brian Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight. On Tue, Jan 15, 2013 at 10:57 AM, Daniel Kinzler dan...@brightbyte.de wrote: On 15.01.2013 15:06, Tyler Romeo wrote: I agree with Antoine. Commit messages are part of the permanent history of this project. From now until MediaWiki doesn't exist anymore, anybody can come and look at the change history and the commit messages that go with them. Now you might ask what the possibility is of somebody ever coming across a single commit message that has a typo in it, but when you're using git-blame, git-bisect, or other similar tools, it's very possible. And then they see a typo. So what? If you look through a mailing list archive or Wikipedia edit comments, you will also see typos. I'm much more concerned about scaring away new contributors with such nitpicking. On the other hand, new users may be attracted to the fact that we have high standards. I agree that spelling is a valid reason for a -1. After all, -1 is not the same as a revert in the svn days, it simply means that the commit is not yet perfect. (Even in svn a revert was supposed to be no big deal). -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problem to get an article's content in MW 1.20.2
While it may be true that there are better methods to call for this
purpose, an article's id should be 0 if and only if it does not exist
(or perhaps if its in a fake namespace like special).
-bawolff
On Tue, Jan 15, 2013 at 10:15 AM, Tyler Romeo tylerro...@gmail.com wrote:
I think the best thing to do would be to just avoid getting the article ID
in the first place. If you have a Title object, you can just pass that
object directly to either Article::newFromTitle or to WikiPage::factory.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Tue, Jan 15, 2013 at 9:11 AM, Harsh Kothari
harshkothari...@gmail.comwrote:
Hi Andreas
Try this
$someobj = WikiPage::newFromId( $ID );
if(is_object( $someobj ) ){
$text = $someobj-getRawText(); or you can use $text =
$someobj-getText();
}
else{
return true;
}
Thanks
Harsh
---
Harsh Kothari
Research Fellow,
Physical Research Laboratory(PRL).
Ahmedabad.
On 15-Jan-2013, at 7:14 PM, Andreas Plank wrote:
Hi,
I'm using MW 1.20.2 and I want to get the content of a page for
further parsing in a PHP application. The PHP application is triggered
via a special page (Special:MobileKeyV1) and parses nature guides for
mobile devices.
I tried to get the content via getArticleID() ...
$titleObj=Title::newFromText(Existing page);
$articleID=$titleObj-getArticleID();
Article::newFromID($articleID)-fetchContent();
etc.
... but it returns $articleID=0 although the page exits. With MW 1.18
this approach worked fine, but after upgrade to MW 1.20.2 it does not
any more.
How do I get the page content correctly?
Article::newFromID($titleObj-getArticleID())-fetchContent(); does
not work because getArticleID() returns 0 or -1 although the page
exits
Or can sombody post a hint, what I'm doing wrong? Is there any context
class needed?
Or where there some big changes (MW 1.18 → 1.20) that are not
described yet on http://www.mediawiki.org/wiki/Manual:Title.php ?
I did also a
sudo php ./maintenance/rebuildall.php --conf ./LocalSettings.php
But it did not help either
Thanks for your help!
Kind regards
Andreas
___
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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Somebody Explain File Repositories
On Tue, Jan 15, 2013 at 10:27 AM, Tyler Romeo tylerro...@gmail.com wrote: Hey, Are there any resources that explain how MediaWiki's file repositories work? I've been going through the code, but between the various FileRepo classes and their corresponding File classes, it's way too confusing. I'm trying to make a new FileRepo/File class to allow storage of uploads on a different device. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Have you read includes/filerepo/README ? Very broadly, filerepo is for stuff generic to the filerepo, and file objects contain info on individual files. Methods on the file objects get called to get info about a specific file, and often those methods call more general methods in the filerepo class to get the needed information out of the repository. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
On Tue, Jan 15, 2013 at 10:05 AM, bawolff bawolff...@gmail.com wrote: On the other hand, new users may be attracted to the fact that we have high standards. I agree that spelling is a valid reason for a -1. After all, -1 is not the same as a revert in the svn days, it simply means that the commit is not yet perfect. (Even in svn a revert was supposed to be no big deal). I would disagree, I think most developers will look for community first. While yes, some wont care that it's full of nitpicky pedants, I think that would turn off more potential developers then would help. Extending this logic, nobody would commit to the Linux kernel tree since it has had fuck and shit committed in revisions. What type of standards is that? I would agree with Daniel above that if it's in a non-critical part of the commit message, if it bothers you that much, then follow it up yourself. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to support MediaWiki
On 01/15/2013 07:25 AM, Daniel Friesen wrote: Daniel Friesen attempted to make skins template-based but I do not think it was accepted into the core. No... I never finished. Said system is still incomplete, in bits, pieces, and documents full of plans. Where is your current work? This is one of the most obvious pain point for many users. Would you be interested in getting some help with this? -- http://hexmode.com/ Language will always shift from day to day. It is the wind blowing through our mouths. -- http://hexm.de/np ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
Daniel Kinzler dan...@brightbyte.de wrote: In my opinion, if the typo is trivial (f.e. someone typed fo instead of of), there is no need to -1 the commit, however if the typo pertains to a crucial element of the commit (f.e. someone typed fixed wkidata bug) perhaps it should, since otherwise people who search through commit messages won't be able to find commits that contain word wikidata. Ok, full text search might be an argument in some cases (does that even work on gerrit?). It works in Git, for example with git log --grep. I do think that fixing typos should be preferred to preserving typos for eternity, and -1 is better than nothing, but up- loading a new changeset is how it should be done. But in that regard, wouldn't it be much more important to enforce (bug 12345) links to bugzilla by giving a -1 to commits that don't have them (though they clearly have, or should have, a bug report?) I'm still in favor of requiring every tag line to contain either (bug n) or (minor), so people are reminded that bugs should be filed and linked for anything that is not trivial. That's not what I want to discuss here - it just strikes me as much more relevant than typos, yet people don't seem to be too keen to enforce that. I cannot follow that line of thought at all. The tag line is rather short and should give the reader a summary of what the commit is about when browsing through a list of commits. Reserving part of that for a bug number would only be useful if the reader could associate the underlying issue by the number, but apart from bug #1 and a few (other) tracking bugs noone will be able to do so, and those bugs will (un- fortunately) never be closed. Is there another software project that uses the summary line in a similar way to MediaWiki? Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problem to get an article's content in MW 1.20.2
That is true. Also if it's interwiki.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Tue, Jan 15, 2013 at 11:12 AM, bawolff bawolff...@gmail.com wrote:
While it may be true that there are better methods to call for this
purpose, an article's id should be 0 if and only if it does not exist
(or perhaps if its in a fake namespace like special).
-bawolff
On Tue, Jan 15, 2013 at 10:15 AM, Tyler Romeo tylerro...@gmail.com
wrote:
I think the best thing to do would be to just avoid getting the article
ID
in the first place. If you have a Title object, you can just pass that
object directly to either Article::newFromTitle or to WikiPage::factory.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Tue, Jan 15, 2013 at 9:11 AM, Harsh Kothari
harshkothari...@gmail.comwrote:
Hi Andreas
Try this
$someobj = WikiPage::newFromId( $ID );
if(is_object( $someobj ) ){
$text = $someobj-getRawText(); or you can use $text =
$someobj-getText();
}
else{
return true;
}
Thanks
Harsh
---
Harsh Kothari
Research Fellow,
Physical Research Laboratory(PRL).
Ahmedabad.
On 15-Jan-2013, at 7:14 PM, Andreas Plank wrote:
Hi,
I'm using MW 1.20.2 and I want to get the content of a page for
further parsing in a PHP application. The PHP application is triggered
via a special page (Special:MobileKeyV1) and parses nature guides for
mobile devices.
I tried to get the content via getArticleID() ...
$titleObj=Title::newFromText(Existing page);
$articleID=$titleObj-getArticleID();
Article::newFromID($articleID)-fetchContent();
etc.
... but it returns $articleID=0 although the page exits. With MW 1.18
this approach worked fine, but after upgrade to MW 1.20.2 it does not
any more.
How do I get the page content correctly?
Article::newFromID($titleObj-getArticleID())-fetchContent(); does
not work because getArticleID() returns 0 or -1 although the page
exits
Or can sombody post a hint, what I'm doing wrong? Is there any context
class needed?
Or where there some big changes (MW 1.18 → 1.20) that are not
described yet on http://www.mediawiki.org/wiki/Manual:Title.php ?
I did also a
sudo php ./maintenance/rebuildall.php --conf ./LocalSettings.php
But it did not help either
Thanks for your help!
Kind regards
Andreas
___
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
___
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] The ultimate bikeshed: typos in commit messages
On Tue, Jan 15, 2013 at 11:44 AM, Tim Landscheidt t...@tim-landscheidt.de wrote: Daniel Kinzler dan...@brightbyte.de wrote: In my opinion, if the typo is trivial (f.e. someone typed fo instead of of), there is no need to -1 the commit, however if the typo pertains to a crucial element of the commit (f.e. someone typed fixed wkidata bug) perhaps it should, since otherwise people who search through commit messages won't be able to find commits that contain word wikidata. Ok, full text search might be an argument in some cases (does that even work on gerrit?). It works in Git, for example with git log --grep. I do think that fixing typos should be preferred to preserving typos for eternity, and -1 is better than nothing, but up- loading a new changeset is how it should be done. But in that regard, wouldn't it be much more important to enforce (bug 12345) links to bugzilla by giving a -1 to commits that don't have them (though they clearly have, or should have, a bug report?) I'm still in favor of requiring every tag line to contain either (bug n) or (minor), so people are reminded that bugs should be filed and linked for anything that is not trivial. That's not what I want to discuss here - it just strikes me as much more relevant than typos, yet people don't seem to be too keen to enforce that. I cannot follow that line of thought at all. The tag line is rather short and should give the reader a summary of what the commit is about when browsing through a list of commits. Reserving part of that for a bug number would only be useful if the reader could associate the underlying issue by the number, but apart from bug #1 and a few (other) tracking bugs noone will be able to do so, and those bugs will (un- fortunately) never be closed. Is there another software project that uses the summary line in a similar way to MediaWiki? Really, we should be using them in the footer so gerrit can track them. Eg: === Some awesome new feature Blah blah blah I did stuff Fixed this too. Bug: 1234 Change-Id: I === -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Somebody Explain File Repositories
I just read it over. The only frustrating thing is trying to figure out which of the approximately 100 functions in the File class need to be overloaded and then which of the 100 additional functions in FileRepo need to be overloaded. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Jan 15, 2013 at 11:19 AM, bawolff bawolff...@gmail.com wrote: On Tue, Jan 15, 2013 at 10:27 AM, Tyler Romeo tylerro...@gmail.com wrote: Hey, Are there any resources that explain how MediaWiki's file repositories work? I've been going through the code, but between the various FileRepo classes and their corresponding File classes, it's way too confusing. I'm trying to make a new FileRepo/File class to allow storage of uploads on a different device. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Have you read includes/filerepo/README ? Very broadly, filerepo is for stuff generic to the filerepo, and file objects contain info on individual files. Methods on the file objects get called to get info about a specific file, and often those methods call more general methods in the filerepo class to get the needed information out of the repository. -bawolff ___ 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] Somebody Explain File Repositories
Actually, not I'm not even sure whether I should be overriding File or FileRepo, because in reality all the storage happens in FileBackend. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Jan 15, 2013 at 11:54 AM, Tyler Romeo tylerro...@gmail.com wrote: I just read it over. The only frustrating thing is trying to figure out which of the approximately 100 functions in the File class need to be overloaded and then which of the 100 additional functions in FileRepo need to be overloaded. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Jan 15, 2013 at 11:19 AM, bawolff bawolff...@gmail.com wrote: On Tue, Jan 15, 2013 at 10:27 AM, Tyler Romeo tylerro...@gmail.com wrote: Hey, Are there any resources that explain how MediaWiki's file repositories work? I've been going through the code, but between the various FileRepo classes and their corresponding File classes, it's way too confusing. I'm trying to make a new FileRepo/File class to allow storage of uploads on a different device. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Have you read includes/filerepo/README ? Very broadly, filerepo is for stuff generic to the filerepo, and file objects contain info on individual files. Methods on the file objects get called to get info about a specific file, and often those methods call more general methods in the filerepo class to get the needed information out of the repository. -bawolff ___ 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] revamped/updated QA docs on mediawiki.org
On 01/04/2013 02:33 PM, Chris McMahon wrote: I've sorted, linked, tagged, organized, and gardened our collection of QA pages on mw.o to be more useful. Of course there is always more to do, so comments, criticism, edits are welcome. http://www.mediawiki.org/wiki/QA In the past days I went a mile (or two) further. I think we have a good structure of pages under QA now. What is missing are more specific calls to action for contributors and polishing some pages. Even inside the WMF teams we are having difficulties to nail down tasks for contributors and testing sprints. Coincidence? Surely not. We _just_ need better coordination beyond our own little projects and teams, and better collaboration with e.g. extensions developers craving for testing and feedback. Currently we have guidelines to be a good contributor in Features testing and Browser testing. What we miss are specific projects that need help right now. Otherwise potential contributors hesitate choosing a project or fear the risk of working in something already done somewhere. In order to fix this we need the involvement from the projects (WMF or not). Probably related to this there is the fact that different teams have different pages for testing QA e.g. http://www.mediawiki.org/wiki/Mobile_QA http://www.mediawiki.org/wiki/Echo_%28Notifications%29/Testing and even pages in Wikipedia or Meta. You can help at least making sure that those pages are connected to the QA umbrella. fyi this is how QA is structured now: http://www.mediawiki.org/wiki/QA http://www.mediawiki.org/wiki/QA/Features_testing --- http://www.mediawiki.org/wiki/Groups/Proposals/Features_testing http://www.mediawiki.org/wiki/QA/Browser_testing http://www.mediawiki.org/wiki/QA/Browser_testing/How_to_contribute http://www.mediawiki.org/wiki/QA/Browser_testing/Running_tests http://www.mediawiki.org/wiki/QA/Browser_testing/Test_backlog --- http://www.mediawiki.org/wiki/Groups/Proposals/Browser_testing http://www.mediawiki.org/wiki/QA_and_testing/status http://www.mediawiki.org/wiki/QA/Strategy (needs polishing) http://www.mediawiki.org/wiki/QA/Roadmap (needs polishing) Feedback and help is welcome. -- Quim Gil Technical Contributor Coordinator @ 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] Fwd: Deployment freeze during Eqiad migration week (and deployments next week)
I am scheduled to do a deployment (to all wikis) for MobileFrontend this Thursday afternoon: * I presume scap/sync-blah will still work for 1.21wmf7 - can you please confirm? * Will I *have* to use git-deploy for 1.21wmf8 or will scap/sync-blah still work? And to reiterate my question from a few days ago re the deployment freeze next week: * During the 'deployment freeze', in the event that someone needs to deploy an emergency fix, what do we do and who do we need to communicate with? Will scap/deploy-whatever still be functional, or will gti-deploy be the de-facto deployment method at that point? On Mon, Jan 14, 2013 at 6:51 PM, Techman224 techman...@techman224.cawrote: On the date you plan to deploy 1.21wmf8 to test, test2, and mediawiki; do you also plan on deploying it to Wikidata with them or with the other non-Wikipedias? Techman224 On 2013-01-14, at 7:26 PM, Rob Lanphier ro...@wikimedia.org wrote: Hi everyone, As you probably read from CT's email last week about the Eqiad migration (you read that, right? No? Go read it. I'll wait) Ok, done now? So, as you know (now), we plan to suspend all scheduled deployments next week during the data center migration (January 21-25). We'd like to keep the number of moving parts to a minimum, thus we'd like to avoid changing anything unless necessary. That said, we are contemplating leaving the Wednesday window for 1.21wmf8 to non-Wikipedia in place as a means of testing deployments themselves. Unlike previous core deployments (which are pretty routine), we're reserving the right not to have that deployment, and may delay the already-revised deployment calendar one more week if things are still messy on Wednesday. I'm guessing that the odds of that deployment happen are pretty low (I'll say 20% based on aerial extraction). So, to reiterate the plan with respect to deployments over the next couple of weeks: January 14-15 (Mon-Tue): deployments from fenari to Tampa cluster using scap/sync-file/sync-dir as normal. January 16 (Wed): 1.21wmf8 deployed to test, test2, and mediawiki.org January 16-18 (Wed-Fri): 1.21wmf8 deployments using git-deploy from fenari January 17 (Thu): Brown bag with Ryan Lane and Chris Steipp to talk about git-deploy January 21 (Mon): Deployment freeze (and U.S. holiday) January 22-25 (Tue-Fri): Deployment freeze January 23 (Wed): MAYBE 1.21wmf8 deployment to some or all non-Wikipedia sites. I hope this all makes sense. Questions/comments/concerns? Rob ___ 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 -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Welcome, Munagala Ramanath (Ram)
Hi everyone, I’m delighted to introduce Munagala Ramanath (a.k.a. “Ram”), who started yesterday as a Senior Software Engineer in our Platform Engineering group (MediaWiki Core, specifically). He comes to us most recently from a small company called Oblong Industries, where he was responsible for build and distribution tools. However, he’s done a lot of other development work, including working for EMC, Sun, many startups, and several years teaching university computer science courses. Ram also has a PhD in Computer Science from University of Wisconsin, Madison. Ram’s primary development experience has been in C, C++ and Java, which are areas that we haven’t had many people to help out in. His first challenge will be to make the processes that power our “Search” box more robust. Over time, he’ll get more involved in architectural work on our back-end systems generally. Ram will be working from his home in Sierra Madre, CA (near Los Angeles), but will be in the San Francisco office from time-to-time (like now!). Eventually, he plans to relocate to San Francisco to work from our office here. Ram's email is r...@wikimedia.org and his IRC handle is xyzram Please join me in welcoming Ram! Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Munagala Ramanath (Ram)
Welcome, Ram! J. On 15 January 2013 12:08, Rob Lanphier ro...@wikimedia.org wrote: Hi everyone, I’m delighted to introduce Munagala Ramanath (a.k.a. “Ram”), who started yesterday as a Senior Software Engineer in our Platform Engineering group (MediaWiki Core, specifically). He comes to us most recently from a small company called Oblong Industries, where he was responsible for build and distribution tools. However, he’s done a lot of other development work, including working for EMC, Sun, many startups, and several years teaching university computer science courses. Ram also has a PhD in Computer Science from University of Wisconsin, Madison. Ram’s primary development experience has been in C, C++ and Java, which are areas that we haven’t had many people to help out in. His first challenge will be to make the processes that power our “Search” box more robust. Over time, he’ll get more involved in architectural work on our back-end systems generally. Ram will be working from his home in Sierra Madre, CA (near Los Angeles), but will be in the San Francisco office from time-to-time (like now!). Eventually, he plans to relocate to San Francisco to work from our office here. Ram's email is r...@wikimedia.org and his IRC handle is xyzram Please join me in welcoming Ram! Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Munagala Ramanath (Ram)
Ram also has a PhD in Computer Science from University of Wisconsin, Madison. Welcome Ram, and small world ... I got my PhD in CS from UW, Madison as well! Have to share notes about UW, and Madison sometime. :) Subbu. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Munagala Ramanath (Ram)
Please join me in welcoming Ram! Rob It's always good to get more ram! :) Welcome! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
Well, I would prefer to get a notice that I made a typo than having that embarrassing typo in the commit log forever. That's the point of using a gating system, right? :) So yes, I do think they should be corrected. (And I have committed typos in both commit messages and inside files, just as anyone else) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Munagala Ramanath (Ram)
Welcome Ram! On Tue, Jan 15, 2013 at 2:00 PM, Platonides platoni...@gmail.com wrote: Please join me in welcoming Ram! Rob It's always good to get more ram! :) Welcome! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problem to get an article's content in MW 1.20.2
On 15/01/13 14:44, Andreas Plank wrote: Hi, I'm using MW 1.20.2 and I want to get the content of a page for further parsing in a PHP application. The PHP application is triggered via a special page (Special:MobileKeyV1) and parses nature guides for mobile devices. I tried to get the content via getArticleID() ... $titleObj=Title::newFromText(Existing page); $articleID=$titleObj-getArticleID(); Article::newFromID($articleID)-fetchContent(); etc. ... but it returns $articleID=0 although the page exits. With MW 1.18 this approach worked fine, but after upgrade to MW 1.20.2 it does not any more. It should be working, and it works for me on 1.20.2 Can you provide more details on that $title-getArticleID(); which is not working? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Deployment freeze during Eqiad migration week (and deployments next week)
Hi Arthur, Sorry for the delayed reply. Comments below: On Tue, Jan 15, 2013 at 12:07 PM, Arthur Richards aricha...@wikimedia.org wrote: I am scheduled to do a deployment (to all wikis) for MobileFrontend this Thursday afternoon: * I presume scap/sync-blah will still work for 1.21wmf7 - can you please confirm? After tomorrow's deployment, assuming it goes well, it's going to be all git-deploy, all the time, and scap/sync-file will go away. * Will I *have* to use git-deploy for 1.21wmf8 or will scap/sync-blah still work? You'll need to use git-deploy. And to reiterate my question from a few days ago re the deployment freeze next week: * During the 'deployment freeze', in the event that someone needs to deploy an emergency fix, what do we do and who do we need to communicate with? Use #wikimedia-operations. If no one is around, and it is an emergency, go ahead and make the fix, and note it in the logs. Will scap/deploy-whatever still be functional, or will gti-deploy be the de-facto deployment method at that point? git-deploy is going to be it. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Munagala Ramanath (Ram)
On 01/15/2013 03:08 PM, Rob Lanphier wrote: Hi everyone, I’m delighted to introduce Munagala Ramanath (a.k.a. “Ram”), who started yesterday as a Senior Software Engineer in our Platform Engineering group (MediaWiki Core, specifically). Welcome, Ram! I look forward to working with you. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Disambiguation features: Do they belong in core or in an extension?
Back in December, there was discussion about needing a better method of identifying disambiguation pages programmatically (bug 6754). I wrote some core code to accomplish this, but was informed that disambiguation functions should reside in extensions rather than in core, per bug 35981. I abandoned the core code and wrote an extension instead (https://gerrit.wikimedia.org/r/#/c/41043/). Now, however, it has been suggested that this code needs to reside in core after all (https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated#Extension:Disambiguator). Personally, I don't mind implementing it either way, but would like to have consensus on where this code should reside. The code is pretty clean and lightweight, so it wouldn't increase the footprint of core MediaWiki (it would actually decrease the existing footprint slightly since it replaces more hacky existing core code). So core bloat isn't really an issue. The issue is: Where does it most make sense for disambiguation features to reside? Should disambiguation pages be supported out of the box or require an extension to fully support? The specific disambiguation features I'm talking about are: 1. Make it easy to identify disambiguation pages via a page property in the database (set by a templated magic word) 2. Provide a special page (and corresponding API) for seeing what pages are linking to disambiguation pages 3. Assign a unique class to disambiguation links so that gadgets can allow them to be uniquely colored or have special UI (not yet implemented) Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disambiguation features: Do they belong in core or in an extension?
To me disambiguation seems like a common problem of wikis and thus should be a core feature. On a wiki about people, people share the same name On a wiki about cities, cities share the same name etc etc you get the idea. On Tue, Jan 15, 2013 at 5:58 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Back in December, there was discussion about needing a better method of identifying disambiguation pages programmatically (bug 6754). I wrote some core code to accomplish this, but was informed that disambiguation functions should reside in extensions rather than in core, per bug 35981. I abandoned the core code and wrote an extension instead (https://gerrit.wikimedia.org/r/#/c/41043/). Now, however, it has been suggested that this code needs to reside in core after all (https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated#Extension:Disambiguator). Personally, I don't mind implementing it either way, but would like to have consensus on where this code should reside. The code is pretty clean and lightweight, so it wouldn't increase the footprint of core MediaWiki (it would actually decrease the existing footprint slightly since it replaces more hacky existing core code). So core bloat isn't really an issue. The issue is: Where does it most make sense for disambiguation features to reside? Should disambiguation pages be supported out of the box or require an extension to fully support? The specific disambiguation features I'm talking about are: 1. Make it easy to identify disambiguation pages via a page property in the database (set by a templated magic word) 2. Provide a special page (and corresponding API) for seeing what pages are linking to disambiguation pages 3. Assign a unique class to disambiguation links so that gadgets can allow them to be uniquely colored or have special UI (not yet implemented) Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disambiguation features: Do they belong in core or in an extension?
On Tue, Jan 15, 2013 at 8:58 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Personally, I don't mind implementing it either way, but would like to have consensus on where this code should reside. The code is pretty clean and lightweight, so it wouldn't increase the footprint of core MediaWiki (it would actually decrease the existing footprint slightly since it replaces more hacky existing core code). So core bloat isn't really an issue. The issue is: Where does it most make sense for disambiguation features to reside? Should disambiguation pages be supported out of the box or require an extension to fully support? I'd say extension. I can think of lots of wikis that don't use disambiguation pages. If we really want, we can stash it in the default tarball along with the other bundled extensions. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Munagala Ramanath (Ram)
On Tue, Jan 15, 2013 at 12:08 PM, Rob Lanphier ro...@wikimedia.org wrote: started yesterday as a Senior Software Engineer in our Platform Engineering group (MediaWiki Core, specifically). Welcome on-board, Ram :-). Look forward to your efforts on search, which is in desperate need of love and attention. ;) Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disambiguation features: Do they belong in core or in an extension?
I agree with extension. For example, my school's IT department uses a wiki to collect information about common computer problems, and on a wiki about computer problems, none of the issues share the same name. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Jan 15, 2013 at 9:38 PM, Chad innocentkil...@gmail.com wrote: On Tue, Jan 15, 2013 at 8:58 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Personally, I don't mind implementing it either way, but would like to have consensus on where this code should reside. The code is pretty clean and lightweight, so it wouldn't increase the footprint of core MediaWiki (it would actually decrease the existing footprint slightly since it replaces more hacky existing core code). So core bloat isn't really an issue. The issue is: Where does it most make sense for disambiguation features to reside? Should disambiguation pages be supported out of the box or require an extension to fully support? I'd say extension. I can think of lots of wikis that don't use disambiguation pages. If we really want, we can stash it in the default tarball along with the other bundled extensions. -Chad ___ 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] Somebody Explain File Repositories
A File object represents the thing that the user uploads to MediaWiki. It has metadata, a description page, archived versions and thumbnails. FileBackend deals with storing individual archived versions, thumbnails, etc. on disk or in remote storage. It can be plugged into any FileRepo or even unrelated projects such as the Math extension to provide file storage. If you want to know what functions to override, study an existing subclass that does something similar to what you want to do. For example: * ForeignDBViaLBRepo: used by Wikipedia etc. to get images from Wikimedia Commons * ForeignAPIRepo: supports the InstantCommons feature * SwiftFileBackend: support storage of image originals and thumbnails in Swift http://swift.openstack.org/. On 16/01/13 04:08, Tyler Romeo wrote: Actually, not I'm not even sure whether I should be overriding File or FileRepo, because in reality all the storage happens in FileBackend. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Jan 15, 2013 at 11:54 AM, Tyler Romeo tylerro...@gmail.com wrote: I just read it over. The only frustrating thing is trying to figure out which of the approximately 100 functions in the File class need to be overloaded and then which of the 100 additional functions in FileRepo need to be overloaded. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Jan 15, 2013 at 11:19 AM, bawolff bawolff...@gmail.com wrote: On Tue, Jan 15, 2013 at 10:27 AM, Tyler Romeo tylerro...@gmail.com wrote: Hey, Are there any resources that explain how MediaWiki's file repositories work? I've been going through the code, but between the various FileRepo classes and their corresponding File classes, it's way too confusing. I'm trying to make a new FileRepo/File class to allow storage of uploads on a different device. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Have you read includes/filerepo/README ? Very broadly, filerepo is for stuff generic to the filerepo, and file objects contain info on individual files. Methods on the file objects get called to get info about a specific file, and often those methods call more general methods in the filerepo class to get the needed information out of the repository. -bawolff ___ 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] The ultimate bikeshed: typos in commit messages
On 16/01/13 01:57, Daniel Kinzler wrote: On 15.01.2013 15:06, Tyler Romeo wrote: I agree with Antoine. Commit messages are part of the permanent history of this project. From now until MediaWiki doesn't exist anymore, anybody can come and look at the change history and the commit messages that go with them. Now you might ask what the possibility is of somebody ever coming across a single commit message that has a typo in it, but when you're using git-blame, git-bisect, or other similar tools, it's very possible. And then they see a typo. So what? If you look through a mailing list archive or Wikipedia edit comments, you will also see typos. I'm much more concerned about scaring away new contributors with such nitpicking. I am also concerned about demotivating people. Giving a change -1 means that you are asking the developer to take orders from you, under threat of having their work ignored forever. A -1 status can cause a change to be ignored by other reviewers, regardless of its merit. If the developer can't lower their sense of pride sufficiently to allow them to engage with nitpickers, then the change might be ignored by all concerned for many months. However, if you give minor negative feedback with +0, the change stays bold in your review requests list, as if you haven't reviewed it at all. I've tried giving -1 with a comment to the effect of please merge this immediately regardless of my nitpicking above, but IIRC the comment was ignored. I think people who give -1 should be aware of the potential roadblock they are creating. And I would like to see a feature in Gerrit to unbold +0 reviews. Under Subversion, my policy as a reviewer was to never ask the committer to fix a typo in a comment, since committing the fix myself was easier than telling them what to fix, and doing so avoided offence. Under Gerrit, it's more difficult to submit amendments, and I hate multi-author patchsets anyway, so negative feedback seems more attractive. Maybe the answer is better scripting for amendments and dependent commits. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
On 01/15/2013 06:58 AM, Nikola Smolenski wrote: In my opinion, if the typo is trivial (f.e. someone typed fo instead of of), there is no need to -1 the commit, however if the typo pertains to a crucial element of the commit (f.e. someone typed fixed wkidata bug) perhaps it should, since otherwise people who search through commit messages won't be able to find commits that contain word wikidata. I agree. Well said. A minor mistake like that that doesn't affect grepping isn't worth a -1, since it doesn't affect the readability of the code itself. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] WikiEditor-like functionality in the VisualEditor age
Hi, The Visual Editor is growing. One of the things that it's going to replace in one way or another is WikiEditor's toolbars. Some WikiEditor features are already built into VE, for example links and bold font. Some core WikiEditor features should be there some day: search and replace, special characters insertion, citation adding. And finally, many wikis built their own custom features: * many wikis added buttons and drop down menus for inserting Math, Templates and useful HTML tags * English Wikipedia added RefToolbar * some Wikipedias added buttons that make automatic spelling fixes in the wikitext Is there any clever plan for porting these features to the Visual Editor age? Or will they have to be redone entirely? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
