User Details
- User Since
- Jan 17 2015, 11:39 AM (464 w, 2 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Andreas Plank [ Global Accounts ]
Jul 20 2018
Jul 9 2018
Jun 5 2018
Then it would be my feature request to get it working: form field autocompletion on a property that has data type monolingual Text. Right now it is not working.
Oct 25 2017
In Firefox Network console I find no request to the translation api of Yandex, but somehow it is done; I get only registered the localhost request of .../api.php?action=translationaids....
Oct 24 2017
Aug 22 2017
This appears in MW 1.28.2 (just the version info)
Jul 11 2016
The extension was loaded by composer autoloading when I installed it via composer. LocalSettings had no effect whatsoever. In MW 1.25+ (1.26 probably as well) I had to manually load composer in LocalSettings:
if (is_readable("$IP/vendor/autoload.php")) { require_once( "$IP/vendor/autoload.php"); }
And that way some LocalSettings could take effect. But in MW 1.27 composer is magically loaded before the LocalSettings.
Jul 9 2016
Jul 6 2016
Yes, with MW 1.27 the language page issue is resolved
- page title is displayed properly
- translation links (for /de, /en) work as expected
Jun 7 2016
When I issue the patch command from the mediawiki root folder, I get
cd /usr/share/mediawiki patch --strip=1 --input=rMWd23738002136761e34f11d72e7dd7eea65e3b655.diff --dry-run --backup # checking file includes/OutputPage.php # Hunk #1 FAILED at 1. # 1 out of 1 hunk FAILED # ...
Honestly, my problem is that I don't know how to apply the https://phabricator.wikimedia.org/rMWd23738002136761e34f11d72e7dd7eea65e3b655?diff=1 directly. The wiki I have is not in git but managed by openSUSE software manager.
May 30 2016
unclear ... that's right in 2nd step I described only loosely, I meant: set page language from German to English, then mark the page for translation, then step 3
May 23 2016
There is a patch to start from: http://biowikifarm.net/meta/File:DT_PageStructure_recursive-escape_parsePageContents.patch
Or add recursive parsing à la http://us.php.net/manual/en/function.preg-replace-callback.php#example-5364?
May 20 2016
May 19 2016
Apr 13 2016
Mar 21 2016
OK. well, sorry for reporting it here I hope you bear with me and I see the issue was transferred as well, so
I follow up
on GitHub ;-)
Jan 29 2016
On https://www.semantic-mediawiki.org/wiki/Special:BrowseData/Extensions there appear similar issues.
Jan 28 2016
Is probaly related: Topic: No email address (on Mediawiki talk)
Jan 27 2016
Jan 17 2015
The problem is, that the PDF is probably not correct and the GhosScript puts out some messages
wget "https://upload.wikimedia.org/wikipedia/commons/a/a1/%D0%95%D1%82%D0%BD%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D1%96%D1%87%D0%BD%D0%B8%D0%B9_%D0%B7%D0%B1%D1%96%D1%80%D0%BD%D0%B8%D0%BA_%D0%A2.28.pdf" --output-document="testfile.pdf" # process by gs gs -sDEVICE=jpeg -sOutputFile=testfile.jpg -dFirstPage=1 -dLastPage=1 -r150 -dBATCH -dNOPAUSE -q 'testfile.pdf' **** Warning: glyf overlaps cmap, truncating. **** Warning: glyf overlaps cmap, truncating. **** Warning: glyf overlaps cmap, truncating. **** Warning: glyf overlaps cmap, truncating. **** Warning: glyf overlaps cmap, truncating.
ImageMagick consumes these (via | pipe) and consequently ImageMagick fails to process the image, because the text-warning messages are rerouted to ImageMagick. The warning messages are printed to stdout.
I have the same problem (Fatal error: Cannot override final method SMW\ResultPrinter::getResult() in path/to/extensions/SemanticResultFormats/formats/Exhibit/SRF_Exhibit.php on line 468)