MediaWiki-l September 2014

52 participants
53 discussions

Lis tes messages avant qu'ils ne soient effacés!
by Badoo 31 Dec '23

31 Dec '23

Lis ton message de Nganguem Victor avant qu'il ne soit effacé! Pour lire ton message, suis simplement ce lien: http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6 D'autres personnes sont aussi présentes: Oded (Tel Aviv, Israël) Priya (Udaipur, Inde) RajaYogi BK (Udaipur, Inde) Karuna (Udaipur, Inde) Chika Reginald Onyia (Pnompen', Cambodge) ...Qui d'autre? http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6 Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur. Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système. Amuse-toi bien ! L'équipe Badoo Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir: http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…

3 2

Wikibase on third-party wikis
by Till Kraemer 26 Sep '16

26 Sep '16

Hi, I'm trying to use Wikibase on my pool wiki and language wikis. In my pool wiki, I can create properties and items, but I can't add site links to them. ID: "Q1", site id: "cswiki", site link: "article name" gives me the error "The specified article could not be found on the corresponding site." even though that article exists on cswiki. I also can't access data from the language wikis. If I use {{#property:P1}} in an article on cswiki, nothing shows up. I downloaded Wikidata-refs-heads-master.tar.gz and extracted it to the extension folder of my pool wiki and language wikis. My LocalSettings.php of the pool wiki looks like this: # Wikibase $wgEnableWikibaseRepo = true; $wgEnableWikibaseClient = false; $wmgUseWikibaseRepo = true; $wmgUseWikibaseClient = false; require_once __DIR__ . "/extensions/Wikidata/Wikidata.php"; require_once __DIR__ . "/extensions/Wikidata/extensions/Wikibase/repo/ExampleSettings.php"; # SiteMatrix Extension require_once "$IP/extensions/SiteMatrix/SiteMatrix.php"; $wgLocalDatabases = array( 'cswiki', 'dewiki', 'enwiki', 'eswiki', 'frwiki', 'huwiki', 'hywiki', 'itwiki', 'nlwiki', 'plwiki', 'poolwiki', 'ptwiki', 'ruwiki', 'srwiki', 'svwiki' ); My LocalSettings.php of the language wikis (cs for example) look like this: # Wikibase Extension $wgEnableWikibaseRepo = false; $wgEnableWikibaseClient = true; $wmgUseWikibaseRepo = false; $wmgUseWikibaseClient = true; require_once __DIR__ . "/extensions/Wikidata/Wikidata.php"; # Settings $wgWBSettings['repoUrl'] = 'http://pool.mypedia.com'; $wgWBSettings['repoScriptPath'] = '/w'; $wgWBSettings['repoArticlePath'] = '/wiki/$1'; $wgWBSettings['siteGlobalID'] = 'cswiki'; $wgWBSettings['repoDatabase'] = 'poolwiki'; $wgWBSettings['changesDatabase'] = 'poolwiki'; # Optional $wgWBSettings['siteGroup'] = 'mypedia'; $wgWBSettings['sort'] = 'code'; //optional $wgWBSettings['sortPrepend'] = array( 'cs' ); In populateSitesTable.php, I changed "https://meta.wikimedia.org/w/api.php" to "http://pool.mypedia.com/w/api.php" and "$validGroups = array( 'wikipedia', 'wikivoyage', 'wikiquote', 'wiktionary','wikibooks', 'wikisource', 'wikiversity', 'wikinews' );" to "$validGroups = array( 'mypedia' );" Do I need to change "$wikiId = $this->getOption( 'wiki' );" too, since it says "wiki" is expanded to "wikipedia"? Table "sites" in the poolwiki database looks like this: site_id | site_global_key | site_type | site_group | site_source | site_language | site_protocol | site_domain | site_data | site_forward | site_config 1 | cswiki | mediawiki | mypedia | local | cs | http:// | com.mypedia.cs. | a:1:{s:5:"paths";a:2:{s:9:"file_path";s:5:"/w/$1";s:9:"page_path";s:8:"/wiki/$1";}} | 0 | a:0:{} [...] 15 | poolwiki | mediawiki | pool | local | en | http:// | com.mypedia.pool. | a:1:{s:5:"paths";a:2:{s:9:"file_path";s:5:"/w/$1";s:9:"page_path";s:8:"/wiki/$1";}} | 0 | a:0:{} I changed site_group "wikipedia" to "mypedia" and added data for site_protocol and site_domain by hand. I noticed that the script path is "/w/$1" here, while $wgScriptPath in LocalSettings.php is actually "/w", could that cause any problems? And should I change site_group of the pool to mypedia like I did with the language wikis or isn't that necessary? Wikibase DataModel 0.8, Wikibase Repository 0.5 alpha, WikibaseLib 0.5 alpha and Wikidata show up in Special:Version of the pool wiki. Wikibase Client 0.5 alpha, Wikibase DataModel 0.8, WikibaseLib 0.5 alpha and Wikidata show up in Special:Version of the language wikis. Any help would be really appreciated! Thanks and cheers, Till

1 1

File descriptions aren't fetched
by Till Kraemer 26 Sep '16

26 Sep '16

Hi, I'm running multiple language wikis and one pool wiki. The problem is that no file descriptions are fetched in the language wikis although $wgFetchCommonsDescriptions is set to true. LocalSettings.php of the language wikis: $wgUseSharedUploads = true; $wgSharedUploadPath = 'http://pool.example.com/w/images'; $wgSharedUploadDirectory = '/path/to/pool/w/images/'; $wgHashedSharedUploadDirectory = true; $wgFetchCommonsDescriptions = true; $wgSharedUploadDBname = 'poolwiki'; # DB-Name of PoolWiki #$wgSharedUploadDBprefix = 'wiki_'; # Table name prefix for PoolWiki $wgRepositoryBaseUrl = "http://pool.example.com/wiki/Image:"; ForeignAPIRepo used to work fine before, but since I switched from Apache to Nginx, no images show up anymore in the language wikis. This is how my LocalSettings.php used to look like: $wgForeignFileRepos[] = array( 'class' => 'ForeignAPIRepo', 'name' => 'pool', 'apibase' => 'http://pool.example.com/w/api.php', 'fetchDescription' => true, // Optional 'descriptionCacheExpiry' => 43200, // 12 hours, optional (values are seconds) 'apiThumbCacheExpiry' => 0, // required for local thumb caching ); I also tried to set 'name' => 'poolwiki', (name of the pool database) but that doesn't work either. I also re-started Memcached and I even deleted a file description page from the CloudFlare cache, but still no file description can be seen :/ My software: MediaWiki: 1.22.0 PHP: 5.3.27 (fpm-fcgi) MySQL: 5.1.70-log Any help would be über-cool. Thanks and cheers, Till

1 3

[BREAKING CHANGE] Upcoming jQuery upgrade: Removing jQuery Migrate
by Krinkle 02 Dec '14

02 Dec '14

Hey all, TL;DR: * We did not make the breaking change last week for Wikimedia; it is postponed. * MediaWiki 1.24.0 will ship with jQuery Migrate switched off. * Wikimedia & non-Wikimedia wikis can enable jQuery Migrate if needed. * When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis. As we said last month, we are upgrading MediaWiki's jQuery to version 1.11.x [1], which removes some long-deprecated functions. These were done in phase one [2] and two [3] as of last week. However, we have held off with phase 3 (removing the jQuery Migrate plugin) for a while to give migration a little more time. The amount of migration work necessary has been much less than I anticipated. Very few scripts have actually needed changing, probably because these features have been deprecated for quite a while now. Some of newer developers may never have even known of these APIs. Having said that, it does take a while for a message like this to spread out to some members of our large community. While those wiki scripts and gadgets which have active maintainers have been looked into, and (where needed) updated accordingly, a large number of gadgets and scripts in the cluster of Wikimedia wikis have not yet had a chance to get a grip on this, let alone extensions and wikis outside of Wikimedia. While I don't want to set another deadline, I think it makes sense to ship the jQuery Migrate plugin for one release (with MediaWiki 1.24), and then remove it in MediaWiki 1.25. This will give all wikis' communities and extension authors a few more months until the MediaWiki 1.24 branch point (in Autumn 2014) before they will need to make adjustments to work with MediaWiki master. MediaWiki 1.24.0 stable will disable support for legacy jQuery by default. If you find you have scripts, gadgets or extensions still using legacy jQuery APIs, you can enable them with a simple line in LocalSettings.php: $wgIncludejQueryMigrate = true; And of course when you find you need to do this, please make an effort to ensure the maintainers of those items still using these legacy features are aware of this so they may patch the code accordingly (using the upgrade guide[4] and my earlier announcement [5]). When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis. — Krinkle [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44740 [2] https://gerrit.wikimedia.org/r/#/c/131494/ [3] https://gerrit.wikimedia.org/r/#/c/133477/ [4] http://jquery.com/upgrade-guide/1.9/ [5] http://www.mail-archive.com/[email protected]/msg75735.html On 7 May 2014, at 18:29, Krinkle <krinklemail(a)gmail.com> wrote: > Hey all, > > TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This > major release removes deprecated functionality. Please migrate away from this > deprecated functionality as soon as possible. > > It's been a long time coming but we're now finally upgrading the jQuery package > that ships with MediaWiki. > > We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple > of years ago due to lack of time and concern about disruption. Because of this, > many developers have needed to work around bugs that were already fixed in later > versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been > the first release in jQuery history that needed an upgrade guide[1][2]. It's a > major release that cleans up deprecated and dubious functionality. > > Migration of existing code in extensions, gadgets, and user & site scripts > should be trivial (swapping one method for another, maybe with a slight change > to the parameters passed). This is all documented in the upgrade guide[1][2]. > The upgrade guide may look scary (as it lists many of your favourite methods), > but they are mostly just addressing edge cases. > > == Call to action == > > This is a call for you, to: > > 1) Get familiar with http://jquery.com/upgrade-guide/1.9/. > > 2) Start migrating your code. > > jQuery v1.9 is about removing deprecated functionality. The new functionality is > already present in jQuery 1.8 or, in some cases, earlier. > > 3) Look out for deprecation warnings. > > Once instrumentation has begun, using "?debug=true" will log jQuery deprecation > warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also > find deprecation notices from mediawiki.js, for more about those see the mail > from last October [8]. > > == Plan == > > 1) Instrumentation and logging > > The first phase is to instrument jQuery to work out all the areas which will > need work. I have started work on loading jQuery Migrate alongside the current > version of jQuery. I expect that to land in master this week [6], and roll out on > Wikimedia wikis the week after. This will enable you to detect usage of most > deprecated functionality through your browser console. Don't forget the upgrade > guide[1], as Migrate cannot detect everything. > > 2) Upgrade and Migrate > > After this, the actual upgrade will take place, whilst Migrate stays. This > should not break anything since Migrate covers almost all functionality that > will be removed. The instrumentation and logging will remain during this phase; > the only effective change at this point is whatever jQuery didn't think was > worth covering in Migrate or were just one of many bug fixes. > > 3) Finalise upgrade > > Finally, we will remove the migration plugin (both the Migrate compatibility > layer and its instrumentation). This will bring us to a clean version of latest > jQuery v1.x without compatibility hacks. > > > A rough timeline: > > * 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This > will run for 4 weeks (until June 9). > > * 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3 > weeks (upto June 9). The instrumentation continues during this period. > > * 1 June 2014 (1.24wmf7) Finalise upgrade. > > > == FAQ == > > Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11? > > A: Those are regular updates that only fix bugs and/or introduce non-breaking > enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any > hassle. We'll be fast-forwarding straight from v1.8 to v1.11. > > > Q: What about the jQuery Migrate plugin? > > A: jQuery developed a plugin that adds back some of the removed features (not > all, consult the upgrade guide[2] for details). It also logs usage of these to > the console. > > > Q: When will the upgrade happen? > > A: In the next few weeks, once we are happy that the impact is reasonably low. > An update will be sent to wikitech-l just before this is done as a final reminder. > This will be well before the MediaWiki 1.24 branch point for extension authors > looking to maintain compatibility. > > > Q: When are we moving to jQuery v2.x? > > A: We are not currently planing to do this. Despite the name, jQuery v2.x > doesn't contain any new features compared to jQuery v1 [3]. The main difference > is in the reduced support for different browsers and environments; most > noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which > MediaWiki is still supporting for now, and is outside the scope of this work. > Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new > features. For example, jQuery released v1.11 and v2.1 together[4][5]. > > -- Krinkle > > [1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- > final-released/ > [2] http://jquery.com/upgrade-guide/1.9/ > [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ > [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ > [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ > [6] https://gerrit.wikimedia.org/r/131494 > [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md > [8] http://www.mail-archive.com/[email protected]/msg72198.html > [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap >

1 1

Images disappearing (recurrent problem), ?memory management
by Dr. Michael Bonert 17 Oct '14

17 Oct '14

I suspect the problem is somewhere in MediaWiki. If knew where I'd be posting it here. - I've stripped away other things on the server. Pretty much the only thing left is the most recent version of MediaWiki (1.23.3) and Debian (stable) packages. - I ran 'debsums' to check whether any of the Debian packages are corrupt. - I am not aware of any LAMP bugs in Debian. The MediaWiki install is near fresh. I did a manual upgrade for version 1.23.1 and then used the patches to get to 1.23.3. The upgrade from 1.23.1 to 1.23.2 had a bug in it-- but I think that was inconsequential. In any case, that upgrade was done July 30, several weeks preceding the problems. Here is a snippet from 'ps aux': ----- USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ... www-data 10518 0.0 2.8 291376 57052 ? S 20:39 0:03 /usr/sbin/apache2 -k start www-data 10567 0.0 2.5 288076 51480 ? S 20:42 0:02 /usr/sbin/apache2 -k start www-data 10568 0.0 2.6 290496 54140 ? S 20:42 0:04 /usr/sbin/apache2 -k start www-data 10569 0.0 2.5 288820 51840 ? S 20:42 0:02 /usr/sbin/apache2 -k start www-data 10570 0.0 2.6 291384 53036 ? S 20:42 0:02 /usr/sbin/apache2 -k start www-data 10571 0.0 2.9 293316 58812 ? S 20:42 0:05 /usr/sbin/apache2 -k start www-data 10572 0.0 2.7 290976 55360 ? S 20:42 0:04 /usr/sbin/apache2 -k start www-data 10573 0.0 2.7 290888 55820 ? S 20:42 0:05 /usr/sbin/apache2 -k start www-data 10649 0.0 2.7 290728 54860 ? S 20:53 0:05 /usr/sbin/apache2 -k start www-data 10650 0.0 2.7 293000 55924 ? S 20:53 0:04 /usr/sbin/apache2 -k start ... ----- The memory seems to be going into apache2. Earlier this morning I rebooted the server. About three hours later the images were gone again. After rebooting this morning... the server has been working okay (so far about 13 hours). I don't understand the cycle: why it breaks in 3 hours... or goes for more than 12. Some ideas I have: 1. Running a 'diff' of my active server against the tarball for the most recent MediaWiki-- to look for corrupted files. 2. At this point I am thinking about the extensions and doing a fresh install of MediaWiki... with the hope that will resolve things. 3. I have bimonthly images going back a year-- I can dump the database, rollback and grab the latest database changes. My inclination is to try #2. It isn't that hard to do... if it works I can be pretty sure it was MediaWiki... and it solves the problem I have at the moment. Any thoughts/ideas are welcome. Michael

3 3

Bug day: Book tool/Collection/PDF, 2014-10-08, 14–22 UTC
by Federico Leva (Nemo) 10 Oct '14

10 Oct '14

Hello, Please join us on the next Wikimedia bug day: **2014-10-08, 14:00–22:00 UTC** [1] in #wikimedia-tech on Freenode IRC.[2] We will be triaging bug reports for the Collection extension (Book tool) in general and PDF export in particular, which were just switched to a new backend (OCG).[3] We have two immediate goals: 1) recover 100 % of the relevant reports from the defunct PediaPress tracker;[4] 2) get a clean list of known PDF issues that the new backend didn't fix. Everyone is welcome to join any time these weeks, and no technical knowledge is needed! It's an easy way to get involved or to give something back. We encourage you to record your activity on the etherpad [4]. This information and more can be found here: https://www.mediawiki.org/wiki/Bug_management/Triage/201410 For more information on triaging in general, check out https://www.mediawiki.org/wiki/Bug_management/Triage I look forward to seeing you there. Please distribute further by email, talk pages etc. (Collection is used on almost 2 thousands wikis!) Sorry for the crossposting, Nemo [1] Timezone converter: http://everytimezone.com/#2014-10-08,120,5x1 [2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC chat [3] http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077867.html [4] https://etherpad.wikimedia.org/BugTriage-Collection

3 5

Search multilingual in one mediawiki
by Grammy Jiang 10 Oct '14

10 Oct '14

Dear all, Sorry for bothering you. I deloy MediaWiki as a content sharing && management platform in my own company, and in company we use both English and Chinese. In mediawiki very beginning configuration page, English is selected as a default language for this MediaWiki, but there will be some pages wrote in Chinese in this MediaWiki. Now my problem is, "Search" function is only working in English, when I input Chinese in the search box, MediaWiki will return nothing! Does MediaWiki support this kind of function, search in multilingual in the same one MediaWiki? Do i miss any settings? If not, is there any MediaWiki Extension may help? Many thanks! Best regards, Grammy Jiang Qingdao Create Future Environment Protection Technology Consultancy Co., Ltd Room 6-11, Building B, International Innovation Park, Songling Road, Laoshan District, Qingdao City, China

2 2

Reset MediaWiki password without email
by Tongjie Li 03 Oct '14

03 Oct '14

hi,all I have a question of how to reset MediaWiki password without email.I post it in stackoverflow, but maybe it is be better asked here. We set up a MediaWiki server for organizing docs.One of our customers forget his password.We need to reset the password for him. In the MediaWiki docs <http://www.mediawiki.org/wiki/Manual:Resetting_passwords> ,there are three ways to do it: First is to reset by email. Since we do not have a mail server,we can't done with it. Second is using changePassword.php, we try it. But we found other account can be changed successfully,but not this account. After the script runs, the new password is still not working. Third is using direct database modification,since our version is 1.22. still other account can be changed, but not this account. After update the database,the user cannot login in with new password. sql as foolow: UPDATEuserSET user_password = CONCAT(':B:somesalt:', MD5(CONCAT('somesalt-', MD5('somepass')))) WHERE user_name = 'someuser'; We have no idea why is this happen? Will be MediaWiki bug? Is there any log that I can check? Is anyone have a idea? thank you very much! -- All the Best! Li Tongjie

2 1

MediaWiki Language Extension Bundle 2014.09 release
by Kartik Mistry 29 Sep '14

29 Sep '14

Hello all, I would like to announce the release of MediaWiki Language Extension Bundle 2014.09. This bundle is compatible with MediaWiki 1.23.x and MediaWiki 1.22.x releases. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.09.tar… * sha256sum: 9cfdc7d4fc87b4cd6f8d1d2e1593b8cd064b7a9a2773c1a6a554304949a609ec Quick links: * Installation instructions are at: https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to: https://bugzilla.wikimedia.org * Talk with us at: #mediawiki-i18n @ Freenode Release notes for each extension are below. -- Kartik Mistry == Babel and CleanChanges == * Only localisation updates. == CLDR == === Noteworthy changes === * Update to CLDR 26 (Upstream: http://cldr.unicode.org/index/downloads/cldr-26) ==== Changes ==== * Removed entries from LocalNamesEn.php when identical to CLDR. Right now, 13 local names are differing from CLDR's, as well as the other languages, are left to follow-ups. == LocalisationUpdate == === Noteworthy changes === * Bug 68781: New hook LocalisationCacheRecacheFallback in MediaWiki 1.24 and above allows to not use the wrong message when a language itself doesn't have a change but one of its fallbacks does. == Translate == === Noteworthy changes === * Regression fixed: Translate's compatibility with MediaWiki 1.22 has been restored. * Regression fixed: Fix translation ratios in translatable page language selector. * Special:MyLanguage is now in core. For backwards compatibility, translations of Special:MyLanguage aliases were moved to a separate file (Bug 69461). * Bug 67778: Added UserMerge support. * $wgTranslatePageTranslationULS now works as intended on all translation pages by removing the language code from the page name. == UniversalLanguageSelector == === Noteworthy changes === * Update ULS data with latest supplementalData.xml from CLDR. -- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

1 0

Every non-existing article ín brand new Namespace redirect to default namespace
by Henrik Rasmussen 29 Sep '14

29 Sep '14

I created*) a new namespace "historisk", as an archive for articles which are no longer relevant, but kept for historical reasons. define("NS_FOO", 500); define("NS_FOO_TALK", 501); $wgExtraNamespaces[NS_HISTORISK] = "Historisk"; $wgExtraNamespaces[NS_HISTORISK_TALK] = "Historisk_talk"; // underscore required. use it to separate all words in the title of namespace $wgContentNamespaces[] = 500; But I must be missing something since "[[historisk:newarticle]]" (no articles exist in that extranamespaces yet and it happens no matter which articlename I enter) keeps redirecting to "[[newarticle]]" prior to the first edit, right after I enter the URL *) http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces Did I miss something obvious or otherwise? Henrik Rasmussen

5 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l September 2014