I did some research for you, and all I could find are some javascript
variable methods of accessing the user's language preference:
wgUserLanguage:
http://www.mediawiki.org/wiki/Manual:Interface/JavaScript
With some different info here:
http://www.mediawiki.org/wiki/Language_in_MediaWiki
Hi!
I upgraded my company's internal wiki from 1.16 to 1.17, and all page names
shown wrong, like „Output feltételrekordok módosÃtása”. The wikitext
body is ok. I checked the localsettings and database before and after
upgrade, and I see nothing wrong. Originally I installed with utf8 mysql5
On Tue, 01 Nov 2011 12:05:57 -0700, Brion Vibber wrote:
On Tue, Nov 1, 2011 at 11:43 AM, Dan Nessett dness...@yahoo.com wrote:
So, while I still believe there is a problem with PHP sessions, I
cannot yet reproduce the intermittent problem we observe. However,
other improper behavior is
FYI: The WorkingWiki extension [1] can be used to plug in any number of
math systems into a MW wiki, including Sage, Octave, Mathematica, etc.
For instance, one you install WW and add a simple makefile rule of the form
%.sage.out : %.sage
(command-line operation here)
you can write the
Thank you for this information. It is a very exciting extension. It's
unfortunate that it has security compromises that cause it to have to be
used on a non-public wiki. Still, it sound like it is so capable, it may be
worth the compromise.
I made some updates to the CalcII and WorkingWiki
On Wed, Nov 9, 2011 at 11:56 AM, Dan Nessett dness...@yahoo.com wrote:
[snip]
This problem is a bear to analyze. I have not been able to develop a
reliable way to reproduce the problem. However, I have found a way to
reproduce a related problem intermittently. I have put details in the bug
Hi,
I'm looking for a hook that is called when the text of an article is
parsed because of a cache miss.
On IRC I was told to use one of the hooks called by Parser::parse, but I
am not sure that's the solution:
* Parse is also called on cached pages, e.g. to render the 'This page
has been
On Wed, 09 Nov 2011 13:20:47 -0800, Brion Vibber wrote:
On Wed, Nov 9, 2011 at 11:56 AM, Dan Nessett dness...@yahoo.com wrote:
[snip]
This problem is a bear to analyze. I have not been able to develop a
reliable way to reproduce the problem. However, I have found a way to
reproduce a
On Wed, Nov 9, 2011 at 2:35 PM, Stephan Gambke s7ep...@gmail.com wrote:
Hi,
I'm looking for a hook that is called when the text of an article is
parsed because of a cache miss.
What are you trying to accomplish with a hook that's called during (before?
after?) parsing that comes after a
On Wed, Nov 9, 2011 at 2:50 PM, Dan Nessett dness...@yahoo.com wrote:
What problems remain other than the ones I noted previously as being
known problems or expected behavior?
Documented in the bug report (comment 4).
Ok so to confirm:
* This is primarily about the bug we told you should
The JavaScript URLs work fine, and they weren't too difficult to adapt to my
own MediaWiki installation. The URL rewrite stuff that redirects the 404 URL
to thumb.php is what seems to be missing, and it affects all image types. I
don't know what command is being used to render SVG thumbs. How do
Badon, thanks for your help. Unfortunately, I don't speak PHP or JavaScript,
but at least I managed to create a very crude patch for
includes/parser/Parser.php
Original version:
8 - - - - -
case 'contentlanguage':
global
This is an interesting, novel solution. It seems it would be trivial to take
this a step further and add an additional case that is userlanguage. It
might be worth your time to request that as a feature enhancement for an
upcoming version of MediaWiki:
https://bugzilla.wikimedia.org/
If you'd
13 matches
Mail list logo
