Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2019.04. This bundle is The bundle is compatible with MediaWiki
1.31 and 1.32 or above and requires PHP 5.5.9 or above.
Next MLEB is expected to be released in 3 months. If there are major
changes or important bug fixes, we will do intermediate release.
Please give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2019.04.tar…
* sha256sum: 5fbbd39acd1cc0e1edbd542a390daf1992d1526134ceb69248cdb4dced58f3a9
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2019.04.tar…
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://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Highlights and upgrade notes ==
== Babel ==
* Maintenance and localization updates only.
== CleanChanges and cldr ==
* PHP entry point has been removed. Warning will be displayed for
deprecated PHP entry point. (T140007)
* Maintenance and localization updates.
== LocalisationUpdate ==
* Maintenance updates only.
== Translate ==
=== Noteworthy changes ===
* Fixed fatal error on PageContentLanguage hook subscriber (T214358)
* Replaced usage of mw.translateHooks with mw.hook. Deprecation
warning will be shown while using functions under mw.translateHooks
(T72031)
* Added support for newer versions of the Elastica extension while
maintaining backward compatibility for older version REL 1.31
(T218100)
* Fixed page suggestion control on Special:PageMigration (T217726)
* Fixed broken Special:PageMigration (T217727)
* Add link to Special:PageMigration when page is marked for
translation (T178642)
* Removed display of the message group state for the source language (T160511)
* Fixed invalid display of priority language notice (T217046)
* Added better error handling in Special:SearchTranslations (T159221)
*Display proper notice when translations to non-priority languages are
blocked (T218777)
*Fixed "proofreading" status appearing for source language on the
MessageGroup and Language stats page (T160511)
== UniversalLanguageSelector ==
* Various performance fixes.
* Maintenance and localization updates.
==== Input Methods ====
* New tilde-based layouts for several languages of Africa: Kabyle,
Kabiye, Kikuyu, Luganda, Lingala, Malagasy, Northern Sotho, Koyraboro
Senni, Sango, Sotho, Venda.
* Added Latin Pinyin transliteration keyboard
==== Fonts ====
* Added fonts for Church Slavonic. (T156843)
--
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com
Hello Hive Mind,
I am looking at implementing a Knowledge base, Source Code Manager and Version Controller into our business area. Currently we are using a shared drive to store our files and any other 'notes' we come along. I found it to be too inefficient and not practical in a professional environment where real work needs to be done.
I have been looking at several options and one of our base requirements to get software into our scif is it needs to be PL-3 compliant:
https://fas.org/irp/offdocs/DCID_6-3_20Manual.htm#4b3
My question, does MediaWiki comply with PL-3?
Thank you,
Chris H.
After updating MediaWiki, PHP, and MySQL, I'm fairly consistently getting
php-fpm worker crashes when I try to edit articles on my wiki.
I think I can rule out database corruption. mysql_check says everything is OK,
and even after dropping the database and restoring from a mysqldump backup,
the crashes continue.
I've enabled error reporting & logging in php.ini, php-fpm.conf, and my.cnf.
The MySQL log reveals that the crash, if it happens (it doesn't always) is
always right after a certain MySQL query runs. Meanwhile, php_error.log says
nothing (but is working), and php-fpm.log says nothing of note, just "[pool
www] child 17491 exited on signal 11 (SIGSEGV - core dumped) after 0.000125
seconds from start".
After adjusting some kernel settings and rebuilding PHP with --enable-debug, I
managed to finally get some core dumps with symbols. Using gdb, I saw in one
of them that it looks like pcre could be to blame:
---------------------------------------------------------------------------
[...]
Reading symbols from /usr/local/sbin/php-fpm...done.
[New LWP 100226]
Core was generated by `php-fpm: pool www'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x26641354 in ?? ()
(gdb) bt
#0 0x26641354 in ?? ()
#1 0x2065b634 in ?? () from /usr/local/lib/libpcre.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
---------------------------------------------------------------------------
However, even after updating pcre, PHP and all its extensions, and nginx, the
crashes persist, again at the same spot. And now, for some reason, the
backtrace is no longer mentioning pcre by name:
---------------------------------------------------------------------------
[...]
Reading symbols from /usr/local/sbin/php-fpm...done.
[New LWP 100136]
Core was generated by `php-fpm: pool www'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x268b5412 in ?? ()
(gdb) bt
#0 0x268b5412 in ?? ()
#1 0x26564d64 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
---------------------------------------------------------------------------
Anyway, here is the last message in the MySQL log just before the crash:
---------------------------------------------------------------------------
SELECT /* LCStoreDB::get */ lc_value FROM `mw_l10n_cache` WHERE lc_lang = 'en' AND lc_key = 'magicWords' LIMIT 1
---------------------------------------------------------------------------
And here is what the next message is, those times when there is no crash:
---------------------------------------------------------------------------
SELECT /* WikiPage::pageData */ page_id,page_namespace,page_title,page_restrictions,page_is_redirect,page_is_new,page_random,page_touched,page_links_updated,page_latest,page_len,page_content_model FROM `mw_page` WHERE page_namespace = '2' AND page_title = 'Mjb/FreeBSD_on_BeagleBone_Black/Additional_software' LIMIT 1;
---------------------------------------------------------------------------
Both of these queries are benign; I can run them from the MySQL client or from
a simple PHP CGI test webpage with no problem.
Does anyone have any idea what could be going wrong or how to further
diagnose?
Thanks,
Mike
(Info about my system follows:)
---------------------------------------------------------------------------
FreeBSD 12.0-RELEASE-p3 running on a BeagleBone Black.
The MySQL connections are via sockets, not TCP.
selected output from 'pkg info':
mediawiki132-php72-1.32.0 Wiki engine used by Wikipedia
mysql57-client-5.7.25 Multithreaded SQL database (client)
mysql57-server-5.7.25 Multithreaded SQL database (server)
nginx-1.14.2_13,2 Robust and small WWW server
pcre-8.43_1 Perl Compatible Regular Expressions library
php72-7.2.17_2 PHP Scripting Language
php72-ctype-7.2.17_2 The ctype shared extension for php
php72-curl-7.2.17_2 The curl shared extension for php
php72-dom-7.2.17_2 The dom shared extension for php
php72-fileinfo-7.2.17_2 The fileinfo shared extension for php
php72-hash-7.2.17_2 The hash shared extension for php
php72-iconv-7.2.17_2 The iconv shared extension for php
php72-intl-7.2.17_2 The intl shared extension for php
php72-json-7.2.17_2 The json shared extension for php
php72-mbstring-7.2.17_2 The mbstring shared extension for php
php72-mysqli-7.2.17_2 The mysqli shared extension for php
php72-opcache-7.2.17_2 The opcache shared extension for php
php72-openssl-7.2.17_2 The openssl shared extension for php
php72-pcntl-7.2.17_2 The pcntl shared extension for php
php72-pdo-7.2.17_2 The pdo shared extension for php
php72-pdo_mysql-7.2.17_2 The pdo_mysql shared extension for php
php72-posix-7.2.17_2 The posix shared extension for php
php72-readline-7.2.17_2 The readline shared extension for php
php72-session-7.2.17_2 The session shared extension for php
php72-xml-7.2.17_2 The xml shared extension for php
php72-xmlreader-7.2.17_2 The xmlreader shared extension for php
php72-xmlrpc-7.2.17_2 The xmlrpc shared extension for php
php72-zlib-7.2.17_2 The zlib shared extension for php
---------------------------------------------------------------------------
Hello all,
It's coming close to time for annual appointments of community members to
serve on the Code of Conduct (CoC) committee. The Code of Conduct Committee
is a team of five trusted individuals plus five auxiliary members with
diverse affiliations responsible for general enforcement of the Code of
conduct for Wikimedia technical spaces. Committee members are in charge of
processing complaints, discussing with the parties affected, agreeing on
resolutions, and following up on their enforcement. For more on their
duties and roles, see
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee
<http://meta.wikimedia.org/wiki/Ombudsman_commission>
This is a call for community members interested in volunteering for
appointment to this committee. Volunteers serving in this role should be
experienced Wikimedians or have had experience serving in a similar
position before.
The current committee is doing the selection and will research and discuss
candidates. Six weeks before the beginning of the next Committee term,
meaning 23th of April 2019, they will publish their candidate slate (a list
of candidates) on-wiki. The community can provide feedback on these
candidates, via private email to the group choosing the next Committee. The
feedback period will be two weeks. The current Committee will then either
finalize the slate, or update the candidate slate in response to concerns
raised. If the candidate slate changes, there will be another two week
feedback period covering the newly proposed members. After the selections
are finalized, there will be a training period, after which the new
Committee is appointed. The current Committee continues to serve until the
feedback, selection, and training process is complete.
If you are interested in serving on this committee or like to nominate a
candidate, please write an email to techconductcandidates AT wikimedia.org
with details of your experience on the projects, your thoughts on the code
of conduct and the committee and what you hope to bring to the role and
whether you have a preference in being auxiliary or constant member of the
committee. The committee consists of five members plus five auxiliary
members and they will serve for a year; all applications are appreciated
and will be carefully considered. The deadline for applications is end of
day on 20th of April, 2019.
Please feel free to pass this invitation along to any users who you think
may be qualified and interested.
Best,
Amir on behalf of the CoC committee
unsubscribe
________________________________
From: MediaWiki-l <mediawiki-l-bounces(a)lists.wikimedia.org> on behalf of mediawiki-l-request(a)lists.wikimedia.org <mediawiki-l-request(a)lists.wikimedia.org>
Sent: Saturday, April 13, 2019 5:00 AM
To: mediawiki-l(a)lists.wikimedia.org
Subject: MediaWiki-l Digest, Vol 187, Issue 9
Send MediaWiki-l mailing list submissions to
mediawiki-l(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
or, via email, send a message with subject or body 'help' to
mediawiki-l-request(a)lists.wikimedia.org
You can reach the person managing the list at
mediawiki-l-owner(a)lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MediaWiki-l digest..."
Today's Topics:
1. Certifications and Protection Levels (Herzog, Christopher J)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Apr 2019 20:32:05 +0000
From: "Herzog, Christopher J" <christopher.j.herzog(a)lmco.com>
To: "mediawiki-l(a)lists.wikimedia.org"
<mediawiki-l(a)lists.wikimedia.org>
Subject: [MediaWiki-l] Certifications and Protection Levels
Message-ID: <1090c09bc188474eab25b81e7ecd7906(a)lmco.com>
Content-Type: text/plain; charset="us-ascii"
Hello Hive Mind,
I am looking at implementing a Knowledge base, Source Code Manager and Version Controller into our business area. Currently we are using a shared drive to store our files and any other 'notes' we come along. I found it to be too inefficient and not practical in a professional environment where real work needs to be done.
I have been looking at several options and one of our base requirements to get software into our scif is it needs to be PL-3 compliant:
https://fas.org/irp/offdocs/DCID_6-3_20Manual.htm#4b3
My question, does MediaWiki comply with PL-3?
Thank you,
Chris H.
------------------------------
Subject: Digest Footer
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
------------------------------
End of MediaWiki-l Digest, Vol 187, Issue 9
*******************************************
<mediawiki-l-request(a)lists.wikimedia.org> 於 2019年4月10日週三 20:03 寫道：
> Send MediaWiki-l mailing list submissions to
> mediawiki-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> or, via email, send a message with subject or body 'help' to
> mediawiki-l-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> mediawiki-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MediaWiki-l digest..."
>
>
> Today's Topics:
>
> 1. Re: update.php failing with message from LoadBalancer.php
> (Mike Brown)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 9 Apr 2019 05:49:19 -0700
> From: Mike Brown <mike(a)hyperreal.org>
> To: mediawiki-l(a)lists.wikimedia.org
> Subject: Re: [MediaWiki-l] update.php failing with message from
> LoadBalancer.php
> Message-ID: <20190409124919.GA61091(a)taz4.hyperreal.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Apr 06, 2019 at 11:38:04PM -0700, Mike Brown wrote:
> > [3f3634afa8a03289878f8ff9] [no req] Wikimedia\Rdbms\DBQueryError from
> line 1496 of
> /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php: A
> database query error has occurred. Did you forget to run your application's
> database schema updater after upgrading?
> > Query: UPDATE `mw_archive` SET ar_rev_id = '3867' WHERE ar_id = '940'
> > Function: PopulateArchiveRevId::reassignArRevIds
> > Error: 1785 Statement violates GTID consistency: Updates to
> non-transactional tables can only be done in either autocommitted
> statements or single-statement transactions, and never in the same
> statement as updates to transactional tables. (localhost)
>
> This happened because I was upgrading a MySQL-based wiki installation
> which
> had MyISAM instead of InnoDB tables. I altered the tables (except
> searchindex)
> to use the InnoDB engine, and then update.php was able to run to
> completion.
>
> Perhaps update.php should be fixed to deal with this contingency.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
> ------------------------------
>
> End of MediaWiki-l Digest, Vol 187, Issue 7
> *******************************************
>
I'm upgrading a MediaWiki 1.30 installation to 1.32.
I already updated my backend from MySQL 5.6.40 to 5.7.25 and ran
mysql_upgrade. I also replaced PHP 5.6.36 with PHP 7.2.17.
I installed MW 1.32.0 and am now trying to run the update.php script in the
maintenance directory. I get the following error:
MediaWiki 1.32.0 Updater
Your composer.lock file is up to date with current dependencies!
[20cebd8c9a3916038d1b3632] [no req] UnexpectedValueException from line 961 of /usr/local/www/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php:
Got connection to 'OffsetDB-mw_', but expected local domain ('OffsetDB-mediawiki-mw_').
Backtrace:
#0 /usr/local/www/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(890): Wikimedia\Rdbms\LoadBalancer->openLocalConnection(integer, integer)
#1 /usr/local/www/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(766): Wikimedia\Rdbms\LoadBalancer->openConnection(integer, boolean, integer)
#2 /usr/local/www/mediawiki/includes/GlobalFunctions.php(2694): Wikimedia\Rdbms\LoadBalancer->getConnection(integer, array, boolean)
#3 /usr/local/www/mediawiki/maintenance/Maintenance.php(1353): wfGetDB(integer, array, boolean)
#4 /usr/local/www/mediawiki/maintenance/update.php(147): Maintenance->getDB(integer)
#5 /usr/local/www/mediawiki/maintenance/doMaintenance.php(94): UpdateMediaWiki->execute()
#6 /usr/local/www/mediawiki/maintenance/update.php(248): require_once(string)
#7 {main}
My db config vars haven't changed. Nothing too bizarre...
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "OffsetDB";
$wgDBport = "5432";
$wgDBprefix = "mw_";
How can I get past the error? Or let me know what other info to provide to
help diagnose. Thanks!