unintentional Camelcase links with slashes e.g. Bla/Blo

[anonymous]

Two ore more Uppercase words separated by a slash e.g. Bla/Blo are treated as CamelCase and therefore generate a wikipage link. This is not welcome. It should better not be hyper-linked.

Examples

"Bla/Blo", "Tom/Thomas" and "Berlin/Germany" produce unwanted wiki-links to non-existing wiki pages.

Argumentation

In routine work it happens quite often that unintended (dead) hyperlinks are created when writing texts fragments e.g. in Berlin/Germany or Tom/Lisa said.
In my opinion it should be like this:

• Germany/Berlin → shall be not be linked,
• LocationGermany/Berlin → shall be linked

because the first one can occur in natural writing and natural writing shall not be wiki-interpreted. In my opinion Germany/Berlin shall not be interpreted as CamelCase.

According to CamelCase and WikiPageNames slashes are allows to make "hierarchy" links. Rule 5 of WikiPageNames says:

5. The use of slash ( / ) is permitted in page names (possibly representing a hierarchy).

In my opinion this rule should be changed as follows:

5. The use of slash ( / ) is permitted in page names (possibly representing a hierarchy). In this case the above rules apply to each of the name fragments.'

Severity and Workaround

I do not really have a big problem here, since:

• one can simple insert spaces Germany / Berlin or
• escape the link with an exclamation mark e.g. !Camel/Case or
• use one of the configuration options e.g. ignore_missing_pages = true.

However I think that the wiki processor shall not negatively interfere with natural writing.

Relation and History

There is also an old discussion in #733 (especially comment:3). It seemed to be solved for TRAC 0.9 in 2004 but until then somehow there was an regression and the unwanted effect reappeared..

The effect of unwanted linking is reported for TRAC versions 0.12, 1.0 and 1.1(dev). Other version I cannot test other versions now, but from my memories I believe that TRAC 0.10 and/or 0.11 did not suffer from the effect.

[Ryan J Ollos]

I didn't catch the ​mailing list discussion until just now, so I'll just be repeating what was already described there. The behavior appears to be intentional, or at least known and well-described at the time it was implemented: #9025 and [9252].

I have also found it to be unexpected that Germany/Berlin is interpreted as a link. You say that LocationGermany/Berlin should be linked. Should Germany/LocationBerlin also be linked? The latter seems even more natural than LocationGermany/Berlin, since it could be interpreted as a wikipage within the Germany page index. Maybe the best solution is to require at least one of the words to be CamelCased.

I haven't tested extensively, but I think the following patch might fix the issue:

trac/wiki/api.py

@@ -341 +341 @@
 
     def get_wiki_syntax(self):
         wiki_page_name = (
-            r"(?:[%(upper)s](?:[%(lower)s])+/?){2,}" # wiki words
+            r"((?:[%(upper)s](?:[%(lower)s])+)+/)*"  # capitalized or camelcase word
+            r"(?:[%(upper)s](?:[%(lower)s])+){2,}"   # wiki camelcase word
+            r"(/(?:[%(upper)s](?:[%(lower)s])+)+)*"  # capitalized or camelcase word
             r"(?:@[0-9]+)?"                          # optional version
             r"(?:#%(xml)s)?"                         # optional fragment id
             r"(?=:(?:\Z|\s)|[^:\w%(upper)s%(lower)s]|\s|\Z)"

I agree with Peter's comment on the mailing list that it isn't good to change existing behavior, though if the behavior didn't already exist, I think it would be best to not have Germany/Berlin interpreted as a link.

[Peter Suter]

Yes, maybe if this wouldn't exist yet there would be little reason to introduce it.

But there are several easy and effective workarounds:

Severity and Workaround

I do not really have a big problem here, since:

• one can simple insert spaces Germany / Berlin or
• escape the link with an exclamation mark e.g. !Camel/Case or
• use one of the configuration options e.g. ignore_missing_pages = true.

Are there any for when this is changed? (I.e. so all links like Maps/Germany written since 11.7 still link to the existing subpages.)

(Except "Carefully review all existing wikitext in pages, tickets, etc. and fix all important links that have stopped working.")

If not, I would vote for WONTFIX and update the documentation if necessary.

[anonymous]

Clemens Feige wrote:

In my opinion it should be like this:

Germany/Berlin → shall be not be linked,

From: Peter Suter

I'm not so sure it's a good idea to change this back. Trac users since 0.12 have surely intentionally created such pages and links.

Hi Peter.

Indeed, one has to balance my proposal with backward-compatibility with those cases which depend on the regression.

However, I would claim that most users which actively use implicit CamelCase-hyperlinking always use CamelCase wiki page names. The other smaller group of users, which use non-CamelCase wiki page names, would use the explicit wiki: macro anyway. I other words the impact of backward compatibility would not be as big as it looks at first view.

I vote for changing the regex to have Germany/Berlin not be linked. I prefer good software usability and confusion avoidance over backward compatibility. Note that we are talking of "backward compatibility" to an regression i.e. to a bug. Remember that with older TRAC versions (0.9?) it worked the other way. I was confused when things changed, and I have many old wiki texts which depend on the old behaviour.

Clemens

[anonymous]

I am Clemens Feige, the one who reported this ticket.

Sorry, for anonymous writing. I do not have a TRAC account yet. I promise to create one soon.

Replying to anonymous:

Clemens Feige wrote:

[Christian Boos]

Replying to rjollos:

[…] I haven't tested extensively, but I think the following patch might fix the issue:

Seems to be working fine, but one motivation to implement it the way it was done in r9252 was that I could already measure a performance penalty by introducing the Lu and Ll lists (the 'upper' and 'lower' lists of Unicode characters used in that regexp are quite long, respectively 943 and 1217 characters). Repeating them more may induce further slow-downs (to be measured). Besides the performance issue, there's also a limit on the regexp size itself, don't forget this is only a piece of an even bigger regexp and sometimes people already hit that limit (#10190).

I agree with Peter's comment on the mailing list that it isn't good to change existing behavior, though if the behavior didn't already exist, I think it would be best to not have Germany/Berlin interpreted as a link.

If we had #425 (configurable or pluggable wiki page name syntax), it would be possible to keep the current behavior as default for existing installations yet make it easy to "fix" it for people that want another behavior.