User Details
- User Since
- Nov 26 2014, 1:31 PM (435 w, 3 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Dnaber [ Global Accounts ]
Apr 13 2016
Here's an example that still works (@MarkTraceur's example returns a 404 error now): https://tools.wmflabs.org/panoviewer/src/standalone/pannellum.htm?autoLoad=true&panorama=%2F%2Ftools.wmflabs.org%2Fpanoviewer%2Fcache.php%3Ft%3D4096%26f%3DAu_March%25C3%25A9_de_la_Butte%2C_Paris_April_2007.jpg
Aug 25 2015
@kaldari: British and American English are both supported (https://languagetool.org/languages/). The problem with the false alarm is that Wikipedia is full of proper nouns and rare words which the spell checker doesn't know. One could maybe ignore words from the title and words that occur more than once in the document (or more than n times in the whole Wikipedia if we have a fast lookup for that).
Aug 24 2015
Is this supposed to be online? I get a Javascript alert box saying "Couldn't connect to server: parsoidserver-http-error: (curl error: 7) Couldn't connect to server. " when clicking on edit.
The problem of feeding back error fixes to wikitext is solved, as long as we have a character position mapping between wikitext and plain text. Currently this is provided by sweble, but as I understand, parsoid also offers this or the parsoid result can easily be be parsed to get it?
Aug 23 2015
@kaldari: Hi, I'm the author of that tool (http://community.languagetool.org/wikiCheck/pageCheck/index) and any help improving it is very welcome. False alarms caused by wikitext exist because we use http://sweble.org, which isn't perfect when it comes to extracting plain text. Switching to parsoid should solve those problems. (There will still be some false alarms not caused by text extraction issues.)
Apr 6 2015
We're not running on Tool Labs anymore, so I cannot help in reproducing this. Feel free to close.
Feb 19 2015
qacct -j fr-feedcheck | grep maxvmem | grep -v "0.000" gives this:
Feb 17 2015
In about 90% the jobs are not running anymore. What's the correct behavior if the DB cannot be connected? Just crash and assume the process will automatically be restarted? Or manually try reconnecting after a wait period?
I've set this to priority 'high' now because the jobs need to run 24 hours per day to be really useful. Also, I have to log in about 5 times or so per week to restart the jobs. If we cannot solve this issue, I'll need to leave Tool Labs and host the jobs on my own machine again. I changed the memory settings a bit, e.g. to jstart -N fr-feedcheck -mem 7500m java -Xms250M -Xmx250M ...) but that doesn't help. Jobs still stop from time to time.
Feb 6 2015
I forget to mention that I restart the jobs every 24 hours with e.g. qmod -rj ca-feedcheck. Could this be a problem? Will this keep the memory settings?
JVMs can also request memory after start, depending on how you start them. I've now added -Xms100M to make sure they start with the maximim amount, i.e. no more memory requests.
Jan 4 2015
Nov 26 2014
More Open Source players (HTML5 based):