Timwi wrote:
> Rob Church wrote:
>
>>There's been some discussion on a development mailing list regarding
>>the namespace selector in contributions pages, which is expensive due
>>to our schema arrangement.
>>[...]
>>What is the point of per-namespace contribution feature on live site?
>>What are the applications of it?
>
> What is the point in that question? If it is so database-intensive that
> it needs to be taken down, then surely it should be taken down even if
> it is useful. Conversely, if it is not database-intensive enough to be a
> real problem, then surely it doesn't hurt to have it even if it isn't
> useful.
It may be in the between. Perhaps the load it causes might be just
enough to make some other useful but nonessential feature infeasible
with the current server resources. (Or maybe not, just speculating for
the sake of it.)
> Besides, it appears that few people have found a really good use for it;
> it can therefore be assumed that it will not be used very frequently,
> and therefore it will likely not have much database impact after all. :)
I certainly find it useful. And in any case, it can generally be
assumed that if it's there, it will be used.
It's true that efficiently indexing that in such a way that page moves
across namespaces remain O(1) is hard. However, it strikes me that, for
most uses of that feature, we presumably aren't really interested in the
current namespace of the page so much as in the namespace it was in when
the contribution was named. If so, a simple solution presents itself:
add a field to the revision table recording the _original_ namespace
(and maybe pagename, while we're at it) of the revision as it was when
it was created.
(The null revisions resulting from page moves should probably be
considered to belong in the target namespace, especially since another
revision is already created in the source namespace for the redirect.)
--
Ilmari Karonen
> > Surely the most useful solution would be to make the Go button redirect
> > non-silently, i.e. in the same way as a real redirect. A wikilink [[Lyon
> > metro]] would still be a redlink, but typing "Lyon metro" in the Go box
> > or the actual URL should bring up [[Lyon Metro]] with the note,
> > "(redirected from _Lyon metro_)", where "Lyon metro" is, of course, a
> > redlink. You can then use that to create the page if you wanted to.
>
> Yes...why didn't I think of that?
Good idea, but maybe it can be improved slightly by assuming that most
people are somewhat lazy.
Instead of:
(Redirected from _Lyon metro_)
You could have:
(Redirected from _Lyon metro_ - _create redirect_)
Where "_create redirect_" would open a preview window at [[Lyon
metro]] with the contents already automatically prefilled as
"#REDIRECT [[Lyon Metro]]" and the edit description already prefilled
as "Redirect to [[Lyon Metro]]". Then if we guess correctly the user
does not have to type anything, and only has to click "Save".
Of course, if the "Go" guess is wrong then they do have to type
something. That's unavoidable though, but now they have to type less,
and also the prefilled content acts as an example of the preferred
redirect format.
All the best,
Nick.
Tim Starling wrote:
>
> Infoboxes are a very important application of templates. There needs to
> be some way conditionally add table rows based on whether or not a given
> template parameter is defined.
Surely this could be done by adding a certain sub-syntax to the table
row syntax? Something like
|-#ifdef:parameter
e.g.
{|
|-#ifdef:heading style="background-color: pretty;"
! {{heading}}
|-
| {{content}}
|}
Of course, that would be an extremely specific syntax (specific to
templates *and* to table-rows), but in my opinion, it is way cleaner and
more structured than any hacky attempt to fool the parser into correctly
patchworking the table from pieces.
> When people complained about the argument separators in {{#if:}}
> clashing with table syntax, I told them to use HTML table tags
> instead.
I am quite surprised that you didn't notice that this means you are
suggesting a workaround, as opposed to a solution.
> Why is the template required to close its own tags? It would make things
> a lot easier if this was not required.
I totally can't believe you said that.
Timwi
I'm in the process of rewriting the old Sanitizer::removeHTMLTags to work much
better. The new code properly closes implied end-tags and obeys some additional
HTML rules about what can go where.
In-progress patches posted at:
http://bugzilla.wikimedia.org/show_bug.cgi?id=5497
Before I finish this up, though, it would be good if we can agree on how to
handle a few things.
** HTML across template boundaries
Right now there's a big behavior difference between the regular mode and the
behavior with Tidy enabled. In regular mode, the HTML nesting and closing rules
are separately applied to every transcluded text chunk. In Tidy mode, only the
allowed-HTML check is applied at that stage, and nesting and closing is left for
Tidy to fix things up at the very end.
An example of a construct that breaks is a template that defines a table header
like:
<table class="fooba">
and is included like this:
{{cool-table-start}}
{{cool-row|blah}}
{{cool-table-end}}
In current non-Tidy mode, this breaks violently as the <table> gets closed in
the first template, and then all the following <tr>, <td> etc are rejected as
they're not allowed in body text.
In current Tidy mode this is allowed to pass on through just fine; the pieces
are assembled and then checked for nesting later.
I really don't like this kind of construct as it makes it harder to treat
transclusions at the abstract-parse-tree level in the future; in order to
understand the markup _following_ the transclusion you need to have already
expanded it. Yucky!
However the current system allows the same thing to work with wiki tables (eg
{|class="fooba") in either mode. I'm pretty sure at least the latter are in
fairly common use on Wikipedia.
So we either need to decide to Kill Them All, or accept the sacrifice for
compatibility.
** Inline HTML across wiki blocks
Currently, removeHTMLTags is applied before most other parsing steps, most
notably doBlockLevels which handles paragraph splitting, wiki lists, etc.
A consequence of this is that bad nesting / illegal overlapping can occur with a
construct like this:
<b>First paragraph
Second paragraph
The HTML normalizer adds the missing close tag:
<b>First paragraph
Second paragraph</b>
and later the wiki block levels adds <p> tags:
<p><b>First paragraph
</p><p>Second paragraph</b>
</p>
This is fairly obviously incorrect; it _probably_ would make a reasonable amount
of sense to rework how the block levels interact with stuff so it happens either
up before, or in concert with, the HTML normalization.
** Mixing of HTML and wiki tables
Running tests on pages from French Wikipedia, I found a cute bugger that does
something like this:
{|
<caption>A table caption</caption>
|-
|blah
|}
Since tables haven't been replaced in the output yet, this <caption> is in a
<body> context as far as the HTML normalizer sees and it fails. But the old code
let it through, in both tidy and non-tidy mode.
While this kind of admixture looks *supremely ugly* to me, do we have any reason
to disallow it?
Should we think of the wiki table syntax as just a shortcut/transformation to
HTML table tags, or should they be entirely separate entities?
-- brion vibber (brion @ pobox.com)
An automated run of parserTests.php showed the following failures:
Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test Parsing optional HTML elements (Bug 6171)... FAILED!
Running test Inline HTML vs wiki block nesting... FAILED!
Running test Mixing markup for italics and bold... FAILED!
Passed 385 of 396 tests (97.22%) FAILED!
i would like to change all occurences and references of an username in
all tables
can someone give me a hint how this can be done. does there exist a
php-script or some sql-code-snipplet?
thx, heinz
Just a heads-up, folks:
Later this week I'm going to be installing a fix for some longstanding bugs with
HTML in wiki pages. One of the issues is a difference in rendering of templates
that improperly nest HTML tags, which caused certain badly-written templates to
render in one way on Wikipedia but wildly broken on most other wikis.
(Don't forget that an important part of what Wikipedia & its sister projects are
about is making information sharable and reusable. If the code breaks when
copied to another site, that's Bad.)
Once the fix is in, templates should render about the same on Wikipedia and
other wikis where the "HTML Tidy" plugin isn't being used. The bad news is that
some of these templates will be broken; so it would be great if we can make sure
they get cleaned up.
Problem templates are mostly those which start an HTML tag in one template, then
finish it in another. For instance if {{table-header}} contains a <table>, and
then the table rows and final </table> are in another template entirely. These
have always broken on regular MediaWiki -- the template is required to close its
own tags -- though they sometimes appeared to work on Wikipedia due to bugs with
our HTML handling when Tidy is enabled.
I've done some automated checks on templates on en.wikipedia.org to make a list
of likely problem candidates:
http://leuksman.com/misc/templates/html-table-start.txthttp://leuksman.com/misc/templates/html-table-end.txthttp://leuksman.com/misc/templates/html-table-row.txt
If you've got a template that you're not sure if it will work, try copying it to
my test wiki at http://test.leuksman.com/ . This has the fix installed with the
corrected behavior, so you can see about how it will render on Wikipedia next week.
Please make sure this information is disseminated to the various other language
and project wikis people are working on; I don't want to hear "waah! all my
templates broke and no one told me!" next week. :)
For the moment the same kind of construct with wiki tables ({| ... |}) will
still work, but note that some time in the future we're going to have to look at
'fixing' that too. (This might require some enhancements to how templates work
to make it easier to fill in long tables.)
-- brion vibber (brion @ pobox.com)
we moved everything from ch.wikimedia.org to our own wikis/websites.
Could somebody close/lock/delete/make inaccessible/whatever the
ch.wikimedia.org wiki?
Thanks
--
Regards
Michael Bimmler
Secretary
Wikimedia CH - Verein zur Förderung Freien Wissens
Wikimedia CH - Association for the advancement of free knowledge
www.wikimedia.ch
Hi
Working with v1.4, I found that 'searchindex' table was corrupted. I repaired
it, but does anybody have any similar experience to know the reason?
Thank you very much.
Tim Starling wrote:
> Infoboxes are a very important application of templates. There needs to
> be some way conditionally add table rows based on whether or not a given
> template parameter is defined. When people complained about the argument
> separators in {{#if:}} clashing with table syntax, I told them to use
> HTML table tags instead. That seemed like a much better, more stable
> solution than {{!}}. If that's not going to work anymore, what exactly
> are people meant to do?
>
> There are thousands of affected articles, and if there is no solution
> for this, then I don't think it is acceptable to put this change live.
>
> Why is the template required to close its own tags? It would make things
> a lot easier if this was not required.
That's how MediaWiki has worked for a long time; it was just broken with Tidy
mode enabled, thus guaranteeing that any Wikipedia page using such a template
would be broken when copied to another wiki.
Would you prefer to change the behavior? Note that this will require some
restructuring to the parser to both be more correct and and not break things,
and will leave us with inconsistent, unparseable code in the future. (That is,
it'll be impossible to tell what the code after a template inclusion will parse
as unless the template is available.)
But if we're really, really sure, we can put some time into working on that and
accept that our syntax will never be predictable. (This has consequences for
future wysiwyg or markup-sensitive assisted editing plugins.)
-- brion vibber (brion @ pobox.com)