In Wikidata, external identifier properties can have an associated "formatter URL" that will allow Wikidata to format a URL for the property value based on the identifier, e.g., https://www.wikidata.org/wiki/Property:P10831 has set the https://www.wikidata.org/wiki/Property:P1630 with "https://ordregister.dk/id/$1" which means that any item that use P10831 will get a URL, e.g., "COR.38799" with P10831 will be linked as https://ordregister.dk/id/COR.38799
I have tried a similar method on a cloud-based Wikibase, https://dreams.wikibase.cloud, but no link appears. For instance, an external identifier property https://dreams.wikibase.cloud/wiki/Property:P40 has the property https://dreams.wikibase.cloud/wiki/Property:P4 set to "https://daieproddreamspdfsto.blob.core.windows.net/files/$1", but items using P40 do not display a link.
Is it possible to make external identifier value links? Where is the option?
As #will-hanley's link to https://www.mediawiki.org/wiki/Wikibase/Installation/Advanced_configuration#Define_links_for_external_identifiers shows the property for external linking can be set with the $wgWBRepoSettings['formatterUrlProperty'] in the LocalSettings.php.
For Wikibase.cloud instances, this variable is, however, not directly available. Instead one should link ones Wikibase property in the settings (under "Features" and "Mapping Properties to wikidata"), so a "My Wikibase" property is linked to P1630 in Wikidata. After a while (hours?) the cache will be refreshed and the links appear.
This was explained by Laurence Parry in the wikibase-cloud mailing list: https://lists.wikimedia.org/hyperkitty/list/wikibase-cloud#lists.wikimedia.org/thread/7HPE53X6PQXTJ2TEVGT6RBB5HLDOT2VF/
Related
I want to build a Web app with SvelteKit with one page listing all items (with potential search query parameters), and then one page for each individual item. If I had to build this the old school way with everything generated in the backend, my paths would be /items/ for a the listing of items, and /items/123 for item 123, etc. That is, to go to the page of item 123, a link will with href="123" will work no matter if you are currently at the index (/items/) or at the page of one particuler item (/items/[id]).
With SvelteKit, if I create files routes/items/index.svelte and routes/items/[id].svelte, then routes/items/index.svelte will have path /items, without a trailing slash, and as a result a link with href="123" will lead to /123, resulting in a "not found" error.
This same link will work however from the page of an individual item, say, /items/456.
This is radically different from what you would have in the traditional HTML model, where a link from /items/ (or /items/index.html) would work the same as a link from /items/[id].html.
Now in svelte.config.js there is a trailingSlash option you can set to always so that routes/items/index.svelte corresponds to path /items/, but then routes/items/[id].svelte has path /items/[id]/ and we have the same problem again: one href value cannot work from both the index and the page of an individual item.
The only way I see right now is to use absolute path, but it's not very composable. My guess is that there is something I am doing wrong.
You're not missing anything - it's not currently possible in SvelteKit to have a trailing slash for some pages but not for others. There is an open GitHub issue you may be interested in that proposes adding additional trailingSlash options. This issue cites the exact problem you described:
The trailingSlash options introduced in #1404 don't make it straightforward to add trailing slashes to index pages but not to leaf pages. For example you might want to have /blog/ and /blog/some-post rather than /blog and /blog-some-post, since that allows the index page to contain relative links.
Until that feature is added, you'll need to use absolute paths.
Within Wikidata the properties P31 (instance of) and P279 (subclass of) - when stated - are always the first statements in the set of statements of a wikidata item.
On a random wikibase install, the properties simply follow the order in which they are created. I would like to know how I can configure a wikibase to replicate the behaviour from Wikidata where a custom property order can be defined
The order of the statements in a given Wikibase installation is determined by the list in the page MediaWiki:Wikibase-SortedProperties.
The Wikidata own file is located at https://www.wikidata.org/wiki/MediaWiki:Wikibase-SortedProperties
The instructions on how to enable the option in the configuration file are on this page https://www.mediawiki.org/wiki/Manual:Interface/Wikibase-SortedProperties.
You can also refer to the Phabricator task https://phabricator.wikimedia.org/T250634 for further technical details.
By the way, this sorting also affect the output of the mw.wikibase.getPropertyOrder LUA function as described here https://www.mediawiki.org/wiki/Extension:Wikibase_Client/Lua#mw.wikibase.getPropertyOrder
When creating an external table, I get the below error:
Msg 105005, Level 16, State 1, Line 1
CREATE EXTERNAL TABLE AS SELECT statement failed as the path name 'wasbs://.blob.core.windows.net/folder/Reject_Directory/_rejectedrows/' could not be used for export. Please ensure that the specified path is a directory which exists or can be created, and that files can be created in that directory.
I'm trying to create an external table using polybase, removing the REJECTED_ROW_LOCATION option works fine, but including it causes this error. How do I fix this?
Something else had already created the Reject_Directory/_rejectedrows folder, for some reason this caused a permissions error.
Delete the Reject_Directory/_rejectedrows folder from the blob store, so that Polybase can create it itself and the table can now be created.
Please check on below two things.
I was able to resolve this error by checking/adding the following things.
Make sure when you create credentials -> you add enough permissions while generating the tokens. This will help to create/loan the error records file in the ADLS container.
Make sure you use this with TYPE=HADOOP.
For that -> CREATE EXTERNAL DATA SOURCE name WITH (
LOCATION='location', CREDENTIAL = credential name, TYPE=HADOOP).
and then try adding REJECT_ROW_LOCATION while creating EXTERNAL TABLE.
In my home page I have the following snippet that fetches all blog posts:
var docs = CurrentPage.Children.Where("Visible")
What I don't understand is that Visible is controlled by a property in the document named umbracoNaviHide. Setting it to true on the document excludes the page from the list above.
How is umbracoNaviHide translated to Visible? I have no macros or XSLT (none actually) that is doing anything funny...
umbracoNaviHide is one of umbraco's internal property implementations.
We used to have to check the property explicitly in xslt but nowadays it is used as you are using it here.
Here is a more complete explanation from the Umbraco wiki
The "umbracoNaviHide" is an Umbraco convention for marking nodes which
should not show up in a navigational context. It is normally added (or
inherited) on every Document Type with a Data Type of "True/false".
NOTE: This property is not added by default on new installations,
meaning you need to add it manually
There are a number of other useful properties that everybody should know about:
umbracoSitemapHide
umbracoUrlAlias
umbracoUrlName
umbracoInternalRedirectId
umbracoRedirect
We always insert these properties on a master page doctype so that all other doc types that represent data on web page content nodes inherit them
Wing
I'm writing an app which saves and loads documents both locally and on iCloud. Locally is working fine, but I'm having a problem with iCloud.
The documents are saved as a package - the UIDocument reads and writes an NSFileWrapper which contains an image file, a thumbnail file, and an info plist. When I save the document to iCloud and then look at the files under 'Manage Storage', I see the individual files instead of the packages; and more importantly when I search for files using NSMetadataQuery it returns an NSMetadataItem for each of the individual files instead of the packages. As a result, my app doesn't realise there are any packages to load and iCloud is pretty useless.
I thought that if I set up the document type and exported the UTI correctly that the packages would be treated properly. Was that right? If so, what's the checklist for setting up a document type as a package? I have:
Added a document type
set LSTypeIsPackage to YES (I've tried string YES and bool YES)
set CFBundleTypeExtensions to an array containing one string: the file suffix
set LSHandlerRank to Owner
Exported a UTI with the same identifier
set it to conform to com.apple.package
added a UITypeTagSpecification dictionary, containing an array for the key public.filename-extension, which contains one string: the file suffix
I've also tried adding a matching Imported UTI to match the exported one, but no luck there.
What did I miss?
UPDATE: I notice that the OP in this question is seeing the behaviour I want (even though he doesn't want it) so it must be possible.
Based on this I tried removing the LSItemContentTypes from my plist, and it worked.