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

2020-05-24 Thread 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 k

Re: [Wikimedia-l] Why we changed

2016-02-22 Thread Hay (Husky)
Hey everyone,
i'd really like to reaffirm what Àlex wrote in his mail: let's start
with people, not technology.

When i read this in Lila's message:
> Many companies copy our knowledge into their own databases and
> present it inside their interfaces. While this supports wider
> dissemination, it also separates our readers from our community.
It seems like it's a bad thing that people reuse our work. But isn't
that the whole point of our mission? Wikipedia might be the last big
site on the internet where the main focus is not on getting everyone
to share their content in the same walled garden (like Facebook,
Google, Twitter, etc.) but on altruistically creating something that
benefits the whole world.

I completely agree that Wikimedia should be a high-tech organization.
I'm very glad that the focus of development (and user experience in
particular) has shifted to the WMF the last couple of years, bringing
us great improvements like the Visual Editor. But we should not never
forget the purpose of all those improvements: it's to better serve the
community and our mission. We shouldn't be building tech for tech's
sake!

Everyone who has spent more than a few years in this community knows
how incredibly difficult it is to balance the needs of the editors,
the readers, and developers. I'm incredibly grateful to those who
managed to make improvements while not disturbing that balance too
much. Unfortunately, many of these people have left the WMF the last
few years, and that's a very sad thing. It's hard to get good people,
it's even harder to replace them when they're gone.

However important those technical improvements are, the greatest asset
of our movement is not the software we built. It's not even the hard
working people in chapters and the WMF. It's the more than 26 million
people who have had the courage in the last fifteen years to press the
'edit' button and voluntarily gave their time and knowledge for the
common good. When major decisions are made, we should be very sure
that they benefit those people.

Best,
-- Hay / Husky

On Mon, Feb 22, 2016 at 5:29 PM, Austin Hair  wrote:
> I think everyone should remember that sarcasm, and tone in general,
> frequently do not come through across the wires, as it were.
>
> For that matter, please, stay civil. I'm happy to report that I
> haven't had to moderate anyone, yet, but I think we can all appreciate
> the current circumstances.
>
> Austin
>
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Public Domain Day

2014-01-06 Thread Hay (Husky)
@Jane: Yes, that's pretty much correct. The URAA is a pain in the ***
if you know what i mean. For example, virtually all works by Theo van
Doesburg are not usable on Commons because they're painted after 1923,
even though in the Netherlands his works have been PD since 2002.

On Fri, Jan 3, 2014 at 9:01 PM, Jane Darnell  wrote:
> Romaine,
> I was wondering about the same thing as Yaroslav.
>
> As I have understood the URAA stuff up to now, I think a work by
> Kandinsky (died Dec 1944) is problematic but this one for example is
> OK (author died in 1943, but the work is dated before 1923):
> https://commons.wikimedia.org/wiki/File:Angorakatze1903.jpg
>
> Jane
>
> 2014/1/3, Yaroslav M. Blanter :
>> On 03.01.2014 15:03, Romaine Wiki wrote:
>>> hello all!
>>>
>>> January 1st was Public Domain Day [1] and after xx years of
>>> copyright, it expires on the first of January of the year after. As
>>> result hundreds of images were restored on Commons on the 1-1-2014,
>>> but many of them did not get a place in articles on Wikipedia and her
>>> sister projects.
>>>
>>> I added all the restored media to this gallery:
>>> https://commons.wikimedia.org/wiki/User:Romaine/Public_Domain_Day/2013
>>>
>>> Everyone is invited to place those images in appropriate places in
>>> articles!
>>>
>>>
>>> Romaine
>>>
>>>
>> Hi Romaine,
>>
>> did you take the URAA provisions into account? I am afraid most of the
>> files we though would be free are in fact not free: If the author died
>> in 1943, in most of the countries the works were not free in 1996, which
>> is the URAA dead hour. Then the date should be not 70 years from the
>> death of the author but 95 years since creation (except if the work was
>> created before 1923), which means only pre-1923 works become free.
>>
>> Cheers
>> Yaroslav
>>
>> ___
>> Wikimedia-l mailing list
>> Wikimedia-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> 
>
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> 

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] [cultural-partners] When was the first...? Your input is needed

2013-11-11 Thread Hay (Husky)
On Fri, Nov 8, 2013 at 10:39 PM, Ryan Kaldari  wrote:
> The first Wiki photo competition (that I'm aware of) was Wikipedia Takes
> Manhattan in Spring 2008.
> https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Takes_Manhattan/Spring_2008
The first "big" photo competition was Wiki Loves Art, during june 2009:

https://commons.wikimedia.org/wiki/Commons%3AWiki_Loves_Art_Netherlands

We had 45 museums participating back then, resulting in 5500 photographs.

-- Hay

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Wikipedia redefined -- typography and UX and such

2012-08-07 Thread Hay (Husky)
Yup, i think it's pretty nice. I especially like the 'edit' modus with
the live edit view. And the colored bars on the top of the main page
indicating the number of articles in a certain language.

-- Hay

On Tue, Aug 7, 2012 at 11:47 PM, Michel Vuijlsteke  wrote:
> Well, it's certainly a possible starting point for discussion:
> http://www.wikipediaredefined.com/
>
> --
> Michel Vuijlsteke
> http://blog.zog.org
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l