@MarcoAurelio: Yes, you're free to fork or create pull requests for this project.

@Aklapper: I'd aggree to this, but I currently don't have time for working on this, too.

Hello Cindy,

Thanks :)

This is just a bugfix, that ensures that only user entered text will get the namespace prepended. Otherwise pre-existing or autocompleted items will be processed, too.

Hello Yaron,

Yes, "int=" is part of a patch that I've uploaded in a task here.

The labels of the result are not translated.

I've created a new issue at SMW GitHub: https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/1611

I've tryed around and found that the bug is not caused by {{displaytitle itself, nor the Semantic Title extension.

Oh no, $label shouldn't be there,either :(

Hello Yaron,

Oh, that's a leftover - sorry!

​Yes, this should be ready to merge, but the second patch needs to be
included as well. It removes a few lines of code that were unnecessary and
messed something up in one case.

Yes, you're right. I've tryed that but got a database error and realized I
missed that table.

I've updated the original patch, as the old one was buggy

This patch does a complete removal by default:

This patch will completely remove the arrows, without adding a config option:

Add CSS classes and visual indication that a filter is applied

When testing, I found a bug where some int labels were assigned to the wrong filter:

While testing, I realized that this fix will introduce a different problem: Since the #drilldowninfo function will store some of its content as semantic properties, those will not be restored when running rebuildDatabase.

@cicalese Maybe this is of interest to you - the radio button input was broken when using mapping templates / labels. It was correctly displaying the label, but incorrectly stores the label instead of the actual value-id when the form is saved.

Ok, I understand why Semantic Title is still necessary then. May I suggest something? You could also keep Semantic Title as it is and for MW 1.27 create a Display Title extension which handles the renaming of links and internal APIs. The current name indicates a dependency on SMW which isn't the case anymore, right?

Sorry, I've committed the last patch itself

Ok, here's a new patch with your proposed behavior:

Yes, that's a possibility, too.

Do you have the changes for MW 1.27 somewhere documented? The page_props table is already existing in MW 1.26 - but using the Class would have the advantage of memoization/caching I guess?

Here is a patch that adds experimental support for remote autocomplete on display title for "values from category"

I've tried to implement the first change as it is very simple. Here's a possible patch for it.

I've been thinking about this for a while, too. The problem is not that mapping templates are not working when remote autocomplete is enabled (they do!), but the value is queried only against the page title (and not the displayed label). Only the returning results are then processed by the mapping template.

Thats a good idea, but unfortunately it doesn't work (probably because the template is loaded after the template I need).

I'm not sure how you handle this internally of SF, but I'm always using ; as separator, as the changes are very low that it will cause issues with page titles

This diff fixes the delimiter and also fixes the radiobutton issue with value/label distinction:

Yes, that solves the problem!

I've tryed to follow your proposal and use {{DISPLAYTITLE:}} to set the new title, but I also need to set $wgRestrictDisplayTitle = false;.

Hello Cindy,

Yes, I've tryed it - but the urldecode afterwards does not seem to happen:

Ah, never mind - I was causing this mess myself! Sorry for the issue.

The master branch, this commit id: https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FSemanticForms/322d4f4c303c1e211f71b18493a9709cf37cefe2

Yes, that was my impression, too. Something probably went wrong with the array explode

No, because then it won't be parsed after it was saved, too.

Hi Yaron,

Hello Yaron!

I've seen that you're refactoring this part of the code anyway. I can't get the current master state to run (it crashes), but this patch should hopefully make labels work:

Yes

See also T63151 and https://www.mediawiki.org/wiki/Topic:Rb7adzuz9pt6ifno