headers
Daniel Arnold | 1 Feb 01:20
Picon
Picon
Gravatar

Re: interface URLs resolution order (splitted from "Major flaws...")

On Thursday 01 February 2007 00:20:31 Brion Vibber wrote:
> > 1)
> > Usually UI interface links (such as "MediaWiki:Mainpage" that defines the
> > URL of the main page) are not localisable by default (pages
> > like "MediaWiki:Mainpag/de" get ignored). However you can whitelist their
> > i18n with "$wgForceUIMsgAsContentMsg = array();" individually in
> > LocalSettings.php.
> >
> > 2)
> > In the past maintenance/update.php did copy every UI message from the
> > default language UI message file into the wiki database.
> >
> > On whitelisted UI interface
> > links it even did copy the default language link target into the language
> > sub pages in every language if there wasn't one created by hand before
> > (for example the content of MediaWiki:Mainpage was copied into
> > MediaWiki:Mainpage/de if it was empty). So if there was the link target
> > existing in the default language it was not possible to link people in
> > other languages into non-existant "localised" pages after running
> > maintenance/update.php (side note: this specific behaviour of
> > maintenance/update.php can't have been an accidential not intended side
> > effect).
>
> ... What? I don't understand.
>
> "Link people in other languages into non-existant "localised pages""?

A "non-existant localised page" is a page that does not exist in that language 
but people using that language get linked to by the interface.
(Continue reading)

Permalink | Reply | 0 comments |
headers
brion | 1 Feb 09:15
Picon
Favicon
Gravatar

MediaWiki automated test run failure 2007-02-01

An automated run of parserTests.php showed the following failures:

This is MediaWiki version 1.10alpha (r19702).

Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...

  18 still FAILING test(s) :(
      * URL-encoding in URL functions (single parameter)
      * URL-encoding in URL functions (multiple parameters)
      * TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
      * TODO: Link containing double-single-quotes '' (bug 4598)
      * TODO: message transform: <noinclude> in transcluded template (bug 4926)
      * TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
      * BUG 1887, part 2: A <math> with a thumbnail- math enabled
      * TODO: HTML bullet list, unclosed tags (bug 5497)
      * TODO: HTML ordered list, unclosed tags (bug 5497)
      * TODO: HTML nested bullet list, open tags (bug 5497)
      * TODO: HTML nested ordered list, open tags (bug 5497)
      * TODO: Inline HTML vs wiki block nesting
      * TODO: Mixing markup for italics and bold
      * TODO: 5 quotes, code coverage +1 line
      * TODO: dt/dd/dl test
      * TODO: Images with the "|" character in the comment
      * TODO: Parents of subpages, two levels up, without trailing slash or name.
      * TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.

Passed 489 of 507 tests (96.45%)... 18 tests failed!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Arnold | 1 Feb 14:09
Picon
Picon
Gravatar

Re: embedded links in UI messages (splitted from "Major flaws...")

On Wednesday 31 January 2007 21:03:49 Daniel Arnold wrote:
> These pages (not existing by default) get referenced hardcoded inside
> message strings from the MessagesEn.php file (I am not talking about the
> url pages like those called from mediawiki:sidebar):
> [[{{ns:project}}:Metadata]]
> [[{{ns:project}}:Administrators|administrator]]
> [[{{ns:help}}:Contents|help page]]
> [[{{ns:project}}:Searching|Searching {{SITENAME}}]]
> [[{{ns:project}}:Policy]]

I have now written a small patch that fixes this problem for MessagesEn.php. I 
used the {{MediaWiki:PAGE}} (thanks Platonides for the idea) syntax as it 
always points to the page in the default language which is desired in this 
case here.

If the patch gets applied this change should be applied to all 151 
MessageXX.php files as this problem causes currently quite some trouble in 
multilingual wikis and as the fix can be done in a search and replace manner 
which doesn't change any real text (and thus you don't need to know the 
language of the language file you are fixing).

Furthermore I added to the after-installation-mainpage a list of pages not 
existing in vanilla MediaWiki which interface definition files (in any 
language) expect to exist though. So after installation of MediaWiki people 
have a quick overview in one place which pages they need to customize in 
order to avoid broken links in the interface.

See: http://bugzilla.wikimedia.org/show_bug.cgi?id=8846 for the patchfile 
against recent SVN version.
(Continue reading)

Permalink | Reply | 7 comments |
headers
GerardM | 1 Feb 14:15
Picon

Re: embedded links in UI messages (splitted from "Major flaws...")

Hoi,
I want to say that this is one of the most helpful threads I have seen in a
long time ..
Thank you so much,
   Thanks,
       GerardM

On 2/1/07, Daniel Arnold <arnomane@...> wrote:
>
> On Wednesday 31 January 2007 21:03:49 Daniel Arnold wrote:
> > These pages (not existing by default) get referenced hardcoded inside
> > message strings from the MessagesEn.php file (I am not talking about the
> > url pages like those called from mediawiki:sidebar):
> > [[{{ns:project}}:Metadata]]
> > [[{{ns:project}}:Administrators|administrator]]
> > [[{{ns:help}}:Contents|help page]]
> > [[{{ns:project}}:Searching|Searching {{SITENAME}}]]
> > [[{{ns:project}}:Policy]]
>
> I have now written a small patch that fixes this problem for
> MessagesEn.php. I
> used the {{MediaWiki:PAGE}} (thanks Platonides for the idea) syntax as it
> always points to the page in the default language which is desired in this
> case here.
>
> If the patch gets applied this change should be applied to all 151
> MessageXX.php files as this problem causes currently quite some trouble in
> multilingual wikis and as the fix can be done in a search and replace
> manner
> which doesn't change any real text (and thus you don't need to know the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Travis Derouin | 1 Feb 16:47

Re: table text is full

I do recall seeing debugging messages printing to stderr when I ran
the script, but they didn't look serious at the time.

One issue I've found is that the default function compressWithConcat
assumes that the text table can do transactions as it is using
dbw->begin and dbw->commit statements. Our text table was initially
created with a version 1.3 of Mediawiki and is still a MyISAM table
(which doesn't support transactions), so if something goes wrong,
there's no opportunity to do a rollback.

I'd suggest at least warning the user of these consequences, or just
use the more basic compressOldPages if InnoDB isn't present:

    $res = $dbr->query("show table status like 'text';");
    if ($row = $dbr->fetchObject($res)) {
        $engine = $row->Engine;
        if ($engine != 'InnoDB') {
            print "Warning the text table is not an InnoDB table,
transactions are not supported\n";
            $dbr->freeResult( $res );
            return;
        }
    }
    $dbr->freeResult( $res );

I've been running compressOld against an original version of the
revisions that had problems, it seems to be working, so it might not
be a reproducible problem based on which revisions are compressed.
I'll look more into it.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dan Jacobson | 1 Feb 17:45
Favicon
Gravatar

Special:Categories starting from D: how to link?

Gentlemen, the challenge: how do I make a link to where the D's start
in Special:Categories?

Currently
http://radioscanningtw.jidanni.org/index.php?title=Special:Categories&offset=507
is right, but it changes day to day.

"Sure, just use [[Special:Allpages/Category:D]], and you won't even
need to use {{fullurl}}" you say. However that would only work if each
category page had a body. None do, so they won't be in Allpages.

Does SpecialCategories.php need to take some lessons from
SpecialAllpages.php about allowing fancier arguments?
Permalink | Reply | 1 comment |
headers
Dan Jacobson | 1 Feb 17:48
Favicon
Gravatar

action=submit blocked at public library?

How could it be that not only for *.wikipedia.org, but also my
taizhongbus.jidanni.org, at our public library
(http://www.ntl.gov.tw/, where you take a number to get a seat before
the doors open), one can login fine, meaning HTTP POST works, but
"show preview" and "save page" cause their MSIE browser to timeout
waiting. Though they like to block things like port 22, etc. I can't
believe they are blocking outbound requests with "wpTextbox" in them
or something. What might be up their sleeve? The lady said she didn't
know, and it's far away so I can't experiment often, nor before, "time
up sir, there are other users waiting."
Permalink | Reply | 0 comments |
headers
Dan Jacobson | 1 Feb 17:44
Favicon
Gravatar

update.php should fix more permissions

Dan Jacobson schrieb:
> php rebuildtextindex.php
> ALTER TABLE... 1142: ALTER command denied to user...

< You do not have the right MySQL permissions. Add to your wikiuser
< account the ALTER TABLE privilege and your problems should be fixed.

And indeed they were. Now let's try another script.
$ php updateSearchIndex.php
LOCK TABLES... 1044: Access denied for user...

And indeed, adding more privileges fixes that too.

My question is why doesn't update.php fix or at least warn about
these? E.g., "Bla lacks permissions to do ZZZ. Some maintenance
scripts won't run. Some daily tasks will be hindered."

By the way on
http://meta.wikimedia.org/wiki/Help:How_to_move_a_wiki_to_another_server
"SELECT, INSERT, UPDATE and DELETE permissions should suffice."
Permalink | Reply | 501 comments |
headers
Rob Church | 1 Feb 18:41
Picon

Re: update.php should fix more permissions

On 01/02/07, Dan Jacobson <jidanni@...> wrote:
> By the way on
> http://meta.wikimedia.org/wiki/Help:How_to_move_a_wiki_to_another_server
> "SELECT, INSERT, UPDATE and DELETE permissions should suffice."

That's because when I wrote the documentation page, I was writing for
the most common case, and for the general purpose user account;
maintenance would normally be done using a different account.

Rob Church
Permalink | Reply | 501 comments |
headers
Rob Church | 1 Feb 18:42
Picon

Re: Special:Categories starting from D: how to link?

On 01/02/07, Dan Jacobson <jidanni@...> wrote:
> Does SpecialCategories.php need to take some lessons from
> SpecialAllpages.php about allowing fancier arguments?

I'll tell you what; Special:Categories can start taking lessons from
Special:Allpages when the bug report is filed in the right place.

Rob Church
Permalink | Reply | 0 comments |

Gmane