[MediaWiki-CodeReview] [MediaWiki r111798]: New comment added
Nikerabbit posted a comment on MediaWiki.r111798. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111798#c31193 Commit summary for MediaWiki.r111798: Revert r97042, causes bug 34432 Nikerabbit's comment: Chrome is buggy as hell, I just reported http://code.google.com/p/chromium/issues/detail?id=114336 few days ago. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111693]: New comment added
Nikerabbit posted a comment on MediaWiki.r111693. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111693#c31194 Commit summary for MediaWiki.r111693: followup to -r111692 - wrap long line Nikerabbit's comment: We don't usually do that, but if you do you should use the same amount of tabs as the line above and do the rest with spaces. Anything else will not align properly for everyone at the same time, as you can see from above diff. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111354]: New comment added
Nikerabbit posted a comment on MediaWiki.r111354. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111354#c31195 Commit summary for MediaWiki.r111354: getSkin is deprecated Nikerabbit's comment: This code is only for BC for some releases, after which it will be dropped. Doesn't seem worth it to spend more time on that than needed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111800]: New comment added
Nikerabbit posted a comment on MediaWiki.r111800. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111800#c31196 Commit summary for MediaWiki.r111800: Add both size *and* size difference on history page per bug 34449 Nikerabbit's comment: The total size was already in the tooltip of the change size. I think that history page is already cluttered enough and we should try to make clearer, not more cluttered. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111809]: New comment added
Nikerabbit posted a comment on MediaWiki.r111809. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111809#c31197 Commit summary for MediaWiki.r111809: Add missing dependency of mediawiki.user to mediawiki.api.watch. May resolve some of bug 34450 Nikerabbit's comment: Does not follow style wrt spaces around parenthesis. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Please test Javascript on meta.wikimedia.org
On 18 February 2012 00:02, Erik Moeller e...@wikimedia.org wrote: On Fri, Feb 17, 2012 at 1:25 PM, Rob Lanphier ro...@wikimedia.org wrote: Yesterday, Roan and others made some fixes in this area in an attempt to address the problems we were seeing. Here's a list of Roan's commits: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/catrope In an effort to fix things, he enabled $wgResourceLoaderExperimentalAsyncLoading for logged-in users our 1.19 wikis. meta.wikimedia.org is where we've seen the most problems, so that would be the best place to test. This is interesting, because I saw similar behavior on translatawiki.net when that option was *enabled* and the problems went away when I disabled that option. In addition to issues already mentioned, it caused some tests to fail consistently in certain conditions - mentioned in the bug https://bugzilla.wikimedia.org/show_bug.cgi?id=33903 -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git + Gerrit is a toughy
On Sat, Feb 18, 2012 at 2:47 AM, Andrew Otto o...@wikimedia.org wrote: 2. Do I need to rebase every time I push for review? I don't quite understand what is going on here. I've installed git-review and am using this to push to git. It does a rebase by default. I'm not sure if I should be turning that off or not. Rebases seem like a bad idea unless you really need to do them. I think git-review is doing a rebase by default so it can squash all of your local commits into one big review commit before pushing. Yuck! This would surely mean fewer commits to review in Gerrit, but it destroys real the history. It is making git work more like subversion, where you just work locally until everything is good and then have one big commit. I should be able to commit often and be able to share my commits with other developers before having everything reviewed. Yes, you need to rebase before you push. The rebase does not exist to squash multiple commits into one, but to ensure that your commit can be merged cleanly. This fits the gated trunk model, but it looks like you don't necessarily want to gate your working branch at all, just your master. IMO you should ask Ryan to set up direct push access for your working branches, so you can just git push into them directly, bypassing review. You can then merge your branch into master, and submit that merge commit for review. 3. How does Gerrit handle merges? Do all merge commits need to be re-approved? Yes. 4. What should I do in the following situation? I have a branch I recently made from master. I've made some changes and pushed them to gerrit. My changes have been approved. Now I want to sync master into my branch. I do git merge master Why did you merge master into your branch, rather than merging your branch into master? That doesn't make much sense to me. Then resolve any conflicts and commit. How should I push these changes? The commits that make up the merge have already been approved in gerrit on the master branch. Do I need to push for review using git-review? They've already been approved, so I would think not. But gerrit will currently not allow me to push without using git-review (is that because the commits need a Change-Id?). Yes, you need to submit the merge commit for review. If some commits don't have a Change-Id, git-review can't submit them, but I don't see how that could be the case. You said the commits were already approved in gerrit, *and* they don't have a Change-Id? Those things can't both be true. Since gerrit doesn't let me do a regular git push to push my master merge to the remote branch I am tracking, I do git-review. Perhaps you should ask for regular pushes to be allowed if you're not using the review workflow for that branch, see also above. This does rebase by default, so for some reason I am stuck having to resolve every single commit that was made to master in order to get the merge to push. This takes quite a while, but I did it, and once the interactive rebase was finished I was able to git-review to push the merge from master. Great. Now I that my branch is in sync with master again, I want to merge it into master. git checkout master git merge my_branch All good. Then what? Since I can't do just 'git push', I try git-review again. The same thing happens. I have to run through the whole interactive rebase routine and resolve each of my commits from my_branch manually. I do that, then run 'git-review' again. Now I get this error message: remote: Hint: A potential Change-Id was found, but it was not in the footer of the commit message. To ssh://o...@gerrit.wikimedia.org:29418/analytics/reportcard.git ! [remote rejected] HEAD - refs/for/master/master (missing Change-Id in commit message) error: failed to push some refs to 'ssh://o...@gerrit.wikimedia.org:29418/analytics/reportcard.git' Each of the commits I merged from my_branch come with their own Change-Id in the commit messages. But these commits are now merge commits (I think?), so they have information about the merge and any conflicts in the commit message below the original Change-Id. I think this is confusing Gerrit, because it doesn't see the Change-Id in the footer. There is a bug in git that causes merge commits to not automatically get Change-IDs. After generating a merge commit, you need to run git commit --amend , then save without changing anything. That makes sure the commit-msg hook is run and the Change-ID is appended. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111439]: New comment added
GWicke posted a comment on MediaWiki.r111439. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111439#c31198 Commit summary for MediaWiki.r111439: Introduce property: and itemprop: support for addMeta to add RDFa meta property=... content=... and Microdata meta itemprop=... content=... to the head. This is done in a way that can also be feature tested, and technically could be expanded by extensions. GWicke's comment: For WebPage, that definitely makes more sense. The only trouble I see with the global scope is that stray itemprops in the content would end up in the outermost itemscope. But that should be fixable in the parser. I am still not that happy with the need to use an extra hook to avoid producing invalid microdata. Some of the WebPage schema data would be naturally added in the skin (mainContentOfPage for example), so it might make sense to add this itemtype and itemscope on the html element in the skin as well. Header itemprops from other itemtypes could still be added using absolute URLs in itemprop names. If we allow users to replace the itemtype on the html element arbitrarily, then we could not use something like WebPage to mark up parts of the page in the skin- at least not without using absolute URLs throughout. Afaik right now search engine crawlers don't yet use itemprops with absolute URLs, but I guess that might change (hopefully also in the HTML spec) once mixing multiple itemtypes becomes more common. Until then, we have to decide if something like WebPage or an arbitrary user itemtype should take precedence. I would vote for a static itemtype like WebPage, as it covers most of the metadata already published with pages. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111765]: Revision status changed
Hashar changed the status of MediaWiki.r111765 to reverted URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111765 Old status: fixme New status: reverted Commit summary for MediaWiki.r111765: (bug 34421) avoid duplicate Subject headers r93397 duplicated the Subject header which was passed to the mail() function as well as to the $headers array. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111378]: New comment added
Catrope posted a comment on MediaWiki.r111378.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111378#c31199
Commit summary for MediaWiki.r111378:
[RL] Comment mod and other minor changes
_ Add comment about why it casts to (object)
- Modify function comment
- Whitespace (start the function body on a new line in debug mode. In
production mode this is trimmed away afterwards)
- Remove the jQuery-$ passage from loader. There is already a global alias for
$ by jQuery, and aside from that every module has it's own (function(){})
wrapper that aliases it from jQuery (not from $), so there is no performance
gain either by having it locally here since it doesn't use that.
Catrope's comment:
See e.g. bug 33903
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Please test Javascript on meta.wikimedia.org
On Fri, Feb 17, 2012 at 20:02, Erik Moeller e...@wikimedia.org wrote: being displayed as expanded, but being actually collapsed). I also still see the issue of occasional flashes of the pre-Vector toolbar. Is this the same which was reported on the following topic? http://labs.wikimedia.beta.wmflabs.org/wiki/Problem_reports#Old_toolbar_is_displayed_before_the_enhanced_toolbar_is_loaded ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111272]: New comment added, and revision status changed
Siebrand changed the status of MediaWiki.r111272 to new and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111272#c31200 Old Status: fixme New Status: new Commit summary for MediaWiki.r111272: * Move hard coded styles in MessageWebImporter to CSS. * Break long line. * Bump version. * Update an unanswered @todo. * Add MessageGroups::getAllMessageGroups() as a replacement of MessageGroups::getGroups() * Update MessageGroups::getAllMessageGroups() to reduce code duplication in export.php and sync-group.php. Added two optional parameters: ** $groups: Get an array of groups for an array of group IDs. ** $groupPrefix: Get an array of groups with a given prefix. * Exit export.php if no valid group IDs are given. * i18n for two hard coded strings. * Add FIXME for missing i18n. Siebrand's comment: Correct. Addresssed in r111821. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Please test Javascript on meta.wikimedia.org
On Sat, Feb 18, 2012 at 10:11, Helder helder.w...@gmail.com wrote: On Fri, Feb 17, 2012 at 20:02, Erik Moeller e...@wikimedia.org wrote: being displayed as expanded, but being actually collapsed). I also still see the issue of occasional flashes of the pre-Vector toolbar. Is this the same which was reported on the following topic? http://labs.wikimedia.beta.wmflabs.org/wiki/Problem_reports#Old_toolbar_is_displayed_before_the_enhanced_toolbar_is_loaded It seems this was fixed recently: https://bugzilla.wikimedia.org/show_bug.cgi?id=34431 https://www.mediawiki.org/wiki/Special:Code/MediaWiki/111796 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] About page ID
Is there a sound reason to hidden so well the main id of pages? Is there any drawback to show it anywhere into wikies, and to use it much largely for links and API calls? Alex brollo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111821]: New comment added
Nikerabbit posted a comment on MediaWiki.r111821. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111821#c31201 Commit summary for MediaWiki.r111821: Use numbered variables. Follows-up r111272. Nikerabbit's comment: Still doesn't look right. The message is passed $defArray (which like the name says is an array) and $i, but the original text had the value of $traArray[$i] in it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] About page ID
2012/2/18 Alex Brollo alex.bro...@gmail.com Is there a sound reason to hidden so well the main id of pages? Is there any drawback to show it anywhere into wikies, and to use it much largely for links and API calls? Deleting and restoring/recreating results in a new id, and pages take their id upon renaming; is the id still useful for linking with these limitations? I just ask it because it is not perfectly clean for me what you mean by that. -- Bináris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111818]: Revision status changed
TheDJ changed the status of MediaWiki.r111818 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111818 Old status: new New status: ok Commit summary for MediaWiki.r111818: Proper $=jQuery aliasing in tablesorter test ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] About page ID
In some cases it would be better to linke on article ids than their names, something like http://en.wikipedia.org/aid/123456 One example is as a link to an article in Wikipedia from tweet posted through the Twitter API. John On Sat, Feb 18, 2012 at 1:51 PM, Bináris wikipo...@gmail.com wrote: 2012/2/18 Alex Brollo alex.bro...@gmail.com Is there a sound reason to hidden so well the main id of pages? Is there any drawback to show it anywhere into wikies, and to use it much largely for links and API calls? Deleting and restoring/recreating results in a new id, and pages take their id upon renaming; is the id still useful for linking with these limitations? I just ask it because it is not perfectly clean for me what you mean by that. -- Bináris ___ 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] About page ID
You can do that, only the URL is slightly longer: http://en.wikipedia.org/wiki?curid=2312711 Although I don't understand what would be the benefit of doing that. Petr Onderka [[User:Svick]] On Sat, Feb 18, 2012 at 14:09, John Erling Blad jeb...@gmail.com wrote: In some cases it would be better to linke on article ids than their names, something like http://en.wikipedia.org/aid/123456 One example is as a link to an article in Wikipedia from tweet posted through the Twitter API. John On Sat, Feb 18, 2012 at 1:51 PM, Bináris wikipo...@gmail.com wrote: 2012/2/18 Alex Brollo alex.bro...@gmail.com Is there a sound reason to hidden so well the main id of pages? Is there any drawback to show it anywhere into wikies, and to use it much largely for links and API calls? Deleting and restoring/recreating results in a new id, and pages take their id upon renaming; is the id still useful for linking with these limitations? I just ask it because it is not perfectly clean for me what you mean by that. -- Bináris ___ 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] About page ID
Alex Brollo schrieb: Is there a sound reason to hidden so well the main id of pages? Is there any drawback to show it anywhere into wikies, and to use it much largely for links and API calls? Not for API calls, but for links. For the API you can use mw.config.get(wgArticleId) without problems, but there are some downsides to use the page ID in regular links: * a link should show the page title, not just a intransparent number * pretty urls, see also http://www.mediawiki.org/?curid=2852 (???) * the id may stay consistent when moving a page, but that should be done with redirects. But when a page was deleted, having only the uri (http://de.wikipedia.org/?curid=6770594) won't help you anything (invalid title). But visiting http://de.wikipedia.org/wiki/Taurmina, you will see at least the deletion log. There was also a discussion at http://de.wikipedia.org/wiki/Wikipedia:Projektdiskussion/WP_-_Teil_des_www, since then we have a gadget in deWP to show a secont permanent link with curid. For technical documentation you may have a look at http://www.mediawiki.org/wiki/Manual:Short_URL. Regards, Bergi ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111822]: New comment added
Nikerabbit posted a comment on MediaWiki.r111822. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111822#c31202 Commit summary for MediaWiki.r111822: Removed wfDeprecated() call from LogPage::logName() and LogPage::logHeader(); they are still widely used including in core. Nikerabbit's comment: Could we please stop going back-and-forth with the deprecation warnings. I think the previous version where you can get the warnings *if you want* was better. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111821]: New comment added
Siebrand posted a comment on MediaWiki.r111821. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111821#c31203 Commit summary for MediaWiki.r111821: Use numbered variables. Follows-up r111272. Siebrand's comment: Stupid me. Too text oriented. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] About page ID
Yes I know you can do that, and in fact its what I do right now. The problem is that a few extra chars has a lot of impact in Twitter. A betetr approach would be if it was legal to write something like wikipedia.org/en/123456789 (26 chars) compared to en.wikipedia.org/aid/123456789 (30 chars) or http://en.wikipedia.org/wiki?curid=123456789 (44 chars). To get around the problem I use bit.ly for a bot, but its a bit stupid to not handle this in wikipedia itself. John On Sat, Feb 18, 2012 at 2:16 PM, Petr Onderka gsv...@gmail.com wrote: You can do that, only the URL is slightly longer: http://en.wikipedia.org/wiki?curid=2312711 Although I don't understand what would be the benefit of doing that. Petr Onderka [[User:Svick]] On Sat, Feb 18, 2012 at 14:09, John Erling Blad jeb...@gmail.com wrote: In some cases it would be better to linke on article ids than their names, something like http://en.wikipedia.org/aid/123456 One example is as a link to an article in Wikipedia from tweet posted through the Twitter API. John On Sat, Feb 18, 2012 at 1:51 PM, Bináris wikipo...@gmail.com wrote: 2012/2/18 Alex Brollo alex.bro...@gmail.com Is there a sound reason to hidden so well the main id of pages? Is there any drawback to show it anywhere into wikies, and to use it much largely for links and API calls? Deleting and restoring/recreating results in a new id, and pages take their id upon renaming; is the id still useful for linking with these limitations? I just ask it because it is not perfectly clean for me what you mean by that. -- Bináris ___ 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
[MediaWiki-CodeReview] [MediaWiki r111822]: New comment added
IAlex posted a comment on MediaWiki.r111822. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111822#c31204 Commit summary for MediaWiki.r111822: Removed wfDeprecated() call from LogPage::logName() and LogPage::logHeader(); they are still widely used including in core. IAlex's comment: It is not correct to get warning when simply using core whithout extensions and with the default configuration. Period. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111822]: New comment added
Nikerabbit posted a comment on MediaWiki.r111822. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111822#c31205 Commit summary for MediaWiki.r111822: Removed wfDeprecated() call from LogPage::logName() and LogPage::logHeader(); they are still widely used including in core. Nikerabbit's comment: Then change the default configuration? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111822]: New comment added
IAlex posted a comment on MediaWiki.r111822. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111822#c31206 Commit summary for MediaWiki.r111822: Removed wfDeprecated() call from LogPage::logName() and LogPage::logHeader(); they are still widely used including in core. IAlex's comment: And what for the comment at the beginning of the two chunks? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] About page ID
Thanks! I'll save this talk as a reference. Really my question was focused on possibile risks or safety issues; it's so strange that a database (since I see wikisource as a database) is mainly indexed, from the user's point of view, on a variable field as title of the page, that I suspected some serious safety issue. And - strangely enough - id is not shown at all into pages, nor there's any magic word or other user friendly method to get it. From a practical point of view, many from wikisource page titles are very long, often they use non-ascii characters and mixtures of capitalized and not capitalized characters, they can't be used as they are as local file names... in brief, I feel all this stuff almost as annoying as the apostophes used in wiki markup for bold and italic. ;-) Alex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111820]: Revision status changed
Hashar changed the status of MediaWiki.r111820 to reverted URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111820 Old status: new New status: reverted Commit summary for MediaWiki.r111820: (bug 34421) avoid duplicate Subject headers in mail r93397 duplicated the Subject header since it was passed both as an argument of mail() and in the additional headers array. This is r111765 done right. Tested using both Pear and mail() methods. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r93397]: Revision status changed
Hashar changed the status of MediaWiki.r93397 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93397 Old status: fixme New status: resolved Commit summary for MediaWiki.r93397: Reduce mail header differences by moving all the header creation code to one place. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111824]: Revision status changed
Amire80 changed the status of MediaWiki.r111824 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111824 Old status: new New status: ok Commit summary for MediaWiki.r111824: Minor comment fix, FIX Bug 34489 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111823]: New comment added, and revision status changed
Amire80 changed the status of MediaWiki.r111823 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111823#c31207 Old Status: new New Status: ok Commit summary for MediaWiki.r111823: Remoive mr inputmethods out of beta status because community people told that it is working. Amire80's comment: Woot. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r110042]: New comment added
Aaron Schulz posted a comment on MediaWiki.r110042. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/110042#c31208 Commit summary for MediaWiki.r110042: * follow up r110039 * killed doFileExists since it is not being called (thx to Aaron) * only use blobExists where necessary * all FileBackendTests pass Aaron Schulz's comment: You still should overwrite doStreamFile() and doGetFileSha1Base36(). The former should stream straight out of the store for performance. The later should use whatever metadata support Azure has to track the sha1 when an object is created (storeInternal or createInternal) as the Swift backend does. This makes the other operations faster. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111822]: New comment added
Nikerabbit posted a comment on MediaWiki.r111822. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111822#c31209 Commit summary for MediaWiki.r111822: Removed wfDeprecated() call from LogPage::logName() and LogPage::logHeader(); they are still widely used including in core. Nikerabbit's comment: They should stay, although alone they are useless for anyone who wants to find any fix deprecated use of stuff. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111822]: Revision status changed
Nikerabbit changed the status of MediaWiki.r111822 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111822 Old status: new New status: ok Commit summary for MediaWiki.r111822: Removed wfDeprecated() call from LogPage::logName() and LogPage::logHeader(); they are still widely used including in core. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111836]: Revision status changed
GWicke changed the status of MediaWiki.r111836 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111836 Old status: new New status: ok Commit summary for MediaWiki.r111836: * Locally apply the HTML5.Marker.type patch. This is needed until https://github.com/aredridel/html5/issues/44 is merged into the upstream html5 module. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111837]: Revision status changed
GWicke changed the status of MediaWiki.r111837 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111837 Old status: new New status: ok Commit summary for MediaWiki.r111837: * Add a make test target that auto-fetches parserTests.txt. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111439]: New comment added
Dantman posted a comment on MediaWiki.r111439. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111439#c31210 Commit summary for MediaWiki.r111439: Introduce property: and itemprop: support for addMeta to add RDFa meta property=... content=... and Microdata meta itemprop=... content=... to the head. This is done in a way that can also be feature tested, and technically could be expanded by extensions. Dantman's comment: * Sure perhaps we should fix stray itemprops in the parser. Even without a html scoped WebPage the Microdata spec basically indicates we should be stripping out itemprops that way anyways. * I have no plans to add any global Microdata into the skin. This feature is added for extensions that have a reason to do that. Whether it's a WebPage Microdata item, or there is some other type of spec they want to add. * http://schema.org/WebPage actually departs a little from the Microdata spec's rules. You can actually completely omit an itemscope and itemtype, and search engines will assume that html is a WebPage itemtype and stray itemprops belong to it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
Regarding my extension for dynamic adaption of $wgResourceLoaderMaxQueryLength in accordance to current suhosin parameter in php.ini it is correct to assume such a format http://example.com/?name1=value1name2=value2name3=value3 i.e. $wgResourceLoaderMaxQueryLength = the max. total length of query stream = ( (max. length of names) + (max. length of values) + 2 ) * ( max. number of name/value pairs ) Rusty wrote $wgResourceLoaderMaxQueryLength limits the *total* length of *all* names and values. Can you confirm ? signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111712]: New comment added, and revision status changed
Wikinaut changed the status of MediaWiki.r111712 to new and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111712#c31211 Old Status: fixme New Status: new Commit summary for MediaWiki.r111712: added ob_start() to prevent headers-already sent problem; add check for undefined variable; removed host wiki from the RSS feed title. feed title has now the programmatic form 'Pagename - Feed' which looks nice. Wikinaut's comment: set to new ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111788]: New comment added
Preilly posted a comment on MediaWiki.r111788. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111788#c31212 Commit summary for MediaWiki.r111788: Followup r111777, fixed mixed indentation caused by copy/paste fail Preilly's comment: Based on coding conventions there is no issue with suggesting the use of a ternary operator in this case, BTW. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111788]: New comment added
MZMcBride posted a comment on MediaWiki.r111788. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111788#c31213 Commit summary for MediaWiki.r111788: Followup r111777, fixed mixed indentation caused by copy/paste fail MZMcBride's comment: You're so saucy. lt;3 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111811]: Revision status changed
Aaron Schulz changed the status of MediaWiki.r111811 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111811 Old status: new New status: ok Commit summary for MediaWiki.r111811: Fix possibly undefined variables Move $db further up Return something on all paths ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111827]: Revision status changed
Aaron Schulz changed the status of MediaWiki.r111827 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111827 Old status: new New status: ok Commit summary for MediaWiki.r111827: Fix extraneous quote from r111800 Doesn't fix Niklas' issue, but it tidies it up for the moment ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111826]: Revision status changed
Aaron Schulz changed the status of MediaWiki.r111826 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111826 Old status: new New status: ok Commit summary for MediaWiki.r111826: Use local context to get messages ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111829]: New comment added, and revision status changed
Hashar changed the status of MediaWiki.r111829 to fixme and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111829#c31214 Old Status: new New Status: fixme Commit summary for MediaWiki.r111829: Add support to tablesorter to handle IP/CIDR notation This fixes bug 34475 Hashar's comment: /36 is not a valid IPv4 mask since an IP address is 32 bits. Instead of randomly generated IP, you need to make a list that would actually stress the code. For example making sure 100.0.0.0 is after 10.0.0.0. Or 10.0.0.1 after 10.0.0.0 but before 10.0.0.2. How would you sort 10.0.0.0/24 vs 10.0.0.0/16. And 10.0.0.0/24 vs 10.0.0.0 ? I guess an IP should be normalized to use a /32 mask then sort using that. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111829]: New comment added
Platonides posted a comment on MediaWiki.r111829. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111829#c31215 Commit summary for MediaWiki.r111829: Add support to tablesorter to handle IP/CIDR notation This fixes bug 34475 Platonides's comment: I'd sort 10.0.0.0/16, 10.0.0.0/24, 10.0.0.0 (from greater nets to smaller ones) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r111823]: Revision status changed
Nikerabbit changed the status of MediaWiki.r111823 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111823 Old status: ok New status: resolved Commit summary for MediaWiki.r111823: Remoive mr inputmethods out of beta status because community people told that it is working. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] MediaWiki Workshop: MediaWiki's ResourceLoader - 2/23/2012 on #wikimedia-dev
Greetings! Building on the success of our inaugural session, MW.org's WikiProject Extensions is presenting our next MediaWiki Workshops for developers (volunteer and staff). MediaWiki's ResourceLoader will be held on 23 February, 2012 at 21:00 UTC in IRC (#wikimedia-dev). This IRC workshop will be an opportunity to learn more about utilizing MediaWiki's ResourceLoader. Also an opportunity to ask questions about developing MediaWiki extensions. Everyone is invited to attend. Developers interested in serving as extensions or ResourceLoader experts are encouraged to signup as participants at: https://www.mediawiki.org/wiki/Project:WikiProject_Extensions/Workshops#MediaWiki_ResourceLoader_Experts MediaWiki Workshops typically last one hour, and happen no more than twice a month to present trainings, hold discussions and collaborate on community or WikiProject Extensions projects. Facilitators host the session to introduce any presenters, determine the order of questions, and generally helps to keep things going. Time of day will vary in order to offer people in different parts of the world the opportunity to participate. Future topics will likely include MW.org documentation, API orientation and workshops similar to our inaugural chat to prepare for each MediaWiki release. More information: https://www.mediawiki.org/wiki/Project:WikiProject_Extensions/MediaWiki_Workshops MediaWiki.org's WikiProject SysAdmins will also likely host similar MediaWiki Workshops to help third-party wiki system administrators. Stay tuned for more information, and chime in at: https://www.mediawiki.org/wiki/Project:WikiProject_SysAdmins/Ideas I look forward to seeing folks on Thursday! Please feel free to forward this along to any interested folks. -greg aka varnent --- Gregory Varnum Lead Administrator, WikiQueer Lead, Aequalitas Project @GregVarnum fb.com/GregVarnum ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Mediawiki-l] authentication on Wikipedia via user_name OR user_email
Le 16 févr. 2012 à 22:26, Platonides a écrit :
On 16/02/12 09:51, Nicolas Brouard INED wrote:
Thanks to Platonides for his comment and also to Olivier (the author of the
Realnames extension) who told me to forward the following patch to
wikitech-l (which I just subscribed to) for advices, comments and critics.
I was just wondering if this small patch in User.php (function idFromName)
was enough in most cases:
$dbr = wfGetDB( DB_SLAVE );
$s = $dbr-selectRow( 'user', array( 'user_id' ), array(
'user_name' = $nt-getText() ), __METHOD__ );
if ( $s === false ) {
//Start Patch $result = null;
$stwo = $dbr-selectRow( 'user', array( 'user_id' ), array(
'user_email' = $nt-getText() ), __METHOD__ );
if ( $stwo === false ) {
$result = null;
}else {
$result = $stwo-user_id;
}
//End patch
} else {
$result = $s-user_id;
}
This is only patching User::idFromName(), which won't be enough.
Sorry, could you detail why it won't be enough!
You could well be storing the email instead of the username in the page
history.
I was probably not clear enough: I don't want the email in the page history.
Also the Realnames extension (quoted above) is trying to do what you seem
suggesting but it is a complex extension which did not work on 1.18 for example.
The proposed patch is also a solution which manages the transition for
Wikipedians. Having an authentication with e-mail only is brutal and won't be
understood. I like the possibility of having both option with a priority to
username for performance also.
But allowing new authors from Arabic or Asian (or Russian or ...) countries
(with non Roman characters) to sign new articles in their own language with
their own standard, not transliterated, signature will be appreciated if they
also have an easy way to authenticate on an English keyboard (pad, smartphone
etc.).
As I said, you should fix it in SpecialUserlogin.php.
What should I fix? Is there something wrong in the proposed patch?
Then, just try to enter your e-mail on a standard wiki in place of your
username and you will be authenticated to the first ID (and user_name)
having your e-mail.
The importance of e-mails as a simple way to authenticate on modern sites
can't be ignored.
It can also expose the fact that someone is registered there with that
email address.
I don't understand what you mean and if someone has already entered an email
for a username what is the problem?
In the patch provided, it would also happily show under some
circunstances the username associated to an email (not a problem for the
internal wiki of a company, where everybody know each other's mail, an
issue for public wikis out there).
That is the reason why I was asking this mailing list. But, as I said in a
previous and detailed answer to Bergi, the patch is very short (a single if)
and thus consequences are not tremendous.
We made some tests on various wikis, and we haven't found yet any circumstance
where the username associated to an email is displayed:
- it can't happen when the authentication works;
- the only situation that I have found is when you are asking for a new
password: then the username associated with the email entered (in place of the
username) is displayed in the received email, but it is not a security issue
because you are the only person to read your email.
If you want to enter your standard username for authentication you can do it
too.
But if your username is not a Roman but an Arabic, Thai, Japanese etc.
username or even a French username with accents and if you decided to have
authorship recognized in your own language and not only in a English
transliterated way, you can also do it with as standard mediawiki
installation. But if you are working with somebody who has an English
keyboard only, the copy-paste of your Unicode username may be tedious and
you would prefer to enter your e-mail address.
The modified Login form could be:
Username (or e-mail address): |___|
Password: |___|
Changing the text displayed there is trivial (edit MediaWiki:yourname).
It seems that MediaWiki:Yourname is deprecated. The (or e-mail address)
sentence must be translated too in all languages (more than 15 for Demopaedia).
But I think that it is no a problem neither for us nor for Wikipedia.
Thanks for your comments,
-Nicolas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] authentication on Wikipedia via user_name OR user_email
Le 18 févr. 2012 à 23:41, Nicolas Brouard a écrit: Le 16 févr. 2012 à 22:26, Platonides a écrit : On 16/02/12 09:51, Nicolas Brouard INED wrote: Thanks to Platonides for his comment and also to Olivier (the author of the Realnames extension) who told me to forward the following patch to wikitech-l (which I just subscribed to) for advices, comments and critics. I was just wondering if this small patch in User.php (function idFromName) was enough in most cases: (...) This is only patching User::idFromName(), which won't be enough. Sorry, could you detail why it won't be enough! You could well be storing the email instead of the username in the page history. I was probably not clear enough: I don't want the email in the page history. Also the Realnames extension (quoted above) is trying to do what you seem suggesting but it is a complex extension which did not work on 1.18 for example. The proposed patch is also a solution which manages the transition for Wikipedians. Having an authentication with e-mail only is brutal and won't be understood. I like the possibility of having both option with a priority to username for performance also. But allowing new authors from Arabic or Asian (or Russian or ...) countries (with non Roman characters) to sign new articles in their own language with their own standard, not transliterated, signature will be appreciated if they also have an easy way to authenticate on an English keyboard (pad, smartphone etc.). I didn't express it right. If you do $user = User::newFromName(em...@address.com), that gets cached, and if youlater use that object for eg. storing the username in the history, boom, $uset-getName() will say it's called em...@address.com That's probably not happening, but you would need to check all paths in core and the extensions... As I said, you should fix it in SpecialUserlogin.php. What should I fix? Is there something wrong in the proposed patch? The patch should go against SpecialUserlogin.php, authenticateUserData() function. Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail. The importance of e-mails as a simple way to authenticate on modern sites can't be ignored. It can also expose the fact that someone is registered there with that email address. I don't understand what you mean and if someone has already entered an email for a username what is the problem? In the patch provided, it would also happily show under some circunstances the username associated to an email (not a problem for the internal wiki of a company, where everybody know each other's mail, an issue for public wikis out there). That is the reason why I was asking this mailing list. But, as I said in a previous and detailed answer to Bergi, the patch is very short (a single if) and thus consequences are not tremendous. Go to Special:Contributions and enter the email of an existing user. I think it may show the user contributions. We made some tests on various wikis, and we haven't found yet any circumstance where the username associated to an email is displayed: - it can't happen when the authentication works; - the only situation that I have found is when you are asking for a new password: then the username associated with the email entered (in place of the username) is displayed in the received email, but it is not a security issue because you are the only person to read your email. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About page ID
John Erling Blad wrote: In some cases it would be better to linke on article ids than their names, something like http://en.wikipedia.org/aid/123456 One example is as a link to an article in Wikipedia from tweet posted through the Twitter API. People interested in prettier URLs should follow these bugs: * https://bugzilla.wikimedia.org/1450 * https://bugzilla.wikimedia.org/16659 * https://bugzilla.wikimedia.org/17981 MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About page ID
On Sat, Feb 18, 2012 at 8:36 AM, John Erling Blad jeb...@gmail.com wrote: Yes I know you can do that, and in fact its what I do right now. The problem is that a few extra chars has a lot of impact in Twitter. A betetr approach would be if it was legal to write something like wikipedia.org/en/123456789 (26 chars) compared to en.wikipedia.org/aid/123456789 (30 chars) or http://en.wikipedia.org/wiki?curid=123456789 (44 chars). To get around the problem I use bit.ly for a bot, but its a bit stupid to not handle this in wikipedia itself. This seems moot to me because it's handled in *Twitter* itself. All URLs in a tweet are converted to t.co shortcuts that are twenty characters long (while abbreviated versions of the destination URLs should be shown when the tweet is viewed). More information is here: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/14d5474c13ed84aa. Madman ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111378]: New comment added
Krinkle posted a comment on MediaWiki.r111378.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111378#c31216
Commit summary for MediaWiki.r111378:
[RL] Comment mod and other minor changes
_ Add comment about why it casts to (object)
- Modify function comment
- Whitespace (start the function body on a new line in debug mode. In
production mode this is trimmed away afterwards)
- Remove the jQuery-$ passage from loader. There is already a global alias for
$ by jQuery, and aside from that every module has it's own (function(){})
wrapper that aliases it from jQuery (not from $), so there is no performance
gain either by having it locally here since it doesn't use that.
Krinkle's comment:
Well, if that's the use case of this alias. Then what about
codejQuery/code, codemw/code, codemediaWiki/code,
codedocument/code or perhaps even codewindow/code ?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
On Sat, Feb 18, 2012 at 10:12 AM, Thomas Gries m...@tgries.de wrote: Can you confirm ? I think the real problem is that $wgResourceLoaderMaxQueryLength is insufficient for the configuration you desire. It only loosely correlates with the problem it seems intended to resolve. Assuming both the number of key/value pairs and the length of each key resource loader uses is bounded and small, a new configuration variable to control the maximum value length would be useful for your purposes. ~Rusty ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Problematic automated tweets
Tonight the Twitter account @wikimediatech sent out two problematic tweets that began with jfaritu, one of which contains a racial slur. Not sure who handles this, but please have someone look into it. Thanks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problematic automated tweets
I saw that too, those tweets have now been taken down by one of the admins. Techman224 On 2012-02-18, at 9:39 PM, A wrote: Tonight the Twitter account @wikimediatech sent out two problematic tweets that began with jfaritu, one of which contains a racial slur. Not sure who handles this, but please have someone look into it. Thanks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l signature.asc Description: Message signed with OpenPGP using GPGMail ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problematic automated tweets
On Sat, Feb 18, 2012 at 7:39 PM, A jokestr...@gmail.com wrote: Tonight the Twitter account @wikimediatech sent out two problematic tweets that began with jfaritu, one of which contains a racial slur. Not sure who handles this, but please have someone look into it. Thanks. A channel troll logged to our Server Admin Log. It automatically posts to twitter and identi.ca. I've cleaned it up everywhere. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r111846]: Revision status changed
Santhosh.thottingal changed the status of MediaWiki.r111846 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111846 Old status: new New status: ok Commit summary for MediaWiki.r111846: Unbreak Narayam, ping r111823 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] About page ID
Some of the urls to Wikipedia will fail when converted by the mechanism in Twitter, so you either must use the ugly url in the tweet or use a short url. Because you usually want to control the overall length you must convert it to a short url before you know how long it will be. In my opinion it wold be better if there was a simple way to generate short urls that also identified Wikipedia as such. John On Sun, Feb 19, 2012 at 12:38 AM, [[w:en:User:Madman]] madman.enw...@gmail.com wrote: On Sat, Feb 18, 2012 at 8:36 AM, John Erling Blad jeb...@gmail.com wrote: Yes I know you can do that, and in fact its what I do right now. The problem is that a few extra chars has a lot of impact in Twitter. A betetr approach would be if it was legal to write something like wikipedia.org/en/123456789 (26 chars) compared to en.wikipedia.org/aid/123456789 (30 chars) or http://en.wikipedia.org/wiki?curid=123456789 (44 chars). To get around the problem I use bit.ly for a bot, but its a bit stupid to not handle this in wikipedia itself. This seems moot to me because it's handled in *Twitter* itself. All URLs in a tweet are converted to t.co shortcuts that are twenty characters long (while abbreviated versions of the destination URLs should be shown when the tweet is viewed). More information is here: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/14d5474c13ed84aa. Madman ___ 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
