[[[ID|Name]] text] doesn't work

Question

The pattern [[[ID|Name]] text] doesn't work and the whole is just rendered as text in a biography.

The related pattern [text [[ID|Name]]] does work.

I suspect the coder is only checking for an internal link if it comes across [[ in isolation.

Answer 1

Single square brackets are for external links, double for internal links. So if you combine them, I would expect strange behaviour.

An external link is structured as: [url text]. So [[[ID|Name]] text] has an internal link to a WikiTree page where the url should be. [text [[ID|Name]]] has text where to url should be, so it may break the external link and just show the internal link inside the non-functioning parts of the code. Both are examples of a misformatted link.

Comments

To me the solution would be to see what close bracket combinations to get back down to a resolved set followed the [[[. Obviously there's only so much you can do, but it should cover most cases, I think.

Answer 2

Hi Nicholas. That's a pity. You can get round it with a zero-width space character. I have attempted to put one as the only character on the following line. It's invisible of course.

​

Maybe you can copy it from there, or from between the apparently empty parentheses near the start of the Wikipedia article.

[​[[ID|Name]] text] should work, where I believe I have inserted the zero-width space like this: [​ZWS[[ID|Name]].

Comments

I would not suggest the use of a zero-width space character or any other non-standard characters, since this could have unintended consequences. For instance, this could break the formatting of a GEDCOM download if the software is not designed to strip or replace those characters. Unicode even treats these as line-wrapping elements.

---

Steven, doesn't WikiTree handle Unicode gracefully? Modern GEDCOM files use a UTF-8 character standard. I don't think Unicode treats a zero-width character as a line break. If WikiTree isn't going to support the full Unicode character set, will we need a project to vet each character? *

It's true that a zero-width space could inadvertently be omitted on a subsequent edit of the file. This could be handled by an explanatory <!-- HTML comment--> .

* For the avoidance of doubt, such a project is not intended as a serious suggestion. Edited to correct format of HTML comment, then to be more careful about line breaks.

---

"If WikiTree isn't going to support the full Unicode character set, will we need a project to vet each character? *"

Just to clarify, I am not saying WikiTree can't (or does not) support it - that is more of a question for Jamie. What I meant is that there is no way to know the full consequences of nonstandard usage like this (and which is why it is not included as a recommended tag format).

---

There were some issues with 4-byte UTF-8 encoded characters in GEDCOM uploads, but if a character saves in the biography then it should be fine to use technically. Whether people should use non-standard characters like a zero-width space or emoji in profiles is more of a policy question I think.

---

Thanks for the information, Jamie. I've continued this theme in another part of the discussion.

Answer 3

Hi Nicholas,

I am curious on how you are trying to use the brackets for your purpose, is it perhaps for including words within a quote that are not part of the original quote? We typically only use square brackets in writing when we want to modify another person's words.

Anyways... Square brackets are a special type of markup on wikis that perform link generation.

Single brackets in the format [link text] is being queried by the software for a URL in the link position, and the text is then formatted as the link wording that everyone sees, and may be customized:

[https://google.com Google] renders as: Google
[https://google.com ''Google''] renders as: Google
[https://google.com {{Red|Google}}] renders as: Google

--

Now, double brackets are similar, but are based on internal pages (profiles, categories, free-space pages, etc.) or specific known sites (like Wikipedia). Again, the presence of the double brackets is being queried for specific information, [[Page-ID|text]]...

So combining these two items together and getting weird results is not really bug - that is just how the underlying software (mediawiki) is designed to work.

In the case of using [[[Harris-5439|Steve]] text], the first item (notated in red) is not a valid URL format, so the software renders plain text for the link component (shows the raw markup): [[[Harris-5439|Steve]] text]

In the case of [text [[Harris-5439|Steve]]], the first item (notated in red) is again not a valid URL format, so the software renders plain text for the link component. In the text position (shown in green), you can add in other wiki-markup to customize the links further as I have shown above, so you now see: [text Steve].

See more information on links at Help:Adding Links.

Comments

I disagree it's not really a bug: it looks to me as if the software only acts if it gets [ or [[, but doesn't try and resolve [[[. There's no intrinsic reason why it shouldn't. The parsing rules aren't that difficult.

In this case, having found the [[[, the parser looks for close brackets and finds ]]. It then treats the text within that as a possible internal link, and the whole within the outer single [ ] as a possible external link.

There are two use cases i can think of:

1) Square brackets are often used for editorial comment, and that comment may well want to start with a linked name.

2) Square brackets are commonly used in transcriptions to expand abbreviations or fill in conjectured missing texts. In my transcriptions I link names to profiles, which again could wind up with this pattern.

---

These use cases sound reasonable to me, Nicholas. Unfortunately taking on board what Steven commented, I now realise that the workaround I suggested in another answer, on the thinking that MediaWiki is fixed, could result in a square bracket [ at the end of a displayed line and the following link text at the start of the next line. (I still think WikiTree should be trying to support the full Unicode character set.)

---

Nicholas, again, I do not believe this to be a bug. A bug would be an incorrect or unexpected result - which is this is not.

This is actually an inherent feature of MediaWiki, which is what WikiTree is based on. You can also replicate this exact behavior on Wikipedia, Wikibooks, Wikimedia Commons, Wikidata, Wikinews, or any other Wikimedia Foundation project.

---

It's unfortunate it's in the underlying software, and I ama little surprised it hasn't been addressed given it affects so many wiki systems. It does, however, put it outside the purview of the WikiTree team.

You say feature, I say bug, I'm afraid. In my opinion it is an incorrect result, and one that wouldn't be hard to fix.

---

@Nicholas, you said that:

Square brackets are commonly used in transcriptions to expand abbreviations or fill in conjectured missing texts. In my transcriptions I link names to profiles, which again could wind up with this pattern.

Can you give me a real example of this?

The typical use of brackets in writing is to indicate you have inserted your own words into a quotation or to show an error in a quotation:

• "She [Julie] finished the report last week."
• "No more [government] equipment will be purchased for use in the facility."
• The note said, "telphone [sic] the hotel as soon as you arrive."
• The candidate stated, "I grew up in Sacremento [Sacramento] in the 1960s."

The only item in the list I could see used in this fashion is the first one, however, if this was based on a conclusion or inference (conjecture), would this not be more suitable for a Research Note, or if derived from another profile you want to link to, as a part of the source?

---

@ Nicholas - just because you don't like the outcome, or the explanation, does not make a feature a bug.

---

Whether it's a bug or a feature is not the most important point. What's crucial is that even if a MediaWiki upgrade improved the behaviour, it wouldn't change WikiTree, which relies on a fixed old MediaWiki fork.

It would be good if we could help Nicholas to achieve his aims (perhaps there wouldn't be controversy about that if it weren't technically difficult). Here's a modification of my previous suggestion which should avoid line wrap:

[&zwj;[[Franklin-1|Ben]] text]

&zwj; is the zero-width joiner. WikiTree ought to support that character, because it's needed by Arabic and some Indic scripts (and some emojis apparently, for what that's worth). Perhaps Jamie could advise on whether it would cause problems.

Edited to add: Jamie has indicated in a comment that in general "if a character saves in the biography then it should be fine to use technically", and beyond that she says there may be a policy question. I don't see how the ZWJ character could be banned outright by policy, because of its use in various natural language scripts. After that, it might seem odd to make a policy outlawing it in this specific other potential use, assuming that Nicholas is willing to follow the method I've suggested.