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.
Hi everyone! I’m considering to make a change to the HTML output for
statements, and I’d like to gather some feedback from people who work on
gadgets and user scripts :)
The problem is that any gadget that appends to the value of a statement
(e. g. *checkConstraints*) changes the HTML in a way that Wikibase’s own
JavaScript doesn’t expect, and sometimes the appended elements bleed into
Wikibase’s own elements, causing e. g. phab:T167869
<https://phabricator.wikimedia.org/T167869> and phab:T169866
<https://phabricator.wikimedia.org/T169866>. (To clarify: the tasks mention
*checkConstraints* specifically, but at least the first task also affects
other gadgets.)
My proposed solution is to change the layout of the HTML slightly, from the
current
<div class="wikibase-snakview-value-container" dir="auto">
<div class="wikibase-snakview-typeselector">...</div>
<div class="wikibase-snakview-value">...</div></div>
into the following:
<div class="wikibase-snakview-value-container" dir="auto">
<div class="wikibase-snakview-typeselector">...</div>
<div class="wikibase-snakview-body">
<span class="wikibase-snakview-value">...</span>
<span class="wikibase-snakview-indicators"></span>
</div></div>
There is a new element for “indicators” on a snak, and the value itself is
now a span inside of a new div wrapper. The indicators are hidden while the
statement is edited, and cleared on save. Gadgets can subscribe to the
wikibase.statement.saved hook to populate the indicators again after a
statement has been saved, using the new value. A simple example gadget
using this technique is at User:Lucas Werkmeister (WMDE)/colorIndicator.js
<https://www.wikidata.org/wiki/User:Lucas_Werkmeister_(WMDE)/colorIndicator.…>
.
Here’s a list of some gadgets and user scripts I’m aware of that could use
this “indicators” area:
- checkConstraints
<https://www.wikidata.org/wiki/MediaWiki:Gadget-checkConstraints.js>
- EasyQuery <https://www.wikidata.org/wiki/MediaWiki:Gadget-EasyQuery.js>
- User:Aude/mapview.js
<https://www.wikidata.org/wiki/User:Aude/mapview.js>
- User:Lucas Werkmeister (WMDE)/colorIndicator.js
<https://www.wikidata.org/wiki/User:Lucas_Werkmeister_(WMDE)/colorIndicator.…>
(mentioned above)
Existing gadgets that use something like $( '.wikibase-snakview-value'
).append( … ) will continue to work, though they could be changed to append
to the indicators instead. However, gadgets that select something like
div.wikibase-snakview-value will break, since the element is no longer a div
.
Do you see any problems with this new HTML layout, or do you want to
suggest any improvements? (You can reply to this email, or on the Project
chat
<https://www.wikidata.org/wiki/Wikidata:Project_chat#Gadget_.2F_userscript_e…>,
or comment on phab:T95403 <https://phabricator.wikimedia.org/T95403>.)
Cheers,
Lucas
--
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 there,
I'm currently working on a .NET implementation of Wikibase API client, and
have some (perhaps somewhat trivial) questions
Take the API response for wbgetentities on Q513
<https://www.wikidata.org/wiki/Special:ApiSandbox#action=wbgetentities&forma
t=json&uselang=en&ids=Q513&redirects=yes&props=claims&normalize=1> for
example. In the response, we have a claim
.
"P625": [
{
"mainsnak": {
"snaktype": "value",
"property": "P625",
"hash": "72a03bd4ecbba1e7d0e0dfc2779ceccf9b2e0bcb",
"datavalue": {
"value": {
"latitude": 27.988055555556,
"longitude": 86.925277777778,
"altitude": null,
"precision": 0.00027777777777778,
"globe": "http://www.wikidata.org/entity/Q2"
},
"type": "globecoordinate"
},
"datatype": "globe-coordinate"
},
"type": "statement",
"id": "q513$6dcddd25-48a6-229a-0e36-31b122c2c813",
"rank": "normal",
"references": [
{
.
1. Is "altitude" attribute in "globe-coordinate" property type still in
use? I saw this attribute in the API responses, but as far as I can observe,
they are always null. Is this attribute either reserved for future use or
obsoleted? (I've opened T177269 <https://phabricator.wikimedia.org/T177269>
but later thought that maybe mail list is more appropriate for this.)
2. Currently the "type" (in "datavalue" node) and "datatype" attributes
seems somewhat duplicate, are you planning to make it possible for one
"datatype" to support some other "type"s, to some extent similar to
polymorphism?
Regards,
Xinyan
Just a reminder,
We are starting to phase out the table, it will stop getting updated from
end of the next week and will be dropped two or three weeks from now, the
wb_terms table now have term_full_entity_id instead which is not replicated
to labs yet [0] but it will very soon.
[0]: https://phabricator.wikimedia.org/T167114
Best
>
> From: Magnus Manske <magnusmanske(a)googlemail.com>
> Date: Thu, Jun 1, 2017 at 5:21 PM
> Subject: Re: [Wikidata-tech] Breaking change: "wb_entity_per_page" table
> will not be updated and replicated on ToolLabs anymore
> To: Daniel Kinzler <daniel.kinzler(a)wikimedia.de>, Wikidata technical
> discussion <wikidata-tech(a)lists.wikimedia.org>
>
>
> The original code predated SPARQL, so I have to change it anyway. The
> example I gave is small enough for SPARQL, but others will not be.
>
> On Thu, Jun 1, 2017 at 4:11 PM Daniel Kinzler <daniel.kinzler(a)wikimedia.de>
> wrote:
>
>> Am 01.06.2017 um 16:59 schrieb Magnus Manske:
>> > As an example from my BEACON tool, I want all properties that have a
>> formatter
>> > property, with English label. That SQL is now:
>> >
>> > SELECT DISTINCT page_title,term_text FROM pagelinks,page,wb_terms WHERE
>> > page_namespace=120 AND substr(page_title,2)=term_entity_id and
>> > term_entity_type='property' and term_language='en' and
>> term_type='label' and
>> > pl_from=page_id and pl_title='P1630' and pl_namespace=120 and
>> > pl_from_namespace=120 ORDER BY term_text
>> >
>> > Note the "substr". My first attempt was "page_title=concat('Q',term_en
>> tity_id)",
>> > but that took forever.
>> >
>> > If we indeed get a full entity ID=page title column for wb_terms, and
>> > for wb_items_per_site etc., that would at least fix the on-the-fly
>> compute. I
>> > shall thus wait with code updates until I get the full story, and not
>> just
>> > piece-by-piece...
>>
>> There is currently no plan to put the full ID into wb_items_per_site or
>> wb_property_info, because these tables are bound to a specific entity
>> type.
>> Whether we want to do this would be a whole new discussion.
>>
>> For what you are doing there, it's probably a lot easier to use the query
>> service. SPARQL:
>>
>> SELECT DISTINCT ?property ?propertyLabel
>> WHERE {
>> ?property a wikibase:Property .
>> ?property wdt:P1630 ?format .
>> SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
>> }
>>
>> --
>> Daniel Kinzler
>> Principal Platform Engineer
>>
>> Wikimedia Deutschland
>> Gesellschaft zur Förderung Freien Wissens e.V.
>>
> _______________________________________________
> Wikidata-tech mailing list
> Wikidata-tech(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
'+'
On Oct 3, 2017 5:17 PM, "Stas Malyshev" <smalyshev(a)wikimedia.org> wrote:
Hi!
On 10/3/17 4:49 PM, Marco Neumann wrote:
> thank you Lucas and Stas, this works for me.
>
> so it would be fair to say that p:P39 by-passes the semantics of
> wdt:P39 with ranking*. for my own understanding why is a wdt property
> called a direct property**?
Because wdt: links directly to value, while p: links to a statement
(where ps: links to the value). But that's not the only property of wdt:
- another property that it links to "truthy" (current, best, etc.) value
- one that has best rank in this property (hence the "t" letter). This
may be what you want or not, depending on general semantics and your
particular case. For many properties, ranks do not play significant
role, since these properties do not change with time and do not have
temporally limited statements. So for these, using wdt: is always ok.
For some, like positions, offices, relationships between humans, etc.
the values can have temporal limits and if you want best/current one,
you use wdt:, otherwise you use p:/ps:. If you still want to account for
rank using p:/ps:, there are rank triples and wikibase:BestRank class
(see
https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Statement_
representation).
--
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 all!
This is an announcement for a breaking change to the output format of the
WikibaseQualityConstraints constraint checking API, to go live on 10
October 2017. It affects all clients that use the *wbcheckconstraints* API
action. (We are not aware of any such clients apart from the
*checkConstraints* gadget, which has been adapted.)
We are soon going to check constraints not just on the main snak of a
statement, but also on qualifiers and references (T168532
<https://phabricator.wikimedia.org/T168532>). However, the current API
output format of the *wbcheckconstraints* API action cannot accommodate any
other constraint check results. To resolve this issue, we are introducing a
new, more flexible output format for the API, which can contain constraint
check results on all kinds of snaks and also leaves room for future
expansion (e. g. for T168626 <https://phabricator.wikimedia.org/T168626>).
The new format is based on the Wikibase JSON format, and documented (along
with the old format) on mw:Wikibase/API#wbcheckconstraints
<https://www.mediawiki.org/wiki/Wikibase/API#wbcheckconstraints>.
If you use the *wbcheckconstraints* API action in your tools, the safest
option is to make them support both output formats for the transitional
period. It’s easy to determine which format the API returned, because the
new format contains the fixed key "claims" on the second level, which will
never happen in the old format. You can see an example of this for the
*checkConstraints* gadget in change I99379a96cd
<https://gerrit.wikimedia.org/r/#/c/373323/>, specifically the new
extractResultsForStatement function.
The new API output format is already enabled 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:
- T168532 <https://phabricator.wikimedia.org/T168532>
- T174544 <https://phabricator.wikimedia.org/T174544>
Relevant patches:
- https://gerrit.wikimedia.org/r/#/c/369420
- https://gerrit.wikimedia.org/r/#/c/373323/
--
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.