Wikitech-l November 2011

wikitech-l@lists.wikimedia.org

127 participants
145 discussions

two layers of <a>
by jidanni＠jidanni.org 22 Nov '11

22 Nov '11

Why the two layers of <a> even if it passes $ validate http://en.wikipedia.org/wiki/Oaxtepec *** Errors validating Oaxtepec: *** Error at line 2, character 33: there is no attribute "class" Error at line 152, character 10: end tag for "ul" which is not finished Error at line 177, character 10: end tag for "ul" which is not finished Why the </a> halfway through the first pair of Coordinates: 18°54′N 98°58′W / 18.9°N 98.967°W / 18.9; -98.967 Why does it look fine in some browsers but ah-ha caught you in emacs-w3m? Could it be that Firefox and Chromium are fooled into thinking that the outer <a id...> which lasts through the whole six coordinates should render as a clickable link... which it apparently does even with stylesheets off. Only emacs-w3m renders it right, revealing the badly written HTML! Here's the code, <a id="coordinates"><a href="/wiki/Geographic_coordinate_system" title="Geographic coordinate system">Coordinates</a>: <a rel="nofollow" class="external text" href="http://toolserver.org/~geohack/geohack.php?pagename=Oaxtepec&params=18_…">18°54′N</a> 98°58′W / 18.9°N 98.967°W / 18.9; -98.967</a>

3 3

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 21 Nov '11

21 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 21 Nov '11

21 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 19 Nov '11

19 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 19 Nov '11

19 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 18 Nov '11

18 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 18 Nov '11

18 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 18 Nov '11

18 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

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

Jump to page:

2025

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