Re: [Wikimedia-l] Giving Commons a bigger public

[Hay (Husky)]

Hey everyone,
first of all, thanks for all the compliments on my tool! I'm really
glad that people think it is of use.

First of all, i made a couple of updates to the tool, including adding
i18n support, category search and links to Petscan. I've posted an
update on Twitter:
https://twitter.com/hayify/status/1264647593218408449

Just a couple of general observations and thoughts about this project.
When i started development i had two main goals:

1) To showcase the beauty and richness of the media on Wikimedia Commons
There are many files on Wikicommons that are of exceptional quality,
but unfortunately the current search results page doesn't really do a
lot of effort to showcase that, compared to search engines like Google
or Yandex. This is why the Structured Search results overview focuses
on big thumbnails and not on the metadata (i doubt many users are
interested in the filesize or resolution for example, which are shown
on the current Commons results page). This has been a big grudge of me
for many years, i've even came across a Phabricator ticket from almost
five(!) years ago where i was already proposing something like this
(https://phabricator.wikimedia.org/T104565).

2) To showcase the usefulness of structured data
Currently the only way to search for structured data is by using the
'haswbstatement' filter in the search engine. I doubt many people know
this (i didn't until Maarten Dammers pointed me to it) and the
user-friendliness is pretty low, given that you need to fill in
property and item numbers by hand. The best way to find media based on
structured data would be using a SPARQL endpoint (just as on
Wikidata), but unfortunately work on that has been slow (see
https://phabricator.wikimedia.org/T141602). So this tool is basically
a stopgap to author Commons search queries using haswbstatement until
we have a proper SPARQL endpoint for SDoC.

A couple of other points that might be of use:
* Structured Search queries are completely compatible with Wikimedia
Commons search engine queries. It's the exact same format. Any query
that can be done using a Commons search query can be done on
Structured Search (given that it uses the 'File' namespace). I've made
a Commons gadget you can use if you want a link from Commons search
results directly to the tool
(https://commons.wikimedia.org/wiki/User:Husky/sdsearch.js)
* I'm really pleased with the translations that have already been
made. Updating the localisations is still a manual process, i'll
change that to something more automatic in the future.
* I don't intend this to be the replacement of the regular search on
Commons, i just hope it can serve as an inspiration and as a solution
to people who want to have something more visual than the current
search UI.

I don't read this mailing list too much, so for feature requests or
bug reports it's probably best if you submit an issue on Github
(https://github.com/hay/wiki-tools) or reach out to me on Twitter
(@hayify) or via Wikimail.

Kind regards,
-- Hay

On Sun, May 24, 2020 at 9:20 PM Gerard Meijssen
 wrote:
>
> Hoi,
> I have been a professional developer for much of my working life. From what
> I know of what Hay has done, I know you are wrong depending on the approach
> taken. Building this functionality can be an iterative process, it does not
> need to be all singing all dancing from the start. At one time the WMF used
> the agile methodology and you can break up a project like this in parts,
> functional parts.
>
> * The first part is a hack to replace the current code with
> internationalised code and have it localised in Translatewiki.net.
> * You then want to build in functionality that measures its use. It also
> measures the extend labeling expands in Wikidata because of this tool. In
> essence this is not essential.
> * As the tool becomes more popular, it follows that the database may need
> tuning to allow for its expanded use
>
> * A next phase is for the code to be made into an extension enabling the
> native use in MediaWiki projects.  This does not mean Commons, it may be in
> any language projects that cares to use it. It is particularly the small
> languages (less than 100.000 articles).
> * Given that measurements are in place, it then follows that we learn what
> it takes to expand the usage of images. Not only but also for our projects.
> For a first time the small languages take precedence.. The primary reason
> is that for those languages there are few pictures that they find when they
> google or bing.
> * When there is an expressed demand for bigger languages < 1.000.000
> articles, we add these on the basis of a first come, first served basis.
> This is to ensure a steady growth path in the usage.
> * Once we understand the scaling issues, we can expand to Commons itself
> and any and all projects.
> * Once we consider sharing freely licensed media files a priority, we can
> speed the process up within the limits of what is technically feasible.
>
> At the same time, we 

Re: [Wikimedia-l] Giving Commons a bigger public

[Gerard Meijssen]

Hoi,
I have been a professional developer for much of my working life. From what
I know of what Hay has done, I know you are wrong depending on the approach
taken. Building this functionality can be an iterative process, it does not
need to be all singing all dancing from the start. At one time the WMF used
the agile methodology and you can break up a project like this in parts,
functional parts.

* The first part is a hack to replace the current code with
internationalised code and have it localised in Translatewiki.net.
* You then want to build in functionality that measures its use. It also
measures the extend labeling expands in Wikidata because of this tool. In
essence this is not essential.
* As the tool becomes more popular, it follows that the database may need
tuning to allow for its expanded use

* A next phase is for the code to be made into an extension enabling the
native use in MediaWiki projects.  This does not mean Commons, it may be in
any language projects that cares to use it. It is particularly the small
languages (less than 100.000 articles).
* Given that measurements are in place, it then follows that we learn what
it takes to expand the usage of images. Not only but also for our projects.
For a first time the small languages take precedence.. The primary reason
is that for those languages there are few pictures that they find when they
google or bing.
* When there is an expressed demand for bigger languages < 1.000.000
articles, we add these on the basis of a first come, first served basis.
This is to ensure a steady growth path in the usage.
* Once we understand the scaling issues, we can expand to Commons itself
and any and all projects.
* Once we consider sharing freely licensed media files a priority, we can
speed the process up within the limits of what is technically feasible.

At the same time, we keep the standalone function available. It will serve
a subset of our potential public. This will help us understand the pent up
demand for a service like this. When the WMF is truly  "agile" in its
development, it is a business decision what priority it gets. Much of what
I describe has been done by us before; it is not rocket science. The first
phase could be done within a month. Scaling up the usage and integrating it
in existing code and projects may indeed take the best of a year. Again,
that is not so much a technical but much more a business consideration. As
always, technical issues may crop up and they are refactored in an agile
process.
Thanks,
  GerardM

On Sun, 24 May 2020 at 20:36, Michael Peel  wrote:

> Hi Gerard,
>
> I mostly agree with you. However, I disagree with this:
>
> > This proof of concept is largely based on existing WMF functionality so
> it
> > takes very little for the Wikimedia Foundation to adopt the code, do it
> > properly particularly for the Internationalisation.
>
> Turning prototype code into production code is never trivial. When you’re
> writing a prototype, you get to skip all performance and edge case
> concerns, and you don’t need to integrate it into existing code, you’re
> just interested in getting something working. I hope (and expect) that the
> WMF will make improvements to Commons’ multilingual search in the future,
> but it’s definitely not a “very little” amount of work that needs doing,
> it’s a year or more worth of developer time.
>
> Thanks,
> Mike
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Giving Commons a bigger public

[Michael Peel]

Hi Gerard,

I mostly agree with you. However, I disagree with this:

> This proof of concept is largely based on existing WMF functionality so it
> takes very little for the Wikimedia Foundation to adopt the code, do it
> properly particularly for the Internationalisation.

Turning prototype code into production code is never trivial. When you’re 
writing a prototype, you get to skip all performance and edge case concerns, 
and you don’t need to integrate it into existing code, you’re just interested 
in getting something working. I hope (and expect) that the WMF will make 
improvements to Commons’ multilingual search in the future, but it’s definitely 
not a “very little” amount of work that needs doing, it’s a year or more worth 
of developer time.

Thanks,
Mike
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Giving Commons a bigger public

[Gerard Meijssen]

Hoi,
Indeed, we have all known what things are possible and, indeed we have all
been calling for a change in the "Commons experience". Now the great thing
of this "proof of concept" is that at this time it stands alone. It
demonstrates that multilingual search can be harnessed in what is only a
translatable user interface. As we speak there are seven translations
available including Japanese and Portuguese. Three translations are waiting
in the wings to become active.

This proof of concept is largely based on existing WMF functionality so it
takes very little for the Wikimedia Foundation to adopt the code, do it
properly particularly for the Internationalisation. Once it is available,
there is nothing stopping a language community enabling it on their
projects INCLUDING by having a main page for Commons in that language. That
could be a strategy when the Commons community prevents its use for
English..

Again, the approach here is for growing this functionality organically.
There is no need for everything to be complete, for all the files to be
linked to Wikidata items. It does not matter when a language has only a few
labels in Wikidata, it is a start. As more labels become available it
really quickly becomes useful for that language not only in Commons but
also for Wikidata (consider Reasonator like functionality. Just consider
googling for pictures in that language and that will open your eyes to the
opportunity we have in front of us.

What I also hope for is for the Wikimedia Foundation to consider is that
there is more to offer than just Wikipedia. It does not take much to start
opening up Commons. It does not take much to see information in a
Reasonator kinda approach. The "omdenken" [1] that it requires is for WMF
to consider growing our endusers and not only considering growing our
contributing community.

PS Allessandro, please do add Italian to the list that has a translation
for the prototype...
Thanks,
  GerardM

[1] https://omdenken.com/flip-thinking/



On Sun, 24 May 2020 at 17:39, Alessandro Marchetti via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

>  First of all, good job. I appreciate that.
>
> To be honest, however, some of us did not need a "proof of concept" to
> know that this was possible, we would have helped to build it years ago if
> the situation allowed it. it did not, the "social" environment was against
> it. We could not de facto support the metadata architecture with a
> bottom-up approach and a top-down strategy was necessary to go forward and,
> as a result, their quality is limited... so any service based on them will
> be limited as well for a while. It's a step in the right direction and I
> wish you all the best... you need me to translate in Italian, fine, I am
> here.
>
> The problem is however that it took more time than necessary to get there
> and it would be useful to face that. You don't have to explain to many of
> us what metadata were for in the end and what long-term change they can
> introduce, we knew that because you can see their use in many other
> platforms an get an idea how they are supposed to work...even newbies with
> professional experience got the concept that Wikidata could help Commons,
> by themselves. So the question is IMHO how this changes the minds of active
> users who did and do not care even now.
>
> Something of course changed over the years... nothing is static. When the
> Wikidata infobox arrived the comments of distrust of Wikidata drastically
> reduced, but it was not long time before this introduction that some
> Commons users were still insulting you for leaving a welcome template on
> their Wikidata talk page.
> Is their attitude the core reason why these efforts are late? IMHO it is.
> Is it going to be solved? Because if it's not, this introduction wlll be in
> any case very slow. A bumpy road. We will have two mentalities coexisting
> at the same time, as we have for example with metadata.
>
> Also, what does it mean for us who are active also in the real world? Not
> a greta change yet if the timeline is slow. When I went to a third party I
> had to say Commons was late on many issues (categorization, metadata,
> search engine, metrics, copyright guidelines, lack of analytical instrument
> for the backlog, workflow of NC files...) and no doubt such gaps were going
> to be filled one day but not soon (definitely much slower than many other
> issues on other platforms). Now I can say it's still late and is (as
> expected) catching up on this issue. Still, the third party won't be
> impressed, the reply will be "good. call me when it's ready". Which is
> fair, they are doing their job.
> I can't change that yet. I don't know how my attitude can change it. I
> still think that this relies on the attitude of the bulk of users that even
> now are not interested in dealing with such long-term issues of Commons and
> any effort will wait a lot to get a clear feedback.
>
>
>
>
>
>
> Il domenica 24 maggio 2020, 

Re: [Wikimedia-l] Giving Commons a bigger public

[Alessandro Marchetti via Wikimedia-l]

 First of all, good job. I appreciate that.

To be honest, however, some of us did not need a "proof of concept" to know 
that this was possible, we would have helped to build it years ago if the 
situation allowed it. it did not, the "social" environment was against it. We 
could not de facto support the metadata architecture with a bottom-up approach 
and a top-down strategy was necessary to go forward and, as a result, their 
quality is limited... so any service based on them will be limited as well for 
a while. It's a step in the right direction and I wish you all the best... you 
need me to translate in Italian, fine, I am here. 

The problem is however that it took more time than necessary to get there and 
it would be useful to face that. You don't have to explain to many of us what 
metadata were for in the end and what long-term change they can introduce, we 
knew that because you can see their use in many other platforms an get an idea 
how they are supposed to work...even newbies with professional experience got 
the concept that Wikidata could help Commons, by themselves. So the question is 
IMHO how this changes the minds of active users who did and do not care even 
now. 

Something of course changed over the years... nothing is static. When the 
Wikidata infobox arrived the comments of distrust of Wikidata drastically 
reduced, but it was not long time before this introduction that some Commons 
users were still insulting you for leaving a welcome template on their Wikidata 
talk page.
Is their attitude the core reason why these efforts are late? IMHO it is. Is it 
going to be solved? Because if it's not, this introduction wlll be in any case 
very slow. A bumpy road. We will have two mentalities coexisting at the same 
time, as we have for example with metadata.

Also, what does it mean for us who are active also in the real world? Not a 
greta change yet if the timeline is slow. When I went to a third party I had to 
say Commons was late on many issues (categorization, metadata, search engine, 
metrics, copyright guidelines, lack of analytical instrument for the backlog, 
workflow of NC files...) and no doubt such gaps were going to be filled one day 
but not soon (definitely much slower than many other issues on other 
platforms). Now I can say it's still late and is (as expected) catching up on 
this issue. Still, the third party won't be impressed, the reply will be "good. 
call me when it's ready". Which is fair, they are doing their job.
I can't change that yet. I don't know how my attitude can change it. I still 
think that this relies on the attitude of the bulk of users that even now are 
not interested in dealing with such long-term issues of Commons and any effort 
will wait a lot to get a clear feedback.






Il domenica 24 maggio 2020, 15:38:36 CEST, Gerard Meijssen 
 ha scritto:  
 
 Hoi,
Mike you are absolutely right but you are missing the point that I am
trying to make. Yes, what is exposed by Hay's SDSEARCH tool is based on all
the work that was done before and as such it relies absolutely on the work
that has been done before. Without it, this tool would not be possible.
This work is key for us to move forward.

What is so vitally important about this proof of concept is that it readily
opens up Commons depending on a localised user interface. Even when that is
not available search, it is possible based to search based on the
availability of labels in a language. This proof of concept dramatically
shows that nothing more is needed to open up Commons to a multilingual
public.

This proof of concept is an invitation to adopt this approach and make it
available in properly internationalised code as part of a multilingual
Commons user interface. It invites people to participate and with some
social engineering it the shore that turns the ship in making Commons a
much more positive place. Why, because making Commons usable even useful is
what we have not done for all the languages but English. When people are
happy to use Commons, they are more likely to participate and join its
community.

So far we could not care less as long as it was used in our own projects.
The challenge that I present to you is to make Commons *my goto place* for
illustrations for my blog. When you can convince me, you convince the world.

Remember our approach is that of a wiki. It does not have to be perfect, it
has to empower us to move forward.
Thanks,
      GerardM



On Sun, 24 May 2020 at 15:12, Michael Peel  wrote:

> Hi all,
>
> It’s worth remembering that this functionality is built in to Commons,
> it’s just not as user-friendly. From the example below, if you put
> "haswbstatement:P180=Q191931” into the Commons searchbox, you will get the
> same results. Thanks to the structured data on commons project+team!
>
> Also, around half of the Commons categories now have multilingual labels
> embedded in them through the Wikidata Infobox, which means that if you do
> an ordinary search for a 

Re: [Wikimedia-l] Giving Commons a bigger public

[Gerard Meijssen]

Hoi,
Mike you are absolutely right but you are missing the point that I am
trying to make. Yes, what is exposed by Hay's SDSEARCH tool is based on all
the work that was done before and as such it relies absolutely on the work
that has been done before. Without it, this tool would not be possible.
This work is key for us to move forward.

What is so vitally important about this proof of concept is that it readily
opens up Commons depending on a localised user interface. Even when that is
not available search, it is possible based to search based on the
availability of labels in a language. This proof of concept dramatically
shows that nothing more is needed to open up Commons to a multilingual
public.

This proof of concept is an invitation to adopt this approach and make it
available in properly internationalised code as part of a multilingual
Commons user interface. It invites people to participate and with some
social engineering it the shore that turns the ship in making Commons a
much more positive place. Why, because making Commons usable even useful is
what we have not done for all the languages but English. When people are
happy to use Commons, they are more likely to participate and join its
community.

So far we could not care less as long as it was used in our own projects.
The challenge that I present to you is to make Commons *my goto place* for
illustrations for my blog. When you can convince me, you convince the world.

Remember our approach is that of a wiki. It does not have to be perfect, it
has to empower us to move forward.
Thanks,
   GerardM



On Sun, 24 May 2020 at 15:12, Michael Peel  wrote:

> Hi all,
>
> It’s worth remembering that this functionality is built in to Commons,
> it’s just not as user-friendly. From the example below, if you put
> "haswbstatement:P180=Q191931” into the Commons searchbox, you will get the
> same results. Thanks to the structured data on commons project+team!
>
> Also, around half of the Commons categories now have multilingual labels
> embedded in them through the Wikidata Infobox, which means that if you do
> an ordinary search for a phrase in a different language, you should find
> the correct commons category if it exists. E.g., try searching for
> “Telescopio Lovell”, or "洛弗尔望远镜". The infobox also has a link at the bottom
> of it that you can click on to search depicts statements for that
> category’s topic without having to look up the QID first.
>
> Thanks,
> Mike
>
> > On 24 May 2020, at 10:30, Gerard Meijssen 
> wrote:
> >
> > Hoi,
> > Two more localisations became available, one for German and one for
> > Swedish. I have asked Alolita if she would help us with a localisation in
> > an Indian language. Anthere, would you be so kind and reach out so that
> we
> > have a localisation in an African language as well.. (French would also
> be
> > good to have :) )
> >
> > In the mean time I have linked pictures of the kakapoa to its Wikidata
> > item, you can search for it in Maori.
> >
> > For me the point of this proof of concept is that we already can expose
> > material in any of our languages. We can make this available and promote
> > the addition of "depicts" statements in Commons and labels in Wikidata.
> In
> > a true Wiki way it brings additional functionality to any and all of our
> > users.. It will improve over time.
> >
> > When we are to know the extend of its usefulness, we need continuous
> > statistics (we have them for Reasonator as well, just as an example).
> > Thanks,
> >   GerardM
> >
> > On Sun, 24 May 2020 at 07:33, Gerard Meijssen  >
> > wrote:
> >
> >> Hoi,
> >> Florence I totally agree that proper internatonalisation, localisation
> is
> >> key. What is key for me is that this already provides an easy and
> obvious
> >> search function for mediafiles that have a link to a Wikidata item.
> Just to
> >> stress the point, this is a wiki, we do not need a fully functional
> search
> >> engine (for all the Commons files); that is what we aspire to that is
> what
> >> we work towards.. That will take years. But with a proper search tool, a
> >> tool that makes it EASY to use Commons, it may fool me into using
> Commons
> >> for my blog.
> >>
> >> To show you that it works, I just looked for "baisikeli
> >> " and made a
> screenshot
> >> [1]. The screenshot is with other files showing the evolution of this
> tool
> >> in a Commons category [2]
> >>
> >> Important to notice is that the tool DOES invite you to localise the
> >> labels to French, Swahili et al for best results!!
> >>
> >> A minor observation, there are all kinds of things that could change in
> >> the user interface. Key is that this is a prototype. It is showing us
> how
> >> we can make Commons work for us.
> >> Thanks,
> >>   GerardM
> >>
> >> [1] https://commons.wikimedia.org/wiki/File:Appelmoes3.png
> >> [2] https://commons.wikimedia.org/wiki/Category:Hay%27s_SDSEARCH
> >>
> >> On Sun, 24 May 2020 

Re: [Wikimedia-l] Giving Commons a bigger public

[Michael Peel]

Hi all,

It’s worth remembering that this functionality is built in to Commons, it’s 
just not as user-friendly. From the example below, if you put 
"haswbstatement:P180=Q191931” into the Commons searchbox, you will get the same 
results. Thanks to the structured data on commons project+team!

Also, around half of the Commons categories now have multilingual labels 
embedded in them through the Wikidata Infobox, which means that if you do an 
ordinary search for a phrase in a different language, you should find the 
correct commons category if it exists. E.g., try searching for “Telescopio 
Lovell”, or "洛弗尔望远镜". The infobox also has a link at the bottom of it that you 
can click on to search depicts statements for that category’s topic without 
having to look up the QID first.

Thanks,
Mike

> On 24 May 2020, at 10:30, Gerard Meijssen  wrote:
> 
> Hoi,
> Two more localisations became available, one for German and one for
> Swedish. I have asked Alolita if she would help us with a localisation in
> an Indian language. Anthere, would you be so kind and reach out so that we
> have a localisation in an African language as well.. (French would also be
> good to have :) )
> 
> In the mean time I have linked pictures of the kakapoa to its Wikidata
> item, you can search for it in Maori.
> 
> For me the point of this proof of concept is that we already can expose
> material in any of our languages. We can make this available and promote
> the addition of "depicts" statements in Commons and labels in Wikidata. In
> a true Wiki way it brings additional functionality to any and all of our
> users.. It will improve over time.
> 
> When we are to know the extend of its usefulness, we need continuous
> statistics (we have them for Reasonator as well, just as an example).
> Thanks,
>   GerardM
> 
> On Sun, 24 May 2020 at 07:33, Gerard Meijssen 
> wrote:
> 
>> Hoi,
>> Florence I totally agree that proper internatonalisation, localisation is
>> key. What is key for me is that this already provides an easy and obvious
>> search function for mediafiles that have a link to a Wikidata item. Just to
>> stress the point, this is a wiki, we do not need a fully functional search
>> engine (for all the Commons files); that is what we aspire to that is what
>> we work towards.. That will take years. But with a proper search tool, a
>> tool that makes it EASY to use Commons, it may fool me into using Commons
>> for my blog.
>> 
>> To show you that it works, I just looked for "baisikeli
>> " and made a screenshot
>> [1]. The screenshot is with other files showing the evolution of this tool
>> in a Commons category [2]
>> 
>> Important to notice is that the tool DOES invite you to localise the
>> labels to French, Swahili et al for best results!!
>> 
>> A minor observation, there are all kinds of things that could change in
>> the user interface. Key is that this is a prototype. It is showing us how
>> we can make Commons work for us.
>> Thanks,
>>   GerardM
>> 
>> [1] https://commons.wikimedia.org/wiki/File:Appelmoes3.png
>> [2] https://commons.wikimedia.org/wiki/Category:Hay%27s_SDSEARCH
>> 
>> On Sun, 24 May 2020 at 01:21, Florence Devouard 
>> wrote:
>> 
>>> 
>>> Le 24/05/2020 à 00:23, Erik Moeller a écrit :
 On Fri, May 22, 2020 at 10:10 AM Gerard Meijssen
  wrote:
 
> Hay Kranen created a proof of concept where Commons is searched for
> pictures that (per standard) use a "depicts" statement.
 This is a beautiful proof of concept; thank you for sharing it,
 Gerard, and thank you, Hay, for developing it. It really illustrates
 the power and importance of the Structured Data efforts.
 
 To pick a different example, imagine that you want to illustrate an
 article about the importance of wheelchair accessibility at your
 university. You might try a major search engine like Google Images.
 Try replacing the word "wheelchair" with translations in other
 languages. Note how the result sets are different, and how you may get
 a much smaller set of results in languages with a smaller Internet
 presence.
 
 https://www.google.com/search?q=wheelchair=isch (English)
 https://www.google.com/search?q=kitimaguru=isch (Swahili, far less
 relevant and smaller set)
 
 In contrast, the use of Wikidata items means that, as long as a label
 exists for a given language, you can search in _any_ language and get
 the same images:
 
 https://tools.wmflabs.org/hay/sdsearch/#q=haswbstatement:P180=Q191931
 
 The fact that the UI of this tool is currently English is an
 implementation detail; even with Hay's implementation, you can type in
 "kitimaguru" and get the same results as in English.
>>> 
>>> 
>>> Sorry Erik, but I do not follow you here...
>>> 
>>> For some reasons, it is true for "kitimaguru", but if I search for
>>> "lamp" (EN) versus "lampe" (FR), or "key" (English) 

Re: [Wikimedia-l] Giving Commons a bigger public

[Gerard Meijssen]

Hoi,
Two more localisations became available, one for German and one for
Swedish. I have asked Alolita if she would help us with a localisation in
an Indian language. Anthere, would you be so kind and reach out so that we
have a localisation in an African language as well.. (French would also be
good to have :) )

In the mean time I have linked pictures of the kakapoa to its Wikidata
item, you can search for it in Maori.

For me the point of this proof of concept is that we already can expose
material in any of our languages. We can make this available and promote
the addition of "depicts" statements in Commons and labels in Wikidata. In
a true Wiki way it brings additional functionality to any and all of our
users.. It will improve over time.

When we are to know the extend of its usefulness, we need continuous
statistics (we have them for Reasonator as well, just as an example).
Thanks,
   GerardM

On Sun, 24 May 2020 at 07:33, Gerard Meijssen 
wrote:

> Hoi,
> Florence I totally agree that proper internatonalisation, localisation is
> key. What is key for me is that this already provides an easy and obvious
> search function for mediafiles that have a link to a Wikidata item. Just to
> stress the point, this is a wiki, we do not need a fully functional search
> engine (for all the Commons files); that is what we aspire to that is what
> we work towards.. That will take years. But with a proper search tool, a
> tool that makes it EASY to use Commons, it may fool me into using Commons
> for my blog.
>
> To show you that it works, I just looked for "baisikeli
> " and made a screenshot
> [1]. The screenshot is with other files showing the evolution of this tool
> in a Commons category [2]
>
> Important to notice is that the tool DOES invite you to localise the
> labels to French, Swahili et al for best results!!
>
> A minor observation, there are all kinds of things that could change in
> the user interface. Key is that this is a prototype. It is showing us how
> we can make Commons work for us.
> Thanks,
>GerardM
>
> [1] https://commons.wikimedia.org/wiki/File:Appelmoes3.png
> [2] https://commons.wikimedia.org/wiki/Category:Hay%27s_SDSEARCH
>
> On Sun, 24 May 2020 at 01:21, Florence Devouard 
> wrote:
>
>>
>> Le 24/05/2020 à 00:23, Erik Moeller a écrit :
>> > On Fri, May 22, 2020 at 10:10 AM Gerard Meijssen
>> >  wrote:
>> >
>> >> Hay Kranen created a proof of concept where Commons is searched for
>> >> pictures that (per standard) use a "depicts" statement.
>> > This is a beautiful proof of concept; thank you for sharing it,
>> > Gerard, and thank you, Hay, for developing it. It really illustrates
>> > the power and importance of the Structured Data efforts.
>> >
>> > To pick a different example, imagine that you want to illustrate an
>> > article about the importance of wheelchair accessibility at your
>> > university. You might try a major search engine like Google Images.
>> > Try replacing the word "wheelchair" with translations in other
>> > languages. Note how the result sets are different, and how you may get
>> > a much smaller set of results in languages with a smaller Internet
>> > presence.
>> >
>> > https://www.google.com/search?q=wheelchair=isch (English)
>> > https://www.google.com/search?q=kitimaguru=isch (Swahili, far less
>> > relevant and smaller set)
>> >
>> > In contrast, the use of Wikidata items means that, as long as a label
>> > exists for a given language, you can search in _any_ language and get
>> > the same images:
>> >
>> > https://tools.wmflabs.org/hay/sdsearch/#q=haswbstatement:P180=Q191931
>> >
>> > The fact that the UI of this tool is currently English is an
>> > implementation detail; even with Hay's implementation, you can type in
>> > "kitimaguru" and get the same results as in English.
>>
>>
>> Sorry Erik, but I do not follow you here...
>>
>> For some reasons, it is true for "kitimaguru", but if I search for
>> "lamp" (EN) versus "lampe" (FR), or "key" (English) versus "clé"
>> (French), I really do not get the same results at all and of course, it
>> does not proposes me the same Qs.
>>
>> I love that functionality, do not get me wrong, I am delighted to see it.
>>
>> But except for English speakers (and now Dutch speakers it seems), it
>> can not be used.
>>
>> So wonderful proof of concept. But please... let's have all languages
>> here !
>>
>> Florence
>>
>>
>> >
>> > It would be wonderful to see this functionality developed further, and
>> > to ultimately make this kind of search functionality central to the
>> > user experience for Wikimedia Commons, so that speakers of any
>> > language are  given _meaningful_ access to freely reusable media.
>> >
>> > Warmly,
>> >
>> > Erik
>> >
>> > ___
>> > Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
>> https://meta.wikimedia.org/wiki/Wikimedia-l
>> > New 

Re: [Wikimedia-l] Trust and safety on Wikimedia projects

[effe iets anders]

How is a one-off ban comparable in any way with a structured effort to
develop a policy in consultation with the community, and then implement it
together?

Lodewijk

On Sat, May 23, 2020 at 10:02 PM Todd Allen  wrote:

> Worked out great the last time WMF tried to pull something like this,
> didn't it?
>
>
> https://en.wikipedia.org/wiki/Wikipedia:Community_response_to_the_Wikimedia_Foundation%27s_ban_of_Fram
>
>
> Oh, wait. By "worked out great" I mean "was an unmitigated disaster." One
> wonders if the folks at the WMF are capable of learning from mistakes, and
> one is not encouraged by the apparent answer.
>
> Todd
>
> On Fri, May 22, 2020 at 3:59 PM María Sefidari 
> wrote:
>
> >  Hello everyone,
> >
> > Today, the Wikimedia Foundation Board of Trustees unanimously passed a
> > resolution and published a statement[1] regarding the urgent need to make
> > our movement more safe and inclusive by addressing harassment and
> > incivility on Wikimedia projects. The statement builds on prior
> statements
> > from 2016 and 2019,[2][3] affirms the forthcoming introduction of a
> > universal code of conduct, and directs the Wikimedia Foundation to
> rapidly
> > and substantively address these challenges in complement with existing
> > community processes.
> >
> > This includes developing sustainable practices and tools that eliminate
> > harassment, toxicity, and incivility, promote inclusivity, cultivate
> > respectful discourse, reduce harms to participants, protect the projects
> > from disinformation and bad actors, and promote trust in our projects.
> >
> > Over the past nearly twenty years, the movement has taken a number of
> > unique and sometimes extraordinary steps to create an environment unlike
> > anything else online: a place to share knowledge, to learn, and to
> > collaborate together. In order for the movement to continue to thrive and
> > make progress to our mission, it is essential to build a culture that is
> > welcoming and inclusive.
> >
> > Research has consistently shown that members of our communities have been
> > subject to hostility and toxic behavior in Wikimedia spaces.[4][5] The
> > Wikimedia 2030 movement strategy recommendations have also identified the
> > safety of our Wikimedia spaces as a core issue to address if we are to
> > reach the 2030 goals, with concrete recommendations which include a
> > universal code of conduct, pathways for users to privately report
> > incidents, and a baseline of community responsibilities.[6]
> >
> > While the movement has made progress in addressing harassment and toxic
> > behavior, we recognize there is still much more to do. The Board’s
> > resolution and statement today is a step toward establishing clear,
> > consistent guidelines around acceptable behavior on our projects, and
> > guiding the Wikimedia Foundation in supporting the movement’s ability to
> > ensure a healthy environment for those who participate in our projects.
> >
> > * Developing and introducing, in close consultation with volunteer
> > contributor communities, a universal code of conduct that will be a
> binding
> > minimum set of standards across all Wikimedia projects;
> >
> > * Taking actions to ban, sanction, or otherwise limit the access of
> > Wikimedia movement participants who do not comply with these policies and
> > the Terms of Use;
> >
> > * Working with community functionaries to create and refine a retroactive
> > review process for cases brought by involved parties, excluding those
> cases
> > which pose legal or other severe risks; and
> >
> > * Significantly increasing support for and collaboration with community
> > functionaries primarily enforcing such compliance in a way that
> prioritizes
> > the personal safety of these functionaries.
> >
> > Together, we have made our movement what it is today. In this same way,
> we
> > must all be responsible for building the positive community culture of
> the
> > future, and accountable for stopping harassment and toxic behavior on our
> > sites.
> >
> > We have also made this statement available on Meta-Wiki for translation
> and
> > wider distribution.[1]
> >
> > On behalf of the Board,
> > María, Board Chair
> >
> > [1]
> >
> >
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard/May_2020_-_Board_of_Trustees_on_Healthy_Community_Culture,_Inclusivity,_and_Safe_Spaces
> >
> > [2]
> >
> >
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard/November_2016_-_Statement_on_Healthy_Community_Culture,_Inclusivity,_and_Safe_Spaces
> >
> > [3]
> >
> >
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard/Archives/2019#Board_statement_posted_at_Community_response_to_the_Wikimedia_Foundation's_ban_of_Fram
> >
> > [4] https://meta.wikimedia.org/wiki/Research:Harassment_survey_2015
> >
> > [5]
> >
> >
> https://meta.wikimedia.org/wiki/Community_Insights/2018_Report#Experience_of_harassment_has_not_declined_since_2017_and_appears_to_remain_steady
> >
> >