SemanticMediaWiki / SemanticMediaWiki

🔗 Semantic MediaWiki turns MediaWiki into a knowledge management platform with query and export capabilities
https://www.semantic-mediawiki.org
Other
517 stars 228 forks source link

$smwgNamespacesWithSemanticLinks usage #184

Closed mwjames closed 10 years ago

mwjames commented 10 years ago

According to [a0, a1] which as been noted with the following contents:


Since we were forced to migrate to composer[1], on translatewiki.net SMW has stopped working completely for our main case, because properties are not set at all.[2] This means we're unable to manage our hundreds of i18n support requests;[3] encouraged by Jeroen, I created a test case which doesn't make use of templates[4] and I'm asking help on how to make it work. Initially we tried refreshing data as docs suggest and got stuck with the insuccess of the process[5] but local hacks brought the script to completion and still no properties are set from LQT namespaces.

We therefore think that $smwgNamespacesWithSemanticLinks is not working; I see the help page for it was created few days ago (thanks!)[6] but it doesn't really say how it interacts with composer. Nikerabbit set it via $wgExtensionFunctions, which docs declare "liable to fail in odd ways",[7] but was (allegedly) recommended by Jeroen and is not explained anywhere, nor I managed to get answers to questions about it since December. What to do? Our sysadmins have not had time to debug SMW in the last few months, I hope you can offer a solution they can apply.

Nemo

[1] Diff: https://git.wikimedia.org/commitdiff/translatewiki.git/2f13c8ef01e5c33d544c4d6699a3dad8c7097725 Current config: https://git.wikimedia.org/blob/translatewiki.git/HEAD/TranslatewikiSettings.php Current composer.json: https://git.wikimedia.org/blob/translatewiki.git/HEAD/composer.json [2] See for instance "Developer". https://translatewiki.net/wiki/Special:Properties [3] https://translatewiki.net/wiki/Support/Open_requests https://translatewiki.net/wiki/Template:Support [4] https://translatewiki.net/w/i.php?title=Summary:Support/HTML_tags_or_wiki_text%3F [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=58969 [6] https://semantic-mediawiki.org/wiki/Help:$smwgNamespacesWithSemanticLinks [7] https://www.mediawiki.org/wiki/Manual:$wgExtensionFunctions


[a0] https://bugzilla.wikimedia.org/show_bug.cgi?id=58969 [a1] http://p.defau.lt/?0iJEtsTkjCpwDIWF1UivQQ

mwjames commented 10 years ago

I suspect that [0] has been set. Looking at smw.org, [1] doesn't show any unusually behaviour when it comes to "extra" namespaces not being able to use property annotations.

For references to Composer and namespaces, please see #40, #45, #47, #39.

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/docs/INSTALL.md#step-5 [1] https://semantic-mediawiki.org/wiki/Demo:Berlin

kghbln commented 10 years ago

The only unusual difference between "regular" custom namespaces and "custom" namespaces provided by LQT is that we are talking about namespace indices from 90 to 93 which is below 100. It is a wild guess, but probably still worth mentioning. However it worked before, so ...

nemobis commented 10 years ago

enableSemantics() is used, yes, in the way recommended by docs. https://semantic-mediawiki.org/w/index.php?title=Help:Installation&oldid=32356#cite_ref-config_3-0

nemobis commented 10 years ago

I now see in the links above "enableSemantics() which can be called in LocalSettings after $smwgNamespaceIndex is set", which is the exact opposite of what docs say one must do. https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/47 Can you please find out what's the correct way in current SMW and update the docs? I don't have shell access so I can't find the correct configuration by trial and error.

kghbln commented 10 years ago

The docs currently say that you have to set $smwgNamespaceIndex prior to enableSemantics(). This is actually how I understood the mechanics. If I am wrong this will obviously have to be rectified. What the documentation on installing does not state is that the value for this parameter must be ≥ 100 as well as an even number. This is indeed only mentioned on the help page of the parameter and needs to be amended.

nemobis commented 10 years ago

The snippet I linked and intended to mention was «Add optional settings[4] to the "LocalSettings.php" file as desired below the enableSemantics() call» (emphasis mine).

(Comment clarified after Nikerabbit pointed out that $smwgNamespaceIndex doesn't appear to be our problem, our config is consistent with both the docs and what you said above.)

kghbln commented 10 years ago

I have adjusted the installation instructions to make the peculiarity of setting $smwgNamespaceIndex more obvious and thus resolve this "subissue". However doing the setting like this is no different than in previous versions of SMW and when looking at "TranslatewikiSettings.php" I see that this indeed seems not to be your issue. Let's see what @JeroenDeDauw thinks how the problem may be resolved.

nemobis commented 10 years ago

Moving the $smwgNamespacesWithSemanticLinks settings outside $wgExtensionFunctions didn't help, any other suggestion?

nemobis commented 10 years ago

Correction: it seems it did work, but it takes a null edit and some time (or a manual job queue run?). Now we're trying with more pages.

nemobis commented 10 years ago

Looks like it's working, see https://translatewiki.net/wiki/Support/Open_requests Now I'm running (wit ad hoc family, will fix pywikibot master later): python pwb.py touch.py -lang:en -family:twn -start:! -namespace:92 -pt:0

JeroenDeDauw commented 10 years ago

Issue fixed?

nemobis commented 10 years ago

Seems so, now applying the patch to the repo https://gerrit.wikimedia.org/r/#/c/112793/

kghbln commented 10 years ago

That's cool. Good to know that namespaces with indices < 100 work too.

nemobis commented 10 years ago

Kgh, can you update the docs about $wgExtensionFunctions etc.?

kghbln commented 10 years ago

$wgExtensionFunctions is MediaWiki thing already documented and the etc. was already improved.

nemobis commented 10 years ago

Meh. Added to https://www.mediawiki.org/w/index.php?title=Manual:$wgExtensionFunctions&diff=903840&oldid=841667

kghbln commented 10 years ago

Well if it wasn't you who added it I would probably have reverted this... Seems not necessary since the recommendation you are referring to is itself undocumented. However, more info does not hurt after all.

mwjames commented 10 years ago

Added to https://www.mediawiki.org/w/index.php?title=Manual:$wgExtensionFunctions&diff=903840&oldid=841667

I can't fully agree with what has been noted on mw.org because SMW itself uses $wgExtensionFunctions [0] and the recommandation to use $wgExtensionFunctions for delayed loading was before the official 1.9 point release.

The real problem with $wgExtensionFunctions is that it is an array which if callbacks are registered (as in [0]) the order of its execution is arbitrary making it possible for values to be set to early or to late.

$wgExtensionFunctions should not be used for when value dependencies are required but it can be used to make sure that initialization happens after LocalSettings is loaded (as in [0]).

This is the reason why $smwgNamespaceIndex and enableSemantics() are used in LocalSettings to allow for custom values to be set before SMW [0] is initialized and make it independent from the Composer registration process (which happens much earlier).

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/SemanticMediaWiki.php#L109

nemobis commented 10 years ago

That's why I want someone else to document it... I added something more to https://www.mediawiki.org/w/index.php?title=Manual:$wgExtensionFunctions&diff=903864&oldid=903840 from the comment above. If I knew well how that stuff works now, I would have self-answered my questions in December. :)

JeroenDeDauw commented 10 years ago

@nemobis I have removed your addition to the docs there. This was never really the recommended way of setting up your config. It was not in any release. During 1.9 alpha there where a few days in which this was an approach we tried out and then decided against. This is why we are not mentioning it in the install or update instructions - doing so would be more confusing then helpful to nearly everyone.