ssanbeg wrote:

There is an option to add a number to every line, i.e. with something like:

<source lang=text line=normal>
some text
</source>

If more control is needed over the formatting, it might make sense to add more functionality to the poem extension.

Would a CSS-like declaration be feasible? Something like <poem options="compact; line-numbers;" />, or <poem options="compact; line-numbers:5;" /> (only label every 5th line).

This would be a very good feature of <poem>, but it should not be default. <poem> is used generically for maintaining whitespace, not only for poems.

ssanbeg wrote:

It would be easier to parse separate options, since the parser will take care of that, and pass an associative array to the extension. i.e. something like <poem compact line-numbers=5>

For consistency with other wiki syntax, would it be just as easy to parse HTML-like syntax (like <poem line-numbers="5">)?

(For other parameters like compact too, I mean.)

ssanbeg wrote:

Yes, the parser will parse HTML-like syntax before calling the extension, so it would be consistent with other wiki tags.

Any updates on this? I think it would be a very useful feature, not only for Wikisource but wherever poem is used.

I imagine adding these parameters to the tag poem:

• start: the number from which to start (default 1)
• step: the interval between numbers (example: 5, default: don't put any number, to be compatible with the current usage). It could be a number, or could be also one of these special values:
  • step="stanzas" -> number the stanzas instead of the lines (showing the number on each first line of each stanza)
  • step="lastline" -> put the number on every last line of each stanza (useful for sonnets)

Here a more "elastic" test solution in Lua (it's not intended for use, but to explore algorithms only): http://it.wikisource.org/wiki/Modulo:Poem

The trick is to wrap verses produced by poem extension into span tags, and to add parameters into such span; in out it.wikisource test implementation we added a id attribute, a title attribute and a class attribute; all contain the verse number, calculated by Lua script, so obtaining an anchor to link any verse by id, a box with verse number when pointing the mouse, and various jQuery tricks to filter verses (and to produce different verse number display you like without changing wikicode).

I will submit a patch for MediaWiki core once bug 52061 is resolved.

The implementation/syntax I propose is as follows:

<poem number-start=1
      number-step=5
      number-show-first
      number-class="fancyLetters">

• Start and step are as per comment 7, although I prefer "first" and "last" (or "stanza-first" and "stanza-last") instead of "stanzas" and "lastline". The default for both is 1.

• number-show-first can be optionally specified if you want e.g. lines 1, 6, 11, 16... to be numbered, instead of the default 5, 10, 15...

• number-class is optional CSS class(es) to be applied to the line numbers.

To enable line numbering, you simply specify any one of these attributes.

Each line number would get an anchor (e.g. #5, #10). Lines without a visible number get no anchor, to avoid excessive HTML clutter.

Feedback is welcome :)

(In reply to comment #9)

Good news, thanks! :) My comments:

• "stanza-first" and "stanza-last" are OK to me, but it seems stanza-first will do something different from the "stanzas" which I proposed. As I understand, "stanza-first" will just count every line, and show the number only on the lines which are the first of their stanza, eg.: 1, 9, 17, 25... My "stanzas" proposal was to count each stanza as 1 and show the number of the stanza, not the number of the line, eg: 1, 2, 3, 4... Of course this is not "one or the other" :), I think both possibilities are useful and should be implemented (maybe also at a later time, the most important thing for now is to have the "basic" numbering system with number-start and a numeric number-step).

• On bug 52061, comment 21, they suggested the possibility of assigning a custom css class to poem. If this is done, maybe number-class is not required: you can give all numbers a standard class "line-number", then users can give a custom class to poem, like "fancyPoem", and they can define the behavior using css subclass like ".fancyPoem .line-number {...}"

• I would favour giving anchors to all lines. This would make it much easier to link to a specific line. Otherwise I'm sure that people would resort to linking to the "closest line" :D, which is not desirable. I'm not sure if it's better to use #line5, #line10 instead of #5, #10, since in HTML4 ids are required to start with a letter (although most browsers tolerate that - also HTML5 is more permissive about that).

(In reply to comment #10)

As I understand,
"stanza-first" will just count every line, and show the number only on the
lines which are the first of their stanza, eg.: 1, 9, 17, 25... My "stanzas"
proposal was to count each stanza as 1 and show the number of the stanza, not
the number of the line, eg: 1, 2, 3, 4... Of course this is not "one or the
other" :), I think both possibilities are useful and should be implemented
(maybe also at a later time, the most important thing for now is to have the
"basic" numbering system with number-start and a numeric number-step).

Good point about stanza counting.

Numbering first/last lines of stanzas is turning out to be more difficult to code than I thought. I'll see what I can do. For now, I've got the basic numeric functionality to work correctly, which is a good start.

• On bug 52061, comment 21, they suggested the possibility of assigning a

custom css class to poem. If this is done, maybe number-class is not
required:
you can give all numbers a standard class "line-number", then users can give
a
custom class to poem, like "fancyPoem", and they can define the behavior
using
css subclass like ".fancyPoem .line-number {...}"

What would actually be more useful than number-class, now I think about it, is a "number-style" attribute, allowing ad hoc styling of line numbers for an individual poem (not otherwise possible without editing global CSS files).

• I would favour giving anchors to all lines. This would make it much easier

to
link to a specific line. Otherwise I'm sure that people would resort to
linking
to the "closest line" :D, which is not desirable. I'm not sure if it's better
to use #line5, #line10 instead of #5, #10, since in HTML4 ids are required to
start with a letter (although most browsers tolerate that - also HTML5 is
more
permissive about that).

OK, makes sense. By the way, MediaWiki outputs HTML5 now, so numeric anchors should not be an issue. Browsers don't seem to choke on them, although older ones like IE6 would have to be checked.

For lines, a compromise could be #l5, #l10, etc.: that would also allow to assign #s1, #s2, etc. to stanzas, thus supporting anchors to lines while displaying the stanzas count only.

But most importantly, the software should check for repeated (non-unique) ids, that would make the HTML invalid, potentially breaking the achor functionality.

In case anyone is interested, a patch that adds automatic line numbering to <lines> aka <poem> is at P192. It looks like it should apply on top of Patch Set 20 of https://gerrit.wikimedia.org/r/#/c/106861/. I'm just putting it here for safekeeping, or in case anyone wants to use it or hack it into an extension.

It can do all kinds of things - I can't really remember what, it's a long time since I wrote it. There's some handy documentation in a code comment, though.

Change 328888 had a related patch set uploaded (by TTO):
Automatic line numbering functionality for <poem>

https://gerrit.wikimedia.org/r/328888

What is the situation here? I see that a change has been submitted and modified several times (last edit on March this year), now why is it stalled?

@Candalua: The situation is that the change needs review. See https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews

In T15644#4260611, @Aklapper wrote:

@Candalua: The situation is that the change needs review. See https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews

Yes, this I can see. I rephrase my question: why is this change still waiting to be reviewed? Can some of the reviewers please proceed with it?

@Candalua: Feel free to contact and ask the reviewers, please.

I don't think @cscott would be especially impressed if that patch were to be merged right now...

In T15644#4261395, @TTO wrote:

I don't think @cscott would be especially impressed if that patch were to be merged right now...

Ok, can you please elaborate on what is wrong with it?