Clarification: The highlight extension allows source code to be
color-highlighted depending on the programming language. A wiki text:

<source lang="c">
int a = 10;
</source>

will highlight int as a keyword, and show 10 as a constant, based on the rules
of the C language.

robchur wrote:

We know what it is.

ayg wrote:

*** Bug 8146 has been marked as a duplicate of this bug. ***

It needs the following changes:

1. Efficiency fix:

https://sourceforge.net/tracker/?func=detail&atid=670231&aid=1688864&group_id=114997

2. Defer loading of geshi.php until the hook is called. Deferring message

initialisation would also be advisable.

3. Use strings for the "line", "case" and "header" parameters instead of

requiring numeric input. Numeric input deprecated and undocumented.

• Bug 9322 has been marked as a duplicate of this bug. ***

Upstream issue is reported to be fixed.

npopok wrote:

Upstream issue is reported to be fixed.

So… is there hope now that the extension will be installed within the next couple of years?

I actually would like to know this, since we at ru.wikibooks have started to make an ugly JavaScript workaround
for this.

I made the changes myself, it's now live on test.wikipedia.org.

npopok wrote:

Great! Does this mean that this'll work on the real thing
soon? Thanks a lot, anyway.

May I give two modest suggestions:

1. To use <code>, a valid HTML tag, instead of <source>.

The idea is to encourage the use of <code>, even if
without syntax highlighting. Why? To be able to make
distinct CSS styling for the whole blocks of source code:
make a grey background, a different margin/border or
whatever.

2. To make the highlighting (colours and fonts)

customisable through the Common.css file.

(In reply to comment #9)

1. To use <code>, a valid HTML tag, instead of <source>.

This would be a nightmare because <code> is already used in many places. It is, as you
say, a valid HTML tag, allowed by the software, and has well-defined behaviour.
Changing that behaviour would have unseen and unseeable consequences and would
basically annoy a whole lot of people for no good reason.

If you are going to define a new behaviour, use a new tag.

npopok wrote:

As far as I know, its "well-defined behaviour" is to
render the tag as it is, with no changes.

Under my proposition, wherever the <code> tag is used
now, that behaviour will not change unless you add
the "lang" attribute (e. g. lang="ruby"). And even then:

1. The <code[ ...]> tag, as before, would be rendered as

is, except for the removal of the lang="..." attribute.

2. The highlighter parser will add tags to each syntax

element.
The OVERALL behaviour of the block of <code> will not be
affected.

I like the idea of the <code> tag. The extension will need a minor modification
to allow the missing lang attribute to mean "do nothing".

Current implementation (as installed on test) produces

<pre class="source source-csharp">
<span class="kw4">int</span> i; <span class="co1">// comment</span>
</pre>

from the wiki markup:

<source lang="csharp">
int i; // comment
</source>

Thus, the extension should output the <code> tag instead of <pre>. Will we have
to redefine the <code> tag in for all wikies' css to look like <pre>?

Please do not add unrelated comments about changing the behavior of an existing
extension on this bug.

Now enabled.