I'm really OK with both ; but I'd rather leave the lambda function (instead of a plain string callback) in order to keep the parameters set to these explicit values in the call, considering the (X)HTML headers of the output page, if you don't mind.

What do you think of htmlentities over htmlspecialchars ?

The debate is long over.
Links MUST point to articles specifically about the entity described. Not sections, not redirects, not articles about generic entities, not articles about something unrelated. There can be no exceptions. This is especially useful to machines, which are the first consumers of Wikidata - including interwikis on Wikipedia, as they're served to you by machines that need to get them from Wikidata. Machines can't read URL fragments in a meaningful fashion, only browsers will scroll until the top of the screen aligns with the top of the (x|ht|xht)ml element with the id specified as fragment so the user can read from their screen, but that's browser behaviour for web browsing, and should not be expected from other software.

It doesn't matter that Wikipedias chose to handle things that way. Wikipedia chose to fill any gap by pointing to a related article. Wikidata chose to fill any gap by actually filling said gap.

In T145522#2999881, @2015.ww wrote:

Could someone kindly show a case -- or two :) -- of how such links cause a problem?
For example... looking at flautist / flûtist / fløjtenist (Q12902372) with an article e.g. at Fløjtenist but some other links, such as in enwiki, redirecting to the instrument page -- vs the instrument, flute (Q11405) but also recorder (Q187851), etc. etc. ... so aren't such additional links in fact rather helpful ?

Thanks much.

For what it's worth, I've built WRCR with the intent of finding items that link to pages that redirect to other pages that have items linking to them too.

Or, to handle the string literals too :

It's weirder than you think :

Temporary workaround :

I really am looking for both.

Additional info : I think I may have found a decent approximation for the complexity of the query(es) I've run up to this point.

Not sure if anyone did anything or if an automated process finally took up, but it finally appeared late last night, and I only just noticed.

Way ahead of ya ;-)
Current implementation (JS on test.wikidata) performs the action=wbgetclaims&props=claims|info call at window.onload time on items that are targetted by properties of interest.
Still wrapping my head around widgets and triggered events, planning on implementing them to do things more cleanly, but that's another talk altogether.

I'm working on a gadget that will allow you to insert by hand only one side of a relationship, and click for an automated insertion of the other side.
Let me clarifiy with a real world example :

• La Villette was a subdivision of Seine department.
• Q532352 (La Villette) has therefore a P131 (is located in) pointing to Q1142326 (Seine).
• and Q1142326 (Seine) has a P150 (has subdivision) pointing back to Q532352 (La Villette).

I did find wgCurRevisionId ;-)