Wikitech-l November 2011

wikitech-l@lists.wikimedia.org

127 participants
144 discussions

Re: [Wikitech-l] Compiling Debian Packages (was Re: 1.18 PHP version requirement)
by John Du Hart 21 Nov '11

21 Nov '11

So instead of having a script that just has to run basic unix commands in order to manage vhosts you now need something to parse an http.conf file. I'm pretty sure I know what I'd choose. On Nov 20, 2011 1:25 AM, "Dmitriy Sintsov" <questpc(a)rambler.ru> wrote: On 19.11.2011 22:59, Happy Melon wrote: > "Better" here is clearly in the eye of the beholder. The ... My method does not require creation of symlinks and numeric prefixes, that's why it's better. Ancient languages used numeric labels for lines of code. Cut / paste of single text line is faster than renaming symlinks. Commenting line with # is better as well. These points are objective, not subjective. I would stop talking about that yesterday if you weren't insisting that it's a personal preference (it's not). Dmitriy _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia...

1 0

Re: [Wikitech-l] No new german dump
by Ariel T. Glenn 21 Nov '11

21 Nov '11

The three processes we had going for "largish" wikis had been restarted from a particilar step, since I had to interrupt them earlier for kernel upgrade and reboot. These stop at the end of the run. Three regular jobs are now running; these cycle through the list of the ten largish wikis in the usual way. While we're on the subject of de wiki, I have been considering starting to produce smaller output files much as we do for en wikipedia. 100GB is pretty large for someone to download and process, and it takes a while to produce as well. Any thoughts? CC-ing wikitech-l since some people on that list may be users of the dump that don't subscribe to xmldatadumps-l (but they should!) Ariel Στις 19-11-2011, ημέρα Σαβ, και ώρα 18:03 +0100, ο/η Andreas Meier έγραψε: > Hello, > today we ja-dump was finished, so a new de-dump should start. > > Best regards > Andreas

1 0

Bugzilla Weekly Report
by reporter 20 Nov '11

20 Nov '11

MediaWiki Bugzilla Report for November 14, 2011 - November 21, 2011 Status changes this week Bugs NEW : 248 Bugs ASSIGNED : 19 Bugs REOPENED : 36 Bugs RESOLVED : 189 Total bugs still open: 6549 Resolutions for the week: Bugs marked FIXED : 142 Bugs marked REMIND : 0 Bugs marked INVALID : 14 Bugs marked DUPLICATE : 15 Bugs marked WONTFIX : 19 Bugs marked WORKSFORME : 4 Bugs marked LATER : 1 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component API 10 UploadWizard 7 SemanticForms 7 Extension setup 5 General/Unknown 5 New Bugs Per Product MediaWiki 28 Wikimedia 22 MediaWiki extensions 32 mwdumper 1 Wikimedia Mobile 3 Top 5 Bug Resolvers sam [AT] reedyboy.net 33 roan.kattouw [AT] gmail.com 27 neilk [AT] wikimedia.org 14 jeroen_dedauw [AT] yahoo.com 12 mah [AT] everybody.org 11

1 0

Making all localized namespace names available on all language wikis... or not, Damn you Stampa and Datoteka
by Daniel Friesen 20 Nov '11

20 Nov '11

I had an idea for a feature to allow any language user to go to any other language wiki and be able to use the namespaces they recognize. The idea would be that a user from it.wp could go to fr.wp and when visiting Utente:... (Utente is User in Italian) whether via search or direct address linking and end up on Utilisateur:... (French's User namespace) This would be done by considering every possible localization of a namespace as an alias in all languages. So on fr.wp Utente, User, etc... would all be aliases for Utilisateur. Additionally since namespaces are dependent on the user rather than the content for logged in users we could start displaying localized namespace names to help the user around and not have to worry about issues that if they copy&paste or whatever it wouldn't be valid. We've got a massive localization cache, and it's possible we might find a way to make a feature like this possible, so that wasn't an issue to stop this idea. But there was a slim possibility that words used for namespaces might conflict with what other languages use. That sounded so unlikely that I wrote a script to scan every language we have for all available namespace names and what they map to and see if the same text is used for different namespaces in any languages. And the dooming news, there are some conflicts. "Stampa" is NS_TEMPLATE in Aln (Gheg Albanian) and Sq (Albanian) and NS_FILE in Mt (Maltese). And Datoteka is NS_FILE in Bs (Bosnian), Hr (Croatian), and Sh (Serbocroatian), but NS_MEDIA in Sl (Slovenian). So our only options are (probably in order of simplicity/likelihood first ;) ): A) Drop this feature idea. B) Find a way to deal with collisions and accept there may be some bugs an confusing behavior for users. C) Implement this while making use of lots of language heuristics like Accepts-Language, Geolocation, and other things that will hurt caching. D.a) Drop support for either Maltese or Albanian languages and Slovenian or Croatian languages. D.b) Convince everyone who speaks these languages to use a different word. D.c) Commit genocide and wipe those languages off the face of the earth and erase them from the history books. E) Implement a brain-neural interface and require use of it while browsing Wikipedia so that we can extract what the user 'actually' means and understands directly from their mind. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

4 3

Re: [Wikitech-l] new external store databases deployed - followup questions
by bawolff 18 Nov '11

18 Nov '11

> Hi everyone, > > I just posted a > note<http://blog.wikimedia.org/2011/11/18/nobody-notices-when-its-not-broken-new…>on > the blog about our new external store but wanted to add a few details > here. The deploy went smoothly, and I'm very happy with how the project > progressed overall. There are plenty more details on the project itself on > the project wiki > page<http://wikitech.wikimedia.org/view/External_storage/Update_2011-08>and > hiding in RT. there were a few followup things to come out of it, and > I want to talk through those in hopes that someone either picks them up or > has suggestions on what to do. > >From what I've read on the blog, that sounds like a "Good Work everyone" is in order :) > > During the deploy there was a brief (about 10 minute) period during which > article saves failed due to the external store databases being in read-only > mode. As expected, some folks showed up in IRC telling us of the > 'problem'. After the migration was complete we brainstormed a bit in IRC > about good ways of informing editors of planned maintenance such as this > migration. The regular databases (s3, etc.) have a read-only mode flag so > that the affected wikis show a reasonable error, but the external store > databases are a little different. Because of the way they're spread out, > the outage of a specific database cluster does not affect specific language > projects, but instead affects a specific time range for all wikis. > Additionally, the currently writable external store database affects > article edits on all wikis. > > There were a few suggestions thrown around: > 1) use central notice. This would certainly have the effect of alerting > all wikis that there was some maintenance, but it has the disadvantage of > telling all *readers* about the outage, rather than only the people that > would actually be interested (those editing pages). --^ Seems to be the most reasonable thing to do. Readers who don't care, probably don't read sitenotices that don't involve giant pictures of everyone's favourite Wikipedia founder, and even if they do read it, I'm sure they'd ignore it. A small maintenance notice is not likely to annoy people. Saves not working is likely to annoy people. Saves not working after you spent an hour revising whatever article you're writing will definitely frustrate people. > 2) make mediawiki cache the change to conceal the outage from editors. The > idea here is that mediawiki would notice that the backend database is > currently in read-only mode and would cache the change and write it to the > DB when it returns to read-write mode. There are a number of technical > challenges here, as well as the introduction of another system (the change > cache), but it's an interesting way around the problem, since rather than > addressing how to inform editors of impending maintenance it simply > eliminates the necessity for that communication. Sounds (very) needlessly complex. Not to mention if it partially fails and people edits go through, then un-go through, people won't be happy. > 3) throw up a banner on the edit page itself. The time when we want to > inform someone that there is going to be maintenance that will impede > editing is when the user begins an edit. (at the moment we inform them > when they try to save the edit in the form of an error message.) > [..] This also sounds reasonable. I personally would just go with just a normal central notice, but this would also be fine imo. > 4) don't make any change from what we do now. The external store databases > rarely fail or undergo maintenance. Increasing the complexity of the > system to protect against their outage will be more likely cause harm than > the outages themselves. Instead, just announce it on the blog before and > apologize to anybody affected afterwards. I really feel that having a site/central notice for planned maintenance is important. At the very least stuff like this should probably be announced on various mailing lists or VP's. Our editors are important, we should make sure we avoid unnecessarily wasting any time/effort they put in to the wiki. -bawolff

2 1

those Jimbo pics are scaring me
by jidanni＠jidanni.org 18 Nov '11

18 Nov '11

Is there anyway to turn off those Jimbo pics every time I check something in Wikipedia... I use many different public terminal browsers so won't be logged in. Yes there's the little box with the [X] but "he has already looked at me".

6 5

Re: [Wikitech-l] those Jimbo pics are scaring me
by jidanni＠jidanni.org 17 Nov '11

17 Nov '11

Why can't they sign somebody who doesn't scare children, like http://en.wikipedia.org/wiki/Pee-wee_Herman . Why does the best person for the campaign have to be the most logical person? Haven't they got any advertising sense? I bet Pee-wee would love to help. Why don't they give him a call?

2 1

1.18RC verification -- does it work for you?
by mhershberger＠wikimedia.org 17 Nov '11

17 Nov '11

Now that Sam has announced the 1.18 Release Candidate, we'd like to make sure that we've created a tarball that will work. Please give 1.18RC1 a try and add your experience to <http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.18/Upgrade_reports>. I just upgraded one of the wikis I maintain from 1.15 and recorded my experience. Of course, as Sam writes in his announcement, you should probably not do this on a production wiki "unless you are both very brave and very confident in your MediaWiki administration skills." So, maybe you'll want to try it in a test installation. That said, let us know of your successes! Of course, we'd like to know about failures, too, and that page is an appropriate place to report them (in addition to bugzilla), but we really need to know if this release is as good as we think it is. Thanks, Mark.

1 0

MediaWiki Release Candidate 1.18.0rc 1
by Sam Reed 17 Nov '11

17 Nov '11

I'm happy to announce the availability of the first release candidate of the new MediaWiki 1.18 release series. Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. MediaWiki 1.18 is a large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the RELEASE-NOTES file for the full list of changes in this version. ********************************************************************* What's new? ********************************************************************* MediaWiki 1.18 brings the usual host of various bugfixes and new features. jQuery 1.6.4 is now included as standard, along with numerous more jQuery plugins. Breaking changes: * action=watch / action=unwatch now requires a token As of 1.18, some extensions are now being bundled with the released tarball. The following extensions are bundled with MediaWiki as of 1.18. All are currently in use on Wikimedia sites. * ConfirmEdit - Various CAPTCHA techniques to try to prevent spambots and other automated tools from editing your wiki. * Gadgets - A system to allow users to enable or disable JavaScript or CSS tools made available to users site-wide. * Nuke - A special page allowing administrators to mass-delete content added by a spammer or vandal. * ParserFunctions - Additional parser functions (like #if and #switch to supplement the "magic words" present in MediaWiki. * Renameuser - A special page which allows authorized users to rename user accounts. * Vector - Enhancements to the Vector skin. * WikiEditor - An improved and customizable editing toolbar developed along the Vector skin. Major features - -------------- Better gender support -- --------------------- Until version 1.17, MediaWiki used neutral nouns to address and identify users on their user page. In English, this was not an issue since "User" matches both genders, but in some languages the neutral gender is always masculine; for example, this would cause French-speaking female Wikipedia users to be referred to as "Utilisateur" (male user) instead of "Utilisatrice" (female user). With version 1.18, user pages reflect the user's gender, if they have specified it in their preferences. More gender support (for instance in logs and user lists) will be available in MediaWiki 1.19. Improved file metadata support -- ----------------------------- MediaWiki now detects the camera orientation from Exif metadata, and rotates the picture preview accordingly. The original file remains unchanged. The overall metadata support in MediaWiki has been greatly extended. Previously, MediaWiki could only extract limited Exif metadata, and showed a subset of it on file description pages. Since 1.18, MediaWiki can extract IPTC and XMP metadata from uploaded files, and more Exif information. This includes an embedded description, author information, GPS coordinates, or copyright statement. Improved directionality support -- ------------------------------- A lot of work has been done to fix directionality bugs (Left-To-Right, Right-To-Left). Most notably bug 6100 is fixed, which allows to display an RTL interface on an LTR wiki properly (and vice versa). This was developed under $wgBetterDirectionality, which is now no longer used because the improvements are merged with the core code. A positive consequence is that the page content on wikis with multiple scripts is aligned according to the direction of the selected variant. For example, on a Kazakh language wiki, selecting the Arabic script variant will align the text as RTL, while selecting the Latin or Cyrillic variant will align it as LTR. Easily find where to customize interface messages -- --------------------------------------------- MediaWiki allows you to customize the user interface by editing pages in the MediaWiki namespace. However, even though they can be viewed at Special:AllMessages] the sheer number of these messages makes it difficult to find which one needs to be customized. In MediaWiki 1.18, a new pseudo-language is introduced (qqx) to help people find such messages, by displaying the messages' key instead of the actual messages. All one has to do is append ?uselang=qqx to the page's index.php/ URL (see https://www.mediawiki.org/w/index.php?title=MediaWiki_1.18&uselang=qqx as an example). New plugin for collapsible elements -- ----------------------------------- The new jQuery.makeCollapsible allows you to create collapsible tables, lists and so on, by adding the class mw-collapsible to the elements. See the manual for details: https://www.mediawiki.org/wiki/Manual:Collapsible_elements Protocol-relative URLs -- ---------------------- MediaWiki now supports protocol- relative URLs in links, interwiki targets and $wgServer. Protocol-relative URLs look like //example.com/wiki/Foo ; the browser will recognize this as http://example.com/wiki/Foo when following a link from an HTTP page, and https://example.com/wiki/Foo when following a link from an HTTPS page. This way, protocol-relative URLs enable a wiki to support HTTP and HTTPS while serving the same HTML for both, which means the parser cache doesn't have to be split. More personalisable styles and scripts -- -------------------------------------- MediaWiki now automatically loads javascript and stylesheets more specific to each user. There is a separate CSS and JS file for each usergroup (MediaWiki:Group-sysop.css, MediaWiki:Group-autoconfirmed.js, etc), and also a CSS file for users viewing without JavaScript (MediaWiki:Noscript.css). Other changes -- ------------- $wgEnableDublinCoreRdf and $wgEnableCreativeCommonsRdf no longer work in core, and the functionality has been moved to the relevant extensions. See http://www.mediawiki.org/wiki/Extension:DublinCoreRdf and http://www.mediawiki.org/wiki/Extension:CreativeCoreRdf as appropriate Math - ---- $wgUseTeX has been superseded by the Math extension. To re-enable math conversion after upgrading, obtain the Math extension from SVN or from http://www.mediawiki.org/wiki/Extension:Math and add to LocalSettings.php: require_once "$IP/extensions/Math/Math.php"; Language support - ---------------- As with every release, MediaWiki 1.18 brings improved support for languages in MediaWiki, with improved translation and features for the many supported languages. New languages: * Angika (anp) * Brahui (brh) * Central Dusun (dtp) * Jamaican Creole English (jam) * Khowar (khw) * Liv (liv) * Kichwa (qug) API - --- API bug fixes and new features have been added to 1.18, providing more options for input and output. * API modules were added to access QueryPage based special pages, to Compare pages, Revert files, and to be able to access other special pages such as Special:UnwatchedPages, Special:MimeSearch and Special:ActiveUsers * The output of the generated help page has been improved The API contains a breaking changes against previous releases: * action=watch now requires POST and token. Other - ----- Our thanks go to everyone who helped to improve MediaWiki by testing the beta release and submitting bug reports and patches. Release notes - ------------- Complete release notes are at http://www.mediawiki.org/wiki/Release_notes/1.18 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.tar.gz Patch to previous version (1.18.0beta1), without interface text: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.0rc1.patch. gz GPG signatures: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.tar.gz.sig http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.patch.gz.si g http://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.0rc1.patch. gz.sig Public keys: https://secure.wikimedia.org/keys.html

1 0

Re: [Wikitech-l] Validator extension.
by Jeroen De Dauw 17 Nov '11

17 Nov '11

Hey, (Full replied to message can be found here: http://pastebin.com/J0aLk2t9) > Please respond to appropriate mail list -- either WikiTech-L Might be interesting to people here :) > But I found terminology used in Validator frustrating and misleading. Well yeah, I agree, the names parameter and argument are used pretty loosely through the extension. > However, it will break compatibility with existing Validator… What do you think? It is possible? How manage compatibility? Create incompatible Validator2? In general I agree with your remarks, but it's not really possible to just change this on the fly, as it would break a lot of compatibility. I suggest creating a new alternate system while keeping the old one, so things can gradually be migrated, and then have the old thing go when it's no longer used. In particular, I'd like to split the param definition from the parameter (with value) handling functionality. Since the Parameter class is used all over the place to define parameters, changing this one would be hard. I also thing it's not that bad of a name, and clearer then Descriptor. So maybe it's better to find an alternate name for the "parameter with value" class, which is only used in Validator itself anyway. And I'd like to have a more lightwight way of defining parameters, rather then creating a Parameter object for each. In most cases an associative array suffices, which can then be turned into an object later on. And I think the current way parameter criteria and manipulations are defined sort of sucks. You need a class for each, while often you want to do very simple stuff. Passing in a function should also work. In PHP 5.3+, anon functions would make a lot of sense here. If a separate parameter definition class is cerated, it might actually make a lot of sense to have doValidation and doManipulation methods in there. This does not allow to share criteria and manipulation objects like the current system, but is probably less of a hassle and less over engineered. Also, I'd like to get rid of the evil LSB hack in the ParserHook class, but guess it's still to early to do that (since you'd need PHP 5.3+). Any such changes would contribute to a new mayor release, version 0.5. The last big changes, those for 0.4, where made over a year ago, and although I see a bunch of stuff that could be made better architecture wise, the current system works. So I'm not that keen on making these changes now and deal with all the compatibility issues. (Maybe after SMW 1.7 has been released.) But if you feel like poking at it or writing up a proposal for a new architecture, please do, I'll happily provide feedback. > BTW, in many languages positional arguments are allowed before the first named argument. Validator allows: > {{ #func: pos1… | namedA=… | pos2… | namedB=… }} Yeah, it does allow this. Originally it did not, but I figured some users might not understand or think about the difference, so I just added this because it works. I don't see what your issue with this is. I don't know how this is called, but don't see how that matters :) > I am sure Validator is a great idea and really helps. I used it in few my extensions. I also wrote parser function `#validate' to validate template arguments and use it in almost all my templates! Well, please share your code - sounds like this could be useful to other people as well ;) Although the current architecture might need some tweaking to become really nice, I think having a declarative system for parameters is very powerful as it allows for a whole range of cool things, which is why I created the extension in the first place. Since then I've only become more convinced of this, and would really like to see such functionality get put into core at some point, in one form or another. Any comments on this are appreciated. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l November 2011