Extension talk:LocalisationUpdate

Some comments

+siebrand> LocalisationUpdate.php should be smaller, and you should lazy load from class files.
+Nikerabbit> the sql should probably be hooked to LoadExtensionSchemaUpdates, it doesn't seem to support table prefixes
+Nikerabbit> I also don't like that it creates a new entry point, either write a command line scripts, a special page or both
+Nikerabbit> how does it determine which updates are compatible and which are not?
+Nikerabbit> $query = "select value from localisation where identifier = '".$db->strencode($lckey)."' and language = '".$db->strencode($langcode)."'";
+Nikerabbit> we have nice $db->select() for this :)
+Nikerabbit> I also see some code duplication there

– Nikerabbit 07:25, 20 May 2009 (UTC)

update database

• when a message is changed or removed from the local messagefile (in English) will the localisation be removed from the database ?
• when a message is changed in SVN, will the localisation be saved for as long as the local message has not changed ?

Thanks, GerardM 22:27, 20 May 2009 (UTC)

two issues left

I have been asked by Naoko to write the two issues that need some more work.

• The performance of the software took a hit when some work was done to make the software more safe.
  • Tom's plan is to talk to Brion and ask for his advise
• When a language known in the Names.php is new to the localisation of an extension, it needs to be introduced in the database.

Thanks, GerardM 07:53, 22 July 2009 (UTC)

Get errors when run update script

When I ran php extensions/LocalisationUpdate/update.php on the command line, I got the following errors:

PHP Catchable fatal error:  Argument 4 passed to LocalisationUpdate::compareFiles() must be an array, boolean given, called in /srv/www/w.ray.io/public_html/extensions/LocalisationUpdate/LocalisationUpdate.class.php on line 163 and defined in /srv/www/w.ray.io/public_html/extensions/LocalisationUpdate/LocalisationUpdate.class.php on line 305

--Sparanoid 07:44, 12 September 2011 (UTC)

Assistance needed: LocalisationUpdate on a wiki family

I recently did a major transition from standalone MW installations to shared resources ones. I have 7 wikis so it took me a lot of time to administer them all, plus, they took a lot of space. Since they are all in the same server I did a "Scenario 4" setup. First I updated all to most recent MW version (1.21.2). Then I created a separate dir called "common" and put there all extensions from all wikis (each one has a different compilation of extensions; they are not a real family, just some wikis in the same server). In the same dir I also put the bin, docs, includes, languages, maintenance, resourses, skins and tests dirs. Then I created symbolic links for all the moved dirs. For example, in /wiki1/wiki/ I have deleted extensions dir and created a symbolic link called "extensions" that points to /common/extensions. And so on. This approach saved me 2 Gb of space and 50$/year. But now I don't know what will happen if I run LocalisationUpdate because I am not sure how it works and I am also not very familiar with linux.

My guess is that LU will run with no issues. My guess is that it will try to update, for example, the "Poem" extension so it will try to update files inside wiki/extensions/Poem dir but through the symbolic link it will go to common/extensions/Poem and update those files there instead. And it will do this for all files in wiki1. Then, in wiki2, it will go again to common/extensions/Poem dir only to find that these files are updated so it will skip them and update only wiki2 extensions that don't exist in wiki1. And so on.

Can someone please confirm (or invalidate) my reasoning? All wikis are live and I don't want to conduct experiments on them. And if this way described above is wrong, then what is the proper way to use LU with a wiki family? I know that the Wikimedia family has a much more complicated setup than the one described above and still uses LU to update. So how can this be done?

P.S.: The funny thing is that just a few days ago I had just finished creating cron jobs with LU so as all wiki messages be up to date every day!

P.S.2: LU is essensial to me since I am a very active translator in translatewiki and I proofread and correct messages all the time.

--Ioannis Protonotarios 12:16, 14 September 2013 (UTC)

In 1.21.2 blocks wiki

I have just installed 1.21.2 with Extension:LocalisationUpdate. Note that the wiki will not start. When removed from core the wiki works properly again.--Juandev (talk) 14:41, 19 October 2013 (UTC)

This is a known bug (it has been discussed in Bug 46885 - Fatal error after installation when using LocalisationUpdate). The problem is that the MW installer does not do the proper configuration of LU extension. The solution is to add the cache dir below the require_once like this:

require_once( "$EXT/LocalisationUpdate/LocalisationUpdate.php" );
$wgLocalisationUpdateDirectory = "$IP/cache";

After that it will work (at least once)! But then you may find that the 1.21.2 bundled LU version is problematic. Some days later you may not get any more localisation updates. I don't know why this happens. Just install latest version/update of extension LU (i.e. remove LU folder and pull a new one from git) and from that point on it will work perfectly every time! (I suggest to install latest version anyway)

--Ioannis Protonotarios 18:38, 19 October 2013 (UTC)

This seems to be reported also here: Thread:Project:Support desk/Fatal exception of type MWException after install MW from 1.21.0

bug 46885 --Ciencia Al Poder (talk) 18:47, 11 January 2014 (UTC)

MediaWiki did the exact same thing to me when I installed as well. Everything went fine until localsettings.php was uploaded and then all I have is an error code. Two tiny lines of code that needed to be added to the file (but weren't) cost me several days of headaches and nearly made me delete the whole install. Hadashi (talk) 22:16, 21 January 2014 (UTC)

Install of MW 1.22.0 failed with this extension

Having enabled the option of including this extension during the install procedure of MW 1.22.0 and after copying LocalSettings.php into wiki directory the browser returned the following error when accessing the wiki first time:

"Fatal exception of type MWException"

Removing or commenting out the extension in LocalSettings made the installed wiki run:

#require_once "$IP/extensions/LocalisationUpdate/LocalisationUpdate.php";

--unsigned comment by 87.163.59.10 22:13, 1 January 2014 (UTC)

See previous topic, right above yours (and happy new year!) --Ioannis Protonotarios 22:35, 1 January 2014 (UTC)

bug 46885 --Ciencia Al Poder (talk) 18:47, 11 January 2014 (UTC)

Error update script

(Sorry my poor english) I try to php extensions/LocalisationUpdate/update.php. But i see

Failed to download https://git.wikimedia.org/raw/mediawiki%2Fcore.git/HEAD/langu
ages%2Fmessages%2FMessagesEn.php; retrying in 1s...
Failed to download https://git.wikimedia.org/raw/mediawiki%2Fcore.git/HEAD/langu
ages%2Fmessages%2FMessagesEn.php; retrying in 1s...

...

.

Is there any solution?

Try renaming the LocalizationUpdate dir in extensions dir and do a clean installation of the latest version of LocalizationUpdate. --Ioannis Protonotarios 15:08, 30 March 2014 (UTC)

Help!

I haven't been able to make LU work, for more than a year now! I have several wikis of various versions and configurations. 2 days ago I did a clean install of MediaWiki 1.25.3 (with PHP 5.5.21 (cgi-fcgi), MySQL 5.1.55-rel12.6) but still LU does nothing. I did set $wgLocalisationUpdateDirectory as well as wiki's cache to same folder: $IP/cache with 755 rights. When I run update.php nothing happens. Literally, no message, nothing. After several minutes, more than 10, I get message "Found no new translations". That's it. I've also tried rebuilding LU cache, and also tried to clone a fresh copy of LU. No luck. All the things I mention here I tried them several times in the past months for all my wikis with the same results. What's wrong with this extension? --Ioannis Protonotarios 07:25, 1 December 2015 (UTC)

What version did you clone? Nemo 07:57, 1 December 2015 (UTC)

Version 1.3.0 (4a4f0d4) 10:08, Nov 24, 2015. --Ioannis Protonotarios 08:19, 1 December 2015 (UTC)

Have you checked that you installed all dependencies with composer? Nemo 10:10, 1 December 2015 (UTC)

I hadn't done that but I did it just now. I run composer update in wiki root.

See output

> ComposerHookHandler::onPreUpdate Deprecation Notice: The Composer\Package\LinkConstraint\VersionConstraint class is deprecated, use Composer\Semver\Constraint\Constraint instead. in phar:///xxxx/xxxx/xxxx/xxxx/xxxx/users/.home/composer.phar/src/Composer/Package/LinkConstraint/VersionConstraint.php:17 Deprecation Notice: The Composer\Package\LinkConstraint\LinkConstraintInterface interface is deprecated, use Composer\Semver\Constraint\ConstraintInterface instead. in phar:////xxxx/xxxx/xxxx/xxxx/xxxx/users/.home/composer.phar/src/Composer/Package/LinkConstraint/LinkConstraintInterface.php:17 Loading composer repositories with package information Updating dependencies (including require-dev) - Installing symfony/yaml (v2.8.0) Downloading: 100% - Installing phpunit/php-text-template (1.2.1) Downloading: 100% - Installing phpunit/phpunit-mock-objects (1.2.3) Downloading: 100% - Installing phpunit/php-timer (1.0.7) Downloading: 100% - Installing phpunit/php-token-stream (1.2.2) Downloading: 100% - Installing phpunit/php-file-iterator (1.4.1) Downloading: 100% - Installing phpunit/php-code-coverage (1.2.18) Downloading: 100% - Installing phpunit/phpunit (3.7.37) Downloading: 100% - Installing squizlabs/php_codesniffer (2.4.0) Downloading: 100% - Installing mediawiki/mediawiki-codesniffer (0.1.0) Loading from cache - Installing jakub-onderka/php-parallel-lint (v0.9) Loading from cache - Installing justinrainbow/json-schema (1.5.0) Downloading: 100% phpunit/php-code-coverage suggests installing ext-xdebug (>=2.0.5) phpunit/phpunit suggests installing phpunit/php-invoker (~1.1) jakub-onderka/php-parallel-lint suggests installing jakub-onderka/php-console-highlighter (Highlight syntax in code snippet) Writing lock file Generating optimized autoload files

Then I run update.php again. It was totally silent for 20+ minutes, then it gives message: "Found no new translations" again.

--Ioannis Protonotarios 13:58, 1 December 2015 (UTC)

Maybe you should try and run a local composer, not the global one provided by your server. Then you will run "php composer.phar someCommand". But have you tried using the MediaWiki Language Extension Bundle? The page doesn't mention running any composer command, so I suppose the dependencies are bundled. Nemo 13:59, 3 December 2015 (UTC)

I tried both of what you suggest with no luck. First I'd disable installed LU and then downloaded latest MLEB and istalled it exactly as it says. After that I ran maintenance/update.php to update the db. (Btw, the first message of updater was: "Your composer.lock file is up to date with current dependencies!"). Then, I run the LU updater and I got the same behaviour: Silent for 20 minutes end then "Found no new translations". I then installed in wiki's root a copy of latest composer.phar and run php composer.phar update but I got "Nothing to install or update".

I think that there is something wrong with LU. As I said above, I haven't been able to run it for at least the last year, in all my wikis which vary in versions and cofigurations. I used to run it all the time before that, since I am an avid translator and main reviewer of the Greek community in translatewiki and I make changes to Greek translations all the time.

Do other people run it? Does it really work? I wonder, because, for example I see that LU is steadily bundled in the last 2-3 versions of MW, but with the same mistake all the time, which is the lack of the cache configuration line in LocalSettings.php. I was the one to put at least a warning about this in LU's documentation. But all this shows that maybe no one really runs LU after all. I see no other feedback here.

It's either this or there is something wrong with my server. I am hosted in Media Temple if this helps.

--Ioannis Protonotarios 08:06, 4 December 2015 (UTC)

Maybe your server can't connect to github to fetch localisation updates, and this extension just ignores any error messages? --Ciencia Al Poder (talk) 10:49, 4 December 2015 (UTC)

As far as I can tell, git and wget work fine with github. As for any suppresed error messages only a LU dev can tell us. I remember that LU was very verbose though. Do you Ciencia Al Poder use it? Does it work? Anybody else? --Ioannis Protonotarios 11:24, 4 December 2015 (UTC)

No, I don't use it, it was just a wild guess --Ciencia Al Poder (talk) 16:16, 4 December 2015 (UTC)

LocalisationUpdate fails if foreground skin is installed!?

When LocalisationUpdate is run I get the following error:

[92b5ad9c1eec7433c835aa4d] [no req] Exception from line 27 of /var/www/extensions/LocalisationUpdate/fetcher/GitHubFetcher.php: Unable to get directory listing for wikimedia/mediawiki-skins-foreground Backtrace:

1. 0 /var/www/extensions/LocalisationUpdate/Updater.php(117): LocalisationUpdate\GitHubFetcher->fetchDirectory(string)
2. 1 /var/www/extensions/LocalisationUpdate/Updater.php(139): LocalisationUpdate\Updater->fetchFiles(LocalisationUpdate\FetcherFactory, string)
3. 2 /var/www/extensions/LocalisationUpdate/update.php(62): LocalisationUpdate\Updater->execute(LocalisationUpdate\Finder, LocalisationUpdate\ReaderFactory, LocalisationUpdate\FetcherFactory, array)
4. 3 /var/www/maintenance/doMaintenance.php(111): LU->execute()
5. 4 /var/www/extensions/LocalisationUpdate/update.php(80): require_once(string)
6. 5 {main}

Why is LocalisaionUpdate trying to update the foreground skin? --C schmitz (talk) 07:32, 30 January 2017 (UTC)

It doesn't know that extensions and skins can exist outside gerrit. https://phabricator.wikimedia.org/T176390 . –Nikerabbit (talk) 16:27, 4 December 2017 (UTC)

how this is an example

wgLocalisationUpdateRepositories['github'] = array(

       'mediawiki' =>
               'https://raw.github.com/wikimedia/mediawiki/master/%PATH%',
       'extension' =>
               'https://raw.github.com/wikimedia/mediawiki-extensions-%NAME%/master/%PATH%',
       'skin' =>
               'https://raw.github.com/wikimedia/mediawiki-skins-%NAME%/master/%PATH%'

);

%/var/www/html%' is it like I can not understand git clone https://gerrit.wikimedia.org/r/mediawiki/core.git how to add it

I don't understand the question, sorry. –Nikerabbit (talk) 16:27, 4 December 2017 (UTC)

sample is not open

Could you put a running linux instance --Enemyx (talk) 21:44, 4 December 2017 (UTC)

Sorry I don't understand this question either. Is this a error message? What instance? Where? for What? –Nikerabbit (talk) 11:21, 8 December 2017 (UTC)

Is this extension only working with the latest version of Mediawiki?

Tracked in Phabricator
Task T206460

Hello, I'm working with MediaWiki 1.31.1 and I had not used this extension. But when I installed this and ran php extensions/LocalisationUpdate/update.php, I gave some messages:

[680729f70d48a5abf3783bb4] [no req]   Exception from line 33 of /path/to/your/wiki/extensions/LocalisationUpdate/includes/fetcher/GitHubFetcher.php: Unable to get directory listing for wikimedia

After some investigations, I realized that this extension tried to fetch files always from the Master branch of update repositories, but act based on locally installed Mediawiki in some weird way. For instance, It tries to fetch some files from https://api.github.com/repos/wikimedia/mediawiki/contents/resources/lib/oojs-ui/i18n that does not exist. Because oojs-ui directory exists in 1.31 has renamed to ooui in the Master branch.

I'm tried to solve this by adding some configuration likes below, But it does not work for me:

$wgLocalisationUpdateRepositories['github'] = array(
    'mediawiki' =>
        'https://raw.github.com/wikimedia/mediawiki/REL1_31/%PATH%',
    'extension' =>
        'https://raw.github.com/wikimedia/mediawiki-extensions-%NAME%/REL1_31/%PATH%',
    'skin' =>
        'https://raw.github.com/wikimedia/mediawiki-skins-%NAME%/REL1_31/%PATH%'
);

And I found that there's no branch info in Http::get calling in includes/fetcher/GitHubFetcher.php file.

So, I wonder the original target of this extension is only the wikis using latest version of Mediawiki, like WMF wikis or I'm missing something.

Thanks. --Lorentz21 (talk) 07:56, 8 October 2018 (UTC)

Probably related: phab:T36272. May be worth a BUGREPORT --Ciencia Al Poder (talk) 09:33, 8 October 2018 (UTC)

I made a ticket for this, Thank you! --Lorentz21 (talk) 13:32, 8 October 2018 (UTC)