Talk:MediaWiki Language Extension Bundle/Archive 2

The new addition states:

We may drop support for EOL versions of PHP, but will have at least one compatible version for each MediaWiki version we support.

Could this be modified so that support can be dropped only for PHP versions not supported by the current stable MediaWiki version (but supported by the previous one)? In the current wording, it may pose stricter requirements on users than usual extensions, which have release branches, while in my understanding, the compatibility policy is about posing less strict requirements on users. It would even allow entirely dropping PHP 7 support in the 2023.07 release (by that time MediaWiki 1.40 should be released), even though for example Debian 12 may not have been released at that point, meaning that no supported Debian release would contain a PHP version supported by MLEB (Debian 11 contains only 7.4).

Thanks for your thoughts. MLEB is indeed additional service on top of what MediaWiki generally provides. We need to consider the effort of providing this service compared to the value it provides to us and its users.

The costs are mainly additional testing (unavoidable), extra effort for making most changes backwards compatible (we have made exceptions for new features) and benefits not reaped from using newer PHP language or MediaWiki core features.

Additionally, these costs affect other developers too, those who want to make changes to these extensions, not just the Language team.

In this case, the motivation for dropping support for PHP 7.3 was that MediaWiki was essentially claiming to support 7.4 only, but kept support for 7.3 because WMF still used it. Additionally, PHP 7.4 is widely available, so the impact for dropping support for 7.3 should be low. PHP 7.4 brings a bunch of improvements and new features that made it compelling to drop support for 7.3.

The wording is rather lax, to give us flexibility on making these trade-offs case-by-case. I am not expecting us to completely drop PHP 7 support very soon.

Having installed MLEB 2021.12 (MediaWiki 1.35.5), when I upgrade Universal Language Selector to Git master because of security issue T293749, CVE-2021-46149 (//gerrit.wikimedia.org/r/q/Ide32704cca578b9aecbce34bdcc0ac25c2a09a4d), I get this error:

Original exception: /index.php?title=Special:Version Error from line 236 of /mediawiki/extensions/UniversalLanguageSelector/includes/Hooks.php: Using $this when not in object context

Backtrace:

#0 /mediawiki/includes/HookContainer/HookContainer.php(329): UniversalLanguageSelector\Hooks::onPersonalUrls()

#1 /mediawiki/includes/HookContainer/HookContainer.php(132): MediaWiki\HookContainer\HookContainer->callLegacyHook()

#2 /mediawiki/includes/HookContainer/HookRunner.php(3084): MediaWiki\HookContainer\HookContainer->run()

#3 /mediawiki/includes/skins/SkinTemplate.php(656): MediaWiki\HookContainer\HookRunner->onPersonalUrls()

#4 /mediawiki/includes/skins/SkinTemplate.php(392): SkinTemplate->buildPersonalUrls()

#5 /mediawiki/includes/skins/SkinTemplate.php(127): SkinTemplate->prepareQuickTemplate()

#6 /mediawiki/includes/skins/SkinTemplate.php(144): SkinTemplate->generateHTML()

#7 /mediawiki/includes/OutputPage.php(2622): SkinTemplate->outputPage()

#8 /mediawiki/includes/MediaWiki.php(952): OutputPage->output()

#9 /mediawiki/includes/MediaWiki.php(965): MediaWiki->{closure}()

#10 /mediawiki/includes/MediaWiki.php(548): MediaWiki->main()

#11 /mediawiki/index.php(53): MediaWiki->run()

#12 /mediawiki/index.php(46): wfIndexMain()

#13 {main}

Master branch does not support 1.35. Please use the latest version of REL1_35 branch or the 2021.12 MLEB tag, both of which include the fix for the vulnerability.

This issue would affect future MLEB release, though, so I created a task to address it before a release: https://phabricator.wikimedia.org/T299305

Revisions from prior October 2019 are showing more recent or current versions of the page. For example

https://www.mediawiki.org/w/index.php?title=MediaWiki_Language_Extension_Bundle&oldid=3243449

It's also unacceptable that links to the meiawiki itself are not whitelisted from abusefilter-linkspam guards.

Revisions from prior October 2019 are showing more recent or current versions of the page. For example https://www.mediawiki.org/w/index.php?title=MediaWiki_Language_Extension_Bundle&oldid=3243449

That's because the page is using the {{/releases}} wikitext transclusion construction, which doesn't respect page versioning. The equivalent version of the transcluded page would be this one.

It's also unacceptable that links to the meiawiki itself are not whitelisted from abusefilter-linkspam guards.

I'm sorry, I don't know what you're saying?

> That's because the page is using the Template:/releases wikitext transclusion construction, which doesn't respect page versioning.

That to me is a horrible documentation practice. Is this subpage/transclusion now a 'thing' with MW extensions? Thanks for finding the equivalent for me!

> It's also unacceptable that links to the meiawiki itself are not whitelisted from abusefilter-linkspam guards.

That's a complaint I should direct toward mediawiki.org. Nevermind. I tried to post the comment anonymously, which failed due to the inclusion of the link.

One more additional point: somewhere in the /installation documentation, it should be noted that 'rebuildLocalisation' should be run in the case of static lang-cache installations. Otherwise, the babel keyword won't be found and you'll get a horrible exception.

> That's because the page is using the Template:/releases wikitext transclusion construction, which doesn't respect page versioning. That to me is a horrible documentation practice. Is this subpage/transclusion now a 'thing' with MW extensions? Thanks for finding the equivalent for me!

Yeah, it's a mess, I agree. I don't think it's a common practice, no. This page is very unusual, as it's about a bundle of extension released as a tarball together rather than the normal individual manner.

> It's also unacceptable that links to the meiawiki itself are not whitelisted from abusefilter-linkspam guards. That's a complaint I should direct toward mediawiki.org. Nevermind. I tried to post the comment anonymously, which failed due to the inclusion of the link.

Oh, right. Sorry about that!

One more additional point: somewhere in the /installation documentation, it should be noted that 'rebuildLocalisation' should be run in the case of static lang-cache installations. Otherwise, the babel keyword won't be found and you'll get a horrible exception.

Oh. In my innocence, I had assumed that anything like that would be run by update.php; that certainly sounds like it should be added, yes.

MediaWiki internal error.

Original exception: [Xhynhn8RCN6g4AKfQjl5bwAAADo] /index.php/Main_Page Wikimedia\Rdbms\DBQueryError from line 1603 of /home/vol9_6/epizy.com/epiz_25047816/htdocs/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: SELECT rt_revision FROM `mwmw_revtag` WHERE rt_page = '1' AND rt_type = 'tp:mark' ORDER BY rt_revision DESC LIMIT 1

Function: TranslatablePage::getTag

Error: 1146 Table 'epiz_25047816_69.mwmw_revtag' doesn't exist (sql200.byetcluster.com)

Backtrace:

#0 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/Database.php(1574): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)

#1 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/Database.php(1152): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)

#2 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/Database.php(1807): Wikimedia\Rdbms\Database->query(string, string)

#3 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/Database.php(1644): Wikimedia\Rdbms\Database->select(string, string, array, string, array, array)

#4 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->selectField(string, string, array, string, array)

#5 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/DBConnRef.php(302): Wikimedia\Rdbms\DBConnRef->__call(string, array)

#6 /home/vol9_6/epizy.com/epiz_25047816/htdocs/extensions/Translate/tag/TranslatablePage.php(616): Wikimedia\Rdbms\DBConnRef->selectField(string, string, array, string, array)

#7 /home/vol9_6/epizy.com/epiz_25047816/htdocs/extensions/Translate/tag/TranslatablePage.php(558): TranslatablePage->getTag(string)

#8 /home/vol9_6/epizy.com/epiz_25047816/htdocs/extensions/Translate/tag/PageTranslationHooks.php(937): TranslatablePage->getMarkedTag()

#9 /home/vol9_6/epizy.com/epiz_25047816/htdocs/extensions/Translate/tag/PageTranslationHooks.php(925): PageTranslationHooks::sourcePageHeader(RequestContext)

#10 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/Hooks.php(174): PageTranslationHooks::translatablePageHeader(Article, boolean, boolean)

#11 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)

#12 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/page/Article.php(693): Hooks::run(string, array)

#13 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/actions/ViewAction.php(63): Article->view()

#14 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/MediaWiki.php(511): ViewAction->show()

#15 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/MediaWiki.php(302): MediaWiki->performAction(Article, Title)

#16 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/MediaWiki.php(900): MediaWiki->performRequest()

#17 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/MediaWiki.php(527): MediaWiki->main()

#18 /home/vol9_6/epizy.com/epiz_25047816/htdocs/index.php(44): MediaWiki->run()

#19 {main}

Exception caught inside exception handler: [Xhynhn8RCN6g4AKfQjl5bwAAADo] /index.php/Main_Page Wikimedia\Rdbms\DBQueryError from line 1603 of /home/vol9_6/epizy.com/epiz_25047816/htdocs/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: SELECT rt_page FROM `mwmw_revtag`,`mwmw_page` WHERE (rt_page = page_id) AND (rt_revision = page_latest) AND rt_type IN ('tp:mark','tp:tag') GROUP BY rt_page

Function: TranslatablePage::getTranslatablePages

Error: 1146 Table 'epiz_25047816_69.mwmw_revtag' doesn't exist (sql200.byetcluster.com)

Backtrace:

#0 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/Database.php(1574): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)

#1 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/Database.php(1152): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)

#2 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/rdbms/database/Database.php(1807): Wikimedia\Rdbms\Database->query(string, string)

#3 /home/vol9_6/epizy.com/epiz_25047816/htdocs/extensions/Translate/tag/TranslatablePage.php(893): Wikimedia\Rdbms\Database->select(array, string, array, string, array)

#4 /home/vol9_6/epizy.com/epiz_25047816/htdocs/extensions/Translate/tag/TranslatablePage.php(869): TranslatablePage::getTranslatablePages()

#5 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/objectcache/wancache/WANObjectCache.php(1424): TranslatablePage::{closure}(boolean, integer, array, NULL)

#6 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/libs/objectcache/wancache/WANObjectCache.php(1278): WANObjectCache->fetchOrRegenerate(string, integer, Closure, array)

#7 /home/vol9_6/epizy.com/epiz_25047816/htdocs/extensions/Translate/tag/TranslatablePage.php(871): WANObjectCache->getWithSetCallback(string, integer, Closure, array)

#8 /home/vol9_6/epizy.com/epiz_25047816/htdocs/extensions/Translate/tag/PageTranslationHooks.php(1104): TranslatablePage::isSourcePage(Title)

#9 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/Hooks.php(174): PageTranslationHooks::replaceSubtitle(string, SkinVector, OutputPage)

#10 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)

#11 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/skins/Skin.php(782): Hooks::run(string, array)

#12 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/skins/SkinTemplate.php(278): Skin->subPageSubtitle()

#13 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/skins/SkinTemplate.php(215): SkinTemplate->prepareQuickTemplate()

#14 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/OutputPage.php(2574): SkinTemplate->outputPage()

#15 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/exception/MWExceptionRenderer.php(134): OutputPage->output()

#16 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/exception/MWExceptionRenderer.php(53): MWExceptionRenderer::reportHTML(Wikimedia\Rdbms\DBQueryError)

#17 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/exception/MWExceptionHandler.php(121): MWExceptionRenderer::output(Wikimedia\Rdbms\DBQueryError, integer)

#18 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/exception/MWExceptionHandler.php(195): MWExceptionHandler::report(Wikimedia\Rdbms\DBQueryError)

#19 /home/vol9_6/epizy.com/epiz_25047816/htdocs/includes/MediaWiki.php(558): MWExceptionHandler::handleException(Wikimedia\Rdbms\DBQueryError)

#20 /home/vol9_6/epizy.com/epiz_25047816/htdocs/index.php(44): MediaWiki->run()

#21 {main}

Did you run update.php?

Instead of providing extensions into a bundle, could be interesting to have a ready to install complete version of updated Mediawiki with pre-installed extensions provided with an installer to make a clone of a Wikipedia multilingual site

This is not in scope of our work.

When I tried to upload these it looks like LocalisationUpdate already exists? It is however not shown in the Specialpages:Version? Can anyone explain, do I need to add this in localsettings.php ?

wfLoadExtension( 'LocalisationUpdate' );

$wgLocalisationUpdateDirectory = "$IP/cache";

If you took the MediaWiki tarball, it includes some most often used extensions, including LocalisationUpdate. But it doesn't enable or configure them by default.

Thanks - I was just confused by this (thinking that I had broken everything), LocalisationUpdate does not appear in the special:version pages.

It would be kind of cool if there was an "unused" Extensions function? That could be done neatly, by using the version and gitinfo.json files. With a bit of work the Extension install process could be in a template and automated... if only I had the time!

That bundle is really impressive, and all seems to work well on my wiki. Made some translations without problems.
My only concern is... the translated pages doesn't display by default in the language set by the user.
i.e. if a Russian user come on my english wiki, has set "Russian" in his language Preferences, and reads a page that has a translated subpage /ru, shouldn't the wiki displays that /ru page first for him?
Maybe I'm missing a parameter? Thanks for any advice.

Due to complicated reasons it is hard to automatically redirect users to their language. But you can use Special:MyLanguage/Pagename to create such links that will redirect to that version (if it exists).

Hi, when I include parameter (" $ IP /extensions/Translate/Translate.php" ;) in LocalSettings.php, my Wiki is not working. Downloaded the latest version from 2018.10

Can you describe how it is not working? Error messages? Blank page? Make sure that those spaces inside "" are not actually there.

I find the TranslationNotifications pretty useful and I wonder why this is not included in MLEB. Well there is probably a reason, but ... ;) I personally find it more useful than e.g. CleanChanges. Not saying that the latter is less useful. However in the translation context...

No particular reason I suppose. Perhaps I thought that no other wiki has such amount of translators that it would be useful. I have to say though that the extension is not well maintained and has severe issues.

Thanks for reminding about CleanChanges... I should propose dropping it from the bundle.

Fair enough, though I think it is also very much useful if you have a wiki with little but irregular appearing translatable content or with irregular appearing translators.

"not well maintained and has severe issues". This scares me a bit now. If you think that it should not be used in production ...

It's probably fine for your wiki, have look at Phabricator. It has some issues sending notices to a lot of recipients.

Yeah, I have a maximum of about 10 translators. I am somewhat relieved now. Indeed this extension needs some love when looking at phabricator.

MediaWiki_Language_Extension_Bundle/installation has been updated.

Under "Add/update your LocalSettings.php" it states "Near the end, you have to place the configuration lines given above (pick from one of the two sections)..."

To what "configuration lines given above" are they referencing? It could just be user error, but I don't see what it's talking about. Please help?

Thanks!

So think I realized what they are talking about. For those who are confused like me.

You can either copy the instructions from each extension into your LocalSettings.php file - so for example: when you are installing Babel, can go to Babel's instructions and copy wfLoadExtension( 'Babel' ); into your LocalSettings.php file . . . and do that for each of the extensions in the bundle. (Doing this is considered the first section that you could pick from, when it says "(pick from one of the two sections)").

OR

You can simply copy the instructions they give under the "Add/update your LocalSettings.php" header - the instructions which includes all of the lines-of-code you need to put in your LocalSettings.php. (Doing this is considered the second section that you could pick from, when it says "(pick from one of the two sections)").

There used to be two ways to define $EXT, which is no longer needed with wfLoadExtension()