Page MenuHomePhabricator

Preceding text and single apostrophes are not included in links
Closed, DeclinedPublic


Author: qleah

Text appearing before, or single apostrophes followed by text and appearing
after double-bracket links are not included in the rendered anchor. That is:

[[abc]]de becomes <u>abcde</u>
'[[abc]]' => '<u>abc</u>'
abc[[de]] => abc<u>de</u> rather than <u>abcde</u>
[[abc]]'s => <u>abc</u>'s rather than <u>abc's</u>

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:54 PM
bzimport set Reference to bz468.
bzimport added a subscriber: Unknown Object (MLST).

jeluf wrote:

Prefixes are only added to the link for certain languages, e.g. Arabic.
Language::linkPrefixExtension must be set to "return true;" for this.

Ticks like ' and " are not supposed to become part of the link. Works as designed.

qleah wrote:

That's peculiar. What's special about Arabic?

I've noticed occasionally on the English Wikipedia that links are sometimes
written [[Canada|Canada's]] when they ought be more simply written as
[[Canada]]'s. This would be trivial to implement.

Most bugs "work as designed". Often the design is wrong.

jeluf wrote:

Arabic merges article and noun. So they have lots of things like "the[[window]]"

rowan.collins wrote:

As for treating trailing apostrophes as part of the link, that's just a matter
of adding ' to the character class in [[MediaWiki:Linktrail]].

i.e. a LinkTrail of "/^([a-z']+)(.*)$/sD" should allow your "[[Canada]]'s"
example to work as you want it to. I must say, I can't *think* of any situations
where this would be undesirable, unless it created annoying bugs by conflicting
with ''italics'' etc., but I imagine it shouldn't...

river wrote:

FWIW, putting preceeding text in the linktrail would cause problems with e.g.
Welsh, where constructions like "Mae[[Yr Undeb Ewropeaidd|'r Undeb
Ewpropeaidd]]..." are common.

Wiki.Melancholie wrote:

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

phi1ipp wrote:

Rowan's suggested fix (of changing the linktrail through the MediaWiki namespace
interface) doesn't actually work, as "the software ignores this page, and takes
the regular expression in the message files, for performance and stability
reasons." src:

Also see for the
same fact.

So can devs include the apostrophe in the expression for English language? I'm
going to assume that this is already a setting included in language packs? Cf.


ayg wrote:

What would this do in the case of ''[[Italicized]]'' or [[Link]]''italicized''
or ''italicized [[link]]'' or similar degenerate cases?

alefzet wrote:

Fixed with r36253.

I believe this has been unfixed by

Regardless the behaviour en.wp is as described, and the MediaWiki:Linktrail page, which has included ' since 2007 seems still to be ignored.

(In reply to comment #10)

Regardless the behaviour en.wp is as described, and the MediaWiki:Linktrail
page, which has included ' since 2007 seems still to be ignored.

And that is not going to change. Actually, the page has not been "in use" in years.

It is not clear from this bug whether the intention was to fix the default, the overriding of Linktrail or both.
Nonetheless, although I assumed MediaWiki:Linktrail was never made live again, the substantive point is default value of Linktrail is reverted.

Like Arabic, Hebrew also uses prefixes for "the", "to", "from", "that", and "and". These can be used in combination. They don't seem to work in the link trail on the English Wiktionary which of course has many Hebrew links.

Brion said he would investigate this but it might be something reserved for the new parser.

Brion, Did you investigate this?

This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED.
In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help!

The summary of this discussion seems to be: the current design works as intended. The arguments against the current design have been challenged by examples of other languages where the current implementation also makes sense.

On top of this we have almost a decades of wiki editing under these conditions.

I will be bold and I will resolve this report as WORKSFORME.