Hi there,
I recently tried to set up Wikibase extensions on my personal MediaWiki site, and almost everything worked fine till now. I know every entity can have its own site links on various wiki sites, but I had difficulties in configuring them on my data site. As per https://www.mediawiki.org/wiki/Wikibase/Installation ,
For Wikibase Repository and Wikibase Client
Run the database update script of your MediaWiki installation:
php maintenance/update.php
Run the script that populates the sites table:
cd extensions/Wikibase
php lib/maintenance/populateSitesTable.php
After running populateSitesTable.php, it seems that now I have a series of Wikimedia project sites in the sites table. However, I just want to add ~10 (non-WMF) wiki sites of various languages, so that editors can just type in the article name on those wikis to create site links, instead of giving the full URL pointing to that external wiki over and over again. Is that possible for non-WMF wikis? If so, I guess I need to make changes to sites table by my hand, right?
Thanks,
Xinyan
p.s.
Is this mailing list suitable for general discussions on Wikibase extension?
Just checked the tabular data format as I want to use it for JSON-stat [2].
Unfortunately I find that JSON tabular data is defined such that I can't
use it for JSON-stat. Why these limits? I wonder, has those coding this
solution investigated how JSON is used for statistics at all? The way it is
now I can't even remap some (a lot) of the available datasets as they are
multidimensional, and tabular data is two-dimensional in its nature.
My guess is that tabular data is an attempt to force something into a
two-dimensional presentation even if it does not fit the problem. Can
anyone explain or clarify?
Before anyone start to argue about use of JSON-stat, I will point out that
this is in use by several statistical bureaus. The list includes Statistics
Norway, UK’s Office for National Statistics, Statistics Sweden, Statistics
Denmark, Instituto Galego de Estatística, the Central Statistics Office of
Ireland, the United Nations Economic Commission for Europe and Eurostat. In
particular Statistics Norway provide an API console where statistics can be
extracted, composed, and exported as JSON-stat.[1]
[1] http://www.ssb.no/en/omssb/tjenester-og-verktoy/api/px-api
[2] https://json-stat.org/
John Erling Blad
/jeblad
Hi all!
This is an announcement for a breaking change to the output of the
WikibaseQualityConstraints constraint checking API, to go live on 18
December 2017. It potentially affects clients that use the
*wbcheckconstraints* API action. (We are not aware of any such clients
apart from the *checkConstraints* gadget, which is not affected.)
Currently, the description of a constraint in the API response includes the
detail and detailHTML fields, which contain the constraint parameters. The
gadget has never used these fields, since the error messages for some time
now contain all the information needed to understand the constraint
violation (that is, the constraint parameters are part of the message where
necessary). Additionally, since the move from the {{Constraint
<https://www.wikidata.org/wiki/Template:Constraint>}} templates to
constraint statements on properties (using property constraint (P2302)
<https://www.wikidata.org/wiki/Property:P2302>), parsing constraint
parameters is no longer the complex task it once was, and consumers
interested in the constraint parameters can inspect the constraint
statements using the standard Wikibase APIs or the Wikidata Query Service.
Since these two fields can account for up to 40% of the *wbcheckconstraints*
API response size, and we want to start caching those responses soon, *we
will remove the detail and detailHTML fields on 18 December 2017.* This is
already in effect on the Wikidata constraints test system
<https://wikidata-constraints.wmflabs.org/>; you can test your tools or
other code there.
Please let us know if you have any comments or objections. -- Lucas
Relevant tickets:
- phab:T180614 <https://phabricator.wikimedia.org/T180614>
Relevant patches:
- gerrit:391864 <https://gerrit.wikimedia.org/r/391864>
--
Lucas Werkmeister
Software Developer (Intern)
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hi!
As I am working on improving Wikidata fulltext search[1], I'd like to
talk about search results page. Right now search results page for
Wikidata is less than ideal, here are the issues I see with it:
- No match highlighting
- Meaningless data, like word count (anybody cares to guess what it is
counting? Anybody ever used it?) and byte count (more useful than word
count but not by much)
- Obviously, search quality is not super high, but that should be
improved with proper description indexing
While working on improving the situation, I would like to solicit
opinions on the set of questions about how the search results page
should look like. Namely:
1. If the match is made on label/description that does not match current
display language, we could opt for:
a) Displaying the description that matched, highlighted. Optionally
maybe display the language of the match (in display language?)
b) Displaying the description in display language, un-highlighted.
Which option is preferable?
2. What we do if the match is on alias? Do we display matching alias,
original label or both? The question above also applies if the match is
on other language alias.
3. It looks clear to me that words count is useless. Is byte count
useful and does it need to be kept?
4. Do we want to display any other parameters of the entity? E.g. we
have in the index: statement_count, sitelink_count, label_count,
incoming_links, etc. Do we want to display any?
5. Display format for Wikidata and for other wikipedia sites is different:
Wikpedia:
Title
Snippet
Wikidata:
Title: Description
I.e. Wikipedia puts title on a separate line, while Wikidata keeps it on
the same line, separated by colon. Is there any reason for this
difference? Do we want to go back to the common format?
Also if you have any other things/ideas/comments about how fulltext
search output for wikidata should be, please tell me.
I am sending this to wikidata-tech and discovery team list only for now,
since it's still work in progress and half-baked, we could open this for
wider discussion later if necessary.
[1] https://phabricator.wikimedia.org/T178851
Thanks,
--
Stas Malyshev
smalyshev(a)wikimedia.org
Hello,
If you don't query against Wikidata database and
specially wb_items_per_site, please ignore this message.
We recently dropped wb_entity_per_page table and as result some queries had
to change, namely the ones that querying against wb_terms and
wb_items_per_site tables because these two store the entity numeric id
instead of full id (e.g. Q7251 vs. 7251) so when you join against these
tables you need to add concatenation, for example CONCAT("Q", ips_item_id).
This sometimes can have performance implications and force you to rewrite
the whole query in order to obtain desired performance which is not true in
wb_terms table anymore because it now contains both numeric id
(term_entity_id) and the full id (term_full_entity_id). But we haven't done
it for wb_items_per_site table yet.
So the question is, are querying against this table and does using
concatenation caused you performance problems? If your answer is yes,
please raise your voice in phabricator [0]
[0]: https://phabricator.wikimedia.org/T179928
Best
--
Amir Sarabadani
Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Two quick thoughts on fallback languages: One general rule perhaps could be to not select a language with a different script when one in the same script is available. (At least for users with a preference for a latin language - this may be different the other way around.)
A broader solution could be offering the user an individual setting for a the sequence of fallback languages (as used, e.g., in http content negotiation) across all Wikidata interfaces. But of course that's a much larger effort, and has perhaps been discussed elsewhere already.
Cheers, Joachim
> -----Ursprüngliche Nachricht-----
> Von: Wikidata-tech [mailto:wikidata-tech-bounces@lists.wikimedia.org] Im
> Auftrag von Stas Malyshev
> Gesendet: Freitag, 3. November 2017 01:40
> An: Wikidata technical discussion; Lydia Pintscher
> Cc: Internal communications for WMF search and discovery team
> Betreff: Re: [Wikidata-tech] Wikidata fulltext search results output
>
> Hi!
>
> > When showing labels from fallback languages we do have little language
> > indicators in other places. I believe we should have this here as
>
> Makes sense. I'll look into how to get those. Is language code OK or we need
> full language name (uk vs. Ukrainian)?
>
> One thing to note here is that secondary languages have no order - i.e.
> if you look in German, and there's no matching German label, but there are 10
> other language labels all the same (happens a lot for names & places), which
> language will be selected is anybody's guess. We could add rule that says "look
> at English as secondary first", in theory, but not sure whether we should - after
> all, besides having most languages, (and us speaking it :) there's not much
> special about it.
>
> > I'm slightly leaning toward showing both.
>
> OK.
>
> > I'd say in this case we could get rid of the word/byte count. To get a
> > good glimpse of the quality of the item I'd say we'd want to show
> > count of statements (excluding identifier statements), identifiers and
> > sitelinks.
>
> OK, I'll try to make this.
>
> >> 5. Display format for Wikidata and for other wikipedia sites is different:
> >> Wikpedia:
> >>
> >> Title
> >> Snippet
> >>
> >> Wikidata:
> >>
> >> Title: Description
> >>
> >> I.e. Wikipedia puts title on a separate line, while Wikidata keeps it
> >> on the same line, separated by colon. Is there any reason for this
> >> difference? Do we want to go back to the common format?
> >
> > Not sure if we had a reason tbh.
>
> OK then, I'll feel free to shuffle things around then :) Having more freedom in
> the title line is good because we can then display both label & aliases.
>
> Thanks!
> --
> Stas Malyshev
> smalyshev(a)wikimedia.org
>
> _______________________________________________
> Wikidata-tech mailing list
> Wikidata-tech(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
http://www.investorvlp.com/phoenix.zhtml?c=252308&p=irol-stockquoteBryntzne
On Nov 2, 2017 10:05 PM, robertdelacruz0430(a)gmail.com wrote:
Philipino Cuban Jakarata Japan Magic fedia Una Anatorio Iron Fist Stallin
First of Alis Hienzeal Alias Bryntzne Robert S Delacruz Robert M Delacruz
Robert G Delacruz Robert H Delacruz Robert X Delacruz Robert A
Delacruz.=====R1 No Change inner working HISTORIA B 4 SIR Hugene Issis
Eugene Promote Ur Culture Adapt or callapse Your Union Offenssive Windows
Brakeing Law Build a Wall Crisis Guallce Stand For ××× History Canada
Mexico France SouthWest Angle Saxon My Elizabathan English Palabras Racism
Destiny Do Donts pro Long Hebrew Pro Con Kings Men BloodLine You Cant Find
A Genration Century Late but Robert Downy I Am For All Under G.O.D you will
Moscow Seca Outline Above the Law OMB IBEW IMB Ant Vex Spectum Illuminate
sermon Homily 90s Illumanati Dela Cartels On the Way to a
Azillvillalilaliawilla Hallocaust
On Nov 2, 2017 5:40 PM, "Stas Malyshev" <smalyshev(a)wikimedia.org> wrote:
Hi!
> When showing labels from fallback languages we do have little language
> indicators in other places. I believe we should have this here as
Makes sense. I'll look into how to get those. Is language code OK or we
need full language name (uk vs. Ukrainian)?
One thing to note here is that secondary languages have no order - i.e.
if you look in German, and there's no matching German label, but there
are 10 other language labels all the same (happens a lot for names &
places), which language will be selected is anybody's guess. We could
add rule that says "look at English as secondary first", in theory, but
not sure whether we should - after all, besides having most languages,
(and us speaking it :) there's not much special about it.
> I'm slightly leaning toward showing both.
OK.
> I'd say in this case we could get rid of the word/byte count. To get a
> good glimpse of the quality of the item I'd say we'd want to show
> count of statements (excluding identifier statements), identifiers and
> sitelinks.
OK, I'll try to make this.
>> 5. Display format for Wikidata and for other wikipedia sites is
different:
>> Wikpedia:
>>
>> Title
>> Snippet
>>
>> Wikidata:
>>
>> Title: Description
>>
>> I.e. Wikipedia puts title on a separate line, while Wikidata keeps it on
>> the same line, separated by colon. Is there any reason for this
>> difference? Do we want to go back to the common format?
>
> Not sure if we had a reason tbh.
OK then, I'll feel free to shuffle things around then :) Having more
freedom in the title line is good because we can then display both label
& aliases.
Thanks!
--
Stas Malyshev
smalyshev(a)wikimedia.org
_______________________________________________
Wikidata-tech mailing list
Wikidata-tech(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Hi,
one more brief announcement:
The gerrit repository of the Wikibase JavaScript API library (
https://www.npmjs.com/package/wikibase-api, previously known as
https://packagist.org/packages/wikibase/javascript-api) was moved yesterday
to a new location at
https://gerrit.wikimedia.org/r/#/admin/projects/wikibase/javascript-api.
The old location
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Wikiba…
has been archived and made read-only.
Should your tools use this little library, please make sure you have update
the URL of the repository in your local copy.
Best regards,
Leszek Manicki
--
Leszek Manicki
Software Developer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hi,
this announcement should be only relevant to people who use a copy of the
git repository of Wikibase. Changes discussed below should be transparent
to other users of Wikibase.
As of yesterday (namely having merged
8f694176c839e98909e7695f6b86b6cff05c372c) JavaScript libraries used in
Wikibase front-end have been integrated into Wikibase git repository as
submodules located under view/lib directory. They are no longer installed
as Composer dependencies of Wikibase.
When updating Wikibase, you might need to run some commands to update
submodules (e.g. to fetch updated files of a particular library). The
commands to be run are:
git submodule init
git submodule update
or simply:
git submodule update --init
Should you have any questions regarding this change, or encounter problems
after recent update, especially in the UI-related code, please reach out to
the development team at WMDE.
Best regards,
Leszek Manicki
--
Leszek Manicki
Software Developer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.