Re: [Commons-l] [Multimedia] How to disable MediaViewer for some images
I'd recommend avoiding classes specific to MultimediaViewer for this purpose. The semantic intent here is to mark images that are not considered part of regular article content. These would be presentational elements like user interface icons, images part of a larger construct (such as clipped images, map pins etc.). It's not at all related to MultimediaViewer and is useful for other tools as well. Don't forget that what MMV is doing is by no means new. Gadgets like these have existed for years and people will continue to use and develop these. This is good; we want people to stay inspired (and even competitive in a way). These gadgets would greatly benefit from a simple class name filter to replace their current approach (lots of exceptions for arbitrary class names, and individual patterns like "Clear crystal" icon). Making this MMV-specific would give MMV special treatment resulting in hacks and maintenance burdens we don't want. A class like no-mmv" masks the real intent. In my experience that would discourage communication between users and developers when issues arise. Not the users that read it here, but the users that copy it further down the line; whom won't know its purpose. Making it specific to the idea of a "viewer" (e.g. "no-viewer", "viewer-exclude", or "for-page-only") is better in my opinion, but only marginally so. I'd recommend aiming for something that reflects what it is and allows separation of concerns. Then have MMV use that in its filters. This may mean we'll need two instead of one if the types of images in this category are that different, but that would imho be a good thing. — Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] SearchExtraNs extension
On Nov 2, 2012, at 10:32 AM, Erik Moeller wrote: > On Fri, Nov 2, 2012 at 2:29 AM, Andrew Gray wrote: >> I can imagine it being amazingly useful (particularly with autocompletion, >> but even without...). Alternatively, given the major role categories play >> for Commons compared to most mediawiki projects, is it possible to simply >> enable searching the category: namespace by default? > > It's already in the default search mask, so categories and other > default search namespaces will come up in fulltext search (your own > user preferences may be different, but that's the behavior for new or > logged out users) -- but the instant lookup (what used to be the "Go" > button) only works on the main namespace, or if you provide the > namespace prefix/alias. > See also https://bugzilla.wikimedia.org/show_bug.cgi?id=30323 -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Testing Upload Wizard Flickr import feature
On Aug 30, 2012, at 3:10 AM, Erik Moeller wrote:
> http://mwreview.wmflabs.org/wiki/index.php/Main_Page
>
> Just click the "Import from Flickr" button on the first page to get started.
>
Nice work. I like the integration with Upload Wizard.
Unfortunately it doesn't appear to work (for me). I tried uploading a photo but
it seems stuck on an infinite "Uploading..." for me (filed
https://bugzilla.wikimedia.org/39948).
>
> Since UW performs a license check, UW will also add a
> "VerifiedByUploadWizard" template which should help with the long term
> validation of licenses for Flickr imported content.
>
Ideally it would use the {{flickrreview}} template so that it integrates with
the patrol workflow (so far it exists). Similar to how [[User:FlickreviewR]]
auto-reviews files on Commons (except that it wouldn't be a separate edit).
Though to avoid hardcoding details for Commons too much, it could be done from
an interface message (similar to Extension:NewUserMessage, with a message
containing the wikitext boilerplate with $N parameters for various bits of
information).
> Known issues:
> * Getting a better 'source' value for each image - ideally we want the
> regular Flickr URL, not the farm server URL
> * Getting the description for each image, this may require separate
> calls to the Flickr API.
> * Making the 'author' value a link to the Flickr account
> * Supporting the feature to copy metadata across a whole batch, which
> is shown for regular batch uploads
>
Not sure what the current planning is, but it'd be nice if those features/issues
would be resolved before deployment on commons.wikimedia.org so that we can
fully obsolete the Toolserver tool that is currently often used for this (which
afaik does have these features):
http://toolserver.org/~bryan/flickr/upload
-- Krinkle
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] (no subject)
On Jul 10, 2012, at 12:40 PM, J.P.HLAVAC wrote: > > > sababa > > +1 -- Krinkl ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] PhotoCommons Wordpress plugin
I've re-added wikitech-l to the header since it was originally addressed to both and your question and my answer will update them at the same time. And since it's now mostly tech-oriented feedback from them would be nice as well. A general note: If you're filing a new bug or feature request [0], be sure to check open tickets [1] first ;-) Right now the purpose / features of the plugin are: * Easy searching of images on commons with autosuggested subjects * Click-and-pick from the results to insert it in the page or post. A WordPress shortcode is inserted into the post ([photocommons file="Example.jpg" with="200" align="right"]) which will be made into a linked thumbnail with hover tooltip when parsed * No need to maintain your posts if a file is moved on Commons, redirects work finen (since there are no paths or -tags hardcoded * No need to download/upload locally * Promote Wikimedia Commons as an easy-to-use source to add images to your blog or website and avoid people from googling for images and uploading or hotlinking random copyvios. On March 4 2011, Teofilo wrote: > 1) I have never used wordpress. What do I need to try wordpress and > your tool as a beginner easily for the first time ? > 2) How does your tool attribute photographers ? Can you provide a > screenshot showing attribution ? Is the attribution printed on paper > when the user prints the resulting page ? > 3) Are you using http://wiki.creativecommons.org/RDFa ? If relevant, > see my remarks at > http://commons.wikimedia.org/wiki/MediaWiki_talk:Stockphoto.js#.22Use_this_file.22_box_html_code_for_videos 1) Like for MediaWiki, you need a simple local AMP environment (eg. Apache, MySQL, PHP. So install something like LAMP or XAMPP, or get FTP access to an existing server with this). Then these 4 steps: * Install WordPress from the control panel of your webhost (if you have one) or download it from http://wordpress.org/, upload files, browse to them, follow instructions on-screen * Right now it's a development plugin, meaning not a plug-and-play for the general public yet, but for commos users and developers to see how it works and how it could be made better. To install the PhotoCommons plugin, check out most recent version from SVN [2] or download zip[3] * Follow install instructions (unzip, upload to /wp-content/plugins/wp- content, browse to your wp-admin -> Manage Plugins -> Click Activate) * Create or edit a new page or post on the wordpress site, next to the buttons to upload files locally to your blog there now is a Commons icon above the editor. Click it and have fun! * There's no step 5. 2) Since it is impossible right now to reliably extract such information we have choosen not to attempt to regex, hack, uglify our way out of it one way or another. We are waiting for the License integration project to finish at which point we will be able to dynamically extract this information from the API in a snap and cache it and display attribution and license under the thumbnail. For now we are taking the same approach as the Wikimedia wikis do (slightly better actually [4]), linking the thumnail directly to the Commons file page and the title of the image as tooltip when hovering the thumbnail. 3) We are not, see 2). I'm totally convinced this should be done, and we will as soon as licenses are integrated this will be done. -- Krinkle [0] https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia%20Tools&product=PhotoCommons [1] https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&component=PhotoCommons&resolution=---&product=Wikimedia%20Tools [2] * http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/wp-photocommons/ * http://www.mediawiki.org/wiki/SVN#Check_out * $ cd mywordpress/wp-content/plugins * $ svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/wp-photocommons [3] http://files.wmnederland.nl/downloads/latest.zip [4] Slightly better in that Wikimedia wikis link to the local cached/ transclusion instead of Commons directly. ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] re-enabling sitemaps for Commons, or, why your image isn't in Google
On 4 March 2011, Neil Kandalgaonkar wrote: > Google has introduced some nifty extensions to the Sitemap protocol, > including geocoding and (especially dear to our hearts) licensing![2] > However we don't have such information easily available in the > database, > so this requires parsing through every File page, which will take > several millenia. > > This will not work at all with the current sitemaps script as it scans > the entire database every time and regenerates a number of sitemaps > files from scratch. So, what we need is something more iterative, that > only scans recent stuff. (Or, using such extensions will have to wait > until someone brings licensing into the database). ... > > -- > Neil Kandalgaonkar Bryan, Roan and me are working on this: http://www.mediawiki.org/wiki/License_integration Right now we're mostly brainstorming for the best way to do this, we expect to plan real development within 2011 but it will most certainly take a while before it's done and stable, working, backwards complatible, proper usability, code reviewed and live on Commons. -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Fwd: [Foundation-l] Friendliness
Op 22 feb 2011, om 19:08 heeft Walter Siegmund het volgende geschreven: > I find that Safari does not display the preview of > File:Van_istendael675.jpg correctly. It displays as a dark negative > image. Camino does not display the preview and comments as follows on > the file itself. > "The image > “http://upload.wikimedia.org/wikipedia/commons/a/a9/Van_istendael675.jpg > ” cannot be displayed, because it contains errors." > > Google Chrome displays the file and preview properly. > http://commons.wikimedia.org/wiki/File:Van_istendael675.jpg > > Walter Siegmund Check https://bugzilla.wikimedia.org/show_bug.cgi?id=27635 -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Reuse content - malformed links
The links are not hardcoded in the script but stored in the license templates in the licensetpl_link hook. Example of the fix for GFDL: http://commons.wikimedia.org/?diff=47141947&oldid=45291781 Op 17 dec 2010, om 22:52 heeft Dereckson het volgende geschreven: > Hi, > > There is an issue with reuse content: when you click on the Use this > file on the web icon to get the attribution HTML code with links to > the licenses (there is a checkbox to enable/disable such links), links > doesn't include protocol, and so are relative links. > > e.g. generated code: > By Ranofuchs (Own work) [ href="www.gnu.org/copyleft/fdl.html">GFDL or href="www.creativecommons.org/licenses/by-sa/3.0">CC-BY- > SA-3.0-2.5-2.0-1.0], > >via > Wikimedia Commons > > From http://www.domain.tld/alpha.html, the GFDL link will so link to > http://www.domain.tld/www.gnu.org/copyleft/fdl.html. > > Where the links are stored? > If it's on messages on MediaWiki: namespace? --> which ones? > If it's on external code, could you point me the relevants files on > the SVN, so I can submit a patch on bugzilla? > > -- > Best Regards, > Sébastien Santoro aka Dereckson > http://commons.wikimedia.org/wiki/User:Dereckson > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Reuse content - malformed links
This is the Stockphoto.js script. I'll get right on it. Op 17 dec 2010, om 22:52 heeft Dereckson het volgende geschreven: > Hi, > > There is an issue with reuse content: when you click on the Use this > file on the web icon to get the attribution HTML code with links to > the licenses (there is a checkbox to enable/disable such links), links > doesn't include protocol, and so are relative links. > > e.g. generated code: > By Ranofuchs (Own work) [ href="www.gnu.org/copyleft/fdl.html">GFDL or href="www.creativecommons.org/licenses/by-sa/3.0">CC-BY- > SA-3.0-2.5-2.0-1.0], > >via > Wikimedia Commons > > From http://www.domain.tld/alpha.html, the GFDL link will so link to > http://www.domain.tld/www.gnu.org/copyleft/fdl.html. > > Where the links are stored? > If it's on messages on MediaWiki: namespace? --> which ones? > If it's on external code, could you point me the relevants files on > the SVN, so I can submit a patch on bugzilla? > > -- > Best Regards, > Sébastien Santoro aka Dereckson > http://commons.wikimedia.org/wiki/User:Dereckson > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Anonymous I18N
Op 7 dec 2010, om 09:01 heeft Michael Dale het volgende geschreven: > looks cool. > > Although maybe think a bit more about scalability. ie calling a php > script from toolserver on every page load won't scale. Better would be > an api hit with public expire: ( ie letting the result be cached in > the > shared squid cache for a few hours ) > http://commons.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=languages&format=json&smaxage=3600 Obviously it won't stay on the toolserver quering an object of languages that rarely ever changes. From my initial post: >> The script itself uses the toolserver to fetch a list of available >> languages and other data (as soon as development is fairly done I >> will >> move the script fully on-wiki - as it would not be handy (and not >> required) to require a toolserver-request on all pageloads for >> anonymous users, this is purely temporarily hosted on the Toolserver >> for now. The list of available languages doesn't change often anyway >> and can be updated manually when needed). >> The PHP list uses the MediaWiki API to get all the languages, it then changes it from [0] => array( 'en' => 'English'); to ['en'] => 'English' (more compact and allows to easily do a check like if( typeof mylist[code] == 'string' ). If it is in a numerical array with objects it requires a loop.. ). The output of this php-file can simply be copied hardcoded into, say, wpAvailableLanguages so that other scripts can use it as well and be updated whenever needed (almost never) The script will then end up as a Wiki-hosted single-file script. The JS was on Toolserver so I could very easily edit the page in my FTP Editor and edit, save, refresh etc. I'll move it on-wiki tonight as basic stuff is done now. > return language = language.replace(/(-.*)+/, '').toLowerCase();// > convert 'AA-BB' to 'aa' etc. > > Should check if the lang key already exists ie 'zh-classical' at least > in firefox we get en-US so i look for lower case keys in > "getBrowserLang" I don't know if it works the same in other browsers. Thanks, I forgot for a second that there are in fact valid, dashed, language codes as well. I'll put a check in between to see if the raw output from the browser is a code of an available language. > Also you can test anonymous usage withJS param: > http://commons.wikimedia.org/wiki/Main_Page?withJS=MediaWiki:AnonymousI18N.js Well, yes the script can be loaded with withJS, but it doesn't stay when navigating to other pages which is the main purpose of the script. But if one just wants to see how it basically looks, sure the withJS is great for that. > I imagine you saw the recent persistantUseLang that got turned on that > does some similar stuff: > http://commons.wikimedia.org/wiki/Commons:Village_pump#Localization_for_anonymous_users I'm afraid I missed this one, I'll check it out right away. My first impression is that it's very exact and elaborate on referals but a few points though * It should be watching out for a hash-tag (ie. #some-header? uselang=fr doesn't get the user anywhere) * instead of looping through ALL anchor-tags on the page, just listen for a click on any a-tag and then perform the is-wiki-domain-check. By doing it live() one also catches clicks on dynamically added links such as the GlobalUsage-action by MediaWiki:Extra-tabs.js. * And usage of global wgVariables to avoid the script being/becoming wiki-dependant. I think these scripts can go great together. A hook in AnonymousI18N could be added to suggest an alternative language (ie. the referal language code) (overriding the browser- language check, but not overriding the cookie-setting). -- Krinkle > > On 12/07/2010 05:06 AM, Krinkle wrote: >> Hi all, >> >> Over the past weekend I've been looking at a decent solution for the >> localization towards our anonymous users. >> Currently there are two solutions being used. >> * Template:mld >> :: This template renders all translations, and by means of >> javascript >> only shows the desired choosen translation >> * ?uselang >> :: Albeit used only a little but it is linked on several Main- >> pages[1] >> to show the interface in the correct language >> >> The problem with Template:Mld is that it's use is limited, it can't >> be >> used in all ocasions (ie. it would be hard to use for License- >> templates or for [[Template:Information]]). Also due to ineffeciency >> (bandwidth wise, it sends everything). >> >> And not to forget that things localized in Message
[Commons-l] Anonymous I18N
Hi all,
Over the past weekend I've been looking at a decent solution for the
localization towards our anonymous users.
Currently there are two solutions being used.
* Template:mld
:: This template renders all translations, and by means of javascript
only shows the desired choosen translation
* ?uselang
:: Albeit used only a little but it is linked on several Main-pages[1]
to show the interface in the correct language
The problem with Template:Mld is that it's use is limited, it can't be
used in all ocasions (ie. it would be hard to use for License-
templates or for [[Template:Information]]). Also due to ineffeciency
(bandwidth wise, it sends everything).
And not to forget that things localized in Messages (ie. translatewiki
or MediaWiki-namespace) can't be fetched via javascript inside the
page when the wikitext only shows {{int:Message}}.
And lastly, lots of things are localized with {{LangSwitch}}, which is
very smart (because of fallbacks etc.) and effecient (only sends the
needed translation to the browser) but is currently only usable for
registered users.
Which means that anonymous users get talkpage messages in English and
see the overal interface in English.
For that reason I've combined bits and pieces of other scripts and re-
wrote things and came up with the AnonymousI18N-script.
You can check it out by adding the following to your vector.js[2]
importScriptURI( 'MediaWiki:AnonymousI18N.js' );
Keep in mind that this is ofcourse not meant for registered users, in
the final version an if()-statement will prevent it from being loaded
if the user is logged in, but during development this will work only
for logged in users.
The script itself uses the toolserver to fetch a list of available
languages and other data (as soon as development is fairly done I will
move the script fully on-wiki - as it would not be handy (and not
required) to require a toolserver-request on all pageloads for
anonymous users, this is purely temporarily hosted on the Toolserver
for now. The list of available languages doesn't change often anyway
and can be updated manually when needed).
Once the script is loaded it checks if a cookie has been set and as
fallback (default for most new users) it checks the browser language.
If the language is not set already to this language and it is
available in MediaWiki it puts up a (declinable) localized notice[3]
on top asking the user to "View Wikimedia Commons in (language)".
Clicking that will set a cookie and redirect the user to the current
page with ?uselang set to that language.
The page also shows a dropdown menu in the Sidebar for hand-picking a
language of choise. This can be used if the suggestion is wrong, or if
the user declined the notice and wishes to pick a language later.
When a language other than the default ('en') is choosen, clicking any
link linking to the same or another wikimedia-wiki will get the
uselang= query string attached.
The script makes the language setting globally available as
wgAnonUserLanguage. Other scripts would in the future use this
variable whenever something language dependant os needed (for example
in the MLD-javascript) to avoid having to write cookie-things up again
and again for each script.
Please let me know what you think and if there are any issues.
So far it's been tested in Safari 5 and Firefox 3.6 (Mac). Testing on
Windows and (older versions of) Internet Explorer is grealty
appreciated.
PS: Since it is built for anonymous users it will only work in the
Vector-skin.
--
Krinkle
[1] Example: http://commons.wikimedia.org/wiki/Hoofdpagina
the link "Herlaad deze pagina met Nederlandstalige menupagina's"
[2] http://commons.wikimedia.org/wiki/Special:Mypage/vector.js
[3] A screenshot of what it looks like:
http://meta.wikimedia.org/wiki/User:Krinkle/Scripts/AnonymousI18N
--
Greetings,
Krinkle
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Use labels in Commons and increase coverage
Op 29 okt 2010, om 19:35 heeft David Gerard het volgende geschreven: On 29 October 2010 17:55, Krinkle wrote: One could search for a tag, and another and another narrowing down your search. I can't imagine how many times I was looking for something simple and being forced to make a specific choise in order to see a picture. Indeed. Remember that the audience for this is not people interested in ontological structure - they already have the category tree. It's for the casual user to type in a few words they're thinking of. Think something like Getty Images. "Commons is sorta like Getty Images except it's all free and the search sucks." I'll be starting developing this extension on my server this weekend. Just as a basic functioning proof-of-concept to see if there's any major problems I run into. As soon as it's something to look at I'll post and link and see if I can get it in SVN. Please note that the toolserver link posted earlier is just a static HTML page. It is not a MediaWiki install. -- Krinkle___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Use labels in Commons and increase coverage
Op 29 okt 2010, om 18:34 heeft Maarten Dammers het volgende geschreven: > Imho the most important > problem of our current system is intersections. Category:Churches gets > too crowded so we intersect it with locations (I even wrote a bot to > do > that). This "hides" a lot of images. We want to add atomic things, > let's > call them labels. So I want to add the label "church" and the label > "Amsterdam" and have some clever software figure out the intersection. Actually, if tags dont get a hierarchy of themselfs intersecting is one of the features I was planning to build in the Extension (or build in an existing extension if it exists). One could search for a tag, and another and another narrowing down your search. I can't imagine how many times I was looking for something simple and being forced to make a specific choise in order to see a picture. [[Categorie:German scientists who won a nobel price]] Such a category could potentially exist on Wikipedia or Commons. Instead such a photo could be categorised in: [[Category:Scienco Foobar meeting 2009]] Tag: Scientist, nobel price winner, german Now for that reason I don't think replacing categories all together is a good thing. Think of categories as sets, pictures that belong together beyond visual similarity. I mean a tag like "Wikimania 2009" would too specific imho. That's ideal as a gallery and/or category. But how about a category: "Groupphotos taken during Wikimania 2009" ? Too specific. But categorizing images of the event in "Wikimania 2009" and tagging some photos with 'groupphoto' . That would be nice. ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Extension:Tags-idea (was: Active projects on Commons)
Op 29 okt 2010, om 15:29 heeft Magnus Manske het volgende geschreven: > On Fri, Oct 29, 2010 at 2:21 PM, Gerard Meijssen > wrote: >> Hoi, >> Typically I am happy with hacks but this is an exception. The >> terminology >> used in the categories are not optimal. The use of plural, the use >> of latin >> names for organisms.. It is better for people to add new tags because >> otherwise they think "it has to be like that". > > Not sure I understand. My hack is using the category /system/, not the > existing categories. Each tag is a special new category like > [[Category:TAG:Flower]]. > > It's not pretty, and a dedicated extension like Krinkle's is much > better, but it works right now, and has the pleasant side effect that > it can be queried for both tags and categories simultaneously, if > desired (e.g. tag X in category tree Y). > A very basic UI concept: http://toolserver.org/~krinkle/MWTags/ (not functional) ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Active projects on Commons
Op 29 okt 2010, om 15:13 heeft Magnus Manske het volgende geschreven: > On Fri, Oct 29, 2010 at 2:09 PM, Krinkle > wrote: >> So [[Tag:Blume]] would never appear in wiki-text. Instead >> [[Tag:Flower]] or [[Tag:100]] (depending >> on the sytem we decide to use). And in sidebar (and whereever else >> tag_i18n is consulted) the currect language >> appears. > > [[Tag:Flower]] would have the advantage of being human-readable, for > the English-speaking world at least. A dozen [[Tag:100]] things would > be ... off-putting to many, IMHO. We could just (in)formally agree > that the main tag name should always be English. > > Magnus It does bring the issue of renaming. Although Tags are (hopefully) less common to be renamed then categories or pages. It could happen (*) in which case numbers is easier. *On the subject, perhaps we don't want that at all. Move could be hidden / disabled on Tag:-pages. It does make sense as, well, they are tags. If you rename it it's a different tag. -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Active projects on Commons
Op 29 okt 2010, om 15:10 heeft Magnus Manske het volgende geschreven:
> On Fri, Oct 29, 2010 at 2:03 PM, Krinkle
> wrote:
>> Op 29 okt 2010, om 14:51 heeft Magnus Manske het volgende geschreven:
>>
>>> Multilanguage tags, as well as synonyms, could simply be implemented
>>> as #REDIRECTs, maybe. [[Tag:Blume]] would redirect to
>>> [[Tag:Flower]],
>>> so a search for "Blume" would know about "Flower" easily. However,
>>> the
>>> system would then have to search for both Blume and Flower
>>> internally.
>>> Also, that could be a problem with "false friends" (en:Gift=present
>>> vs. de:Gift=poison).
>>
>> Though that's certainly not a bad option. I was thinking not to use
>> page-title search
>> when searching through tags. Instead the tag-table itself which
>> contains all the i18n
>> versions. An option on the tag-search page could specify whether the
>> search should
>> cover English( and/or user-language), or all languages.
>>
>> Reason being that using redirects would practically mean we are
>> supposed to keep
>> all redirects in-sync with the tag-translations, which seems double
>> work.
>
> A separate database table derived from the wikitext on [[Tag:Flower]]
> would certainly work as well.
>
> Another idea: Instead of inventing new syntax or pseudo-HTML tags, why
> not use language links? On [[Tag:Flower]]
> [[en:Flower]]
> [[de:Blume]]
>
> That is well-known syntax, and could be nicely parsed for some other
> applications (On [[de:Blume]] "Search for images on commons relating
> to Blume" generated automatically, or something)
>
> However, it would preclude synonyms within the same language, as there
> is only one language:title pair stored AFAIK.
>
> Magnus
Sure, that works too (I was aiming at the #tag syntax, which I believe
is also
fairly easy parsed).
Whether [[xx:Words here]] or {{#en:Words here}}.
The former might confuse the few users that check the Diff (instead of
editing the page
with the form) as I asume the Tag:-page would not actually have
langlinks.
--
Krinkle
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Active projects on Commons
Op 29 okt 2010, om 15:01 heeft Bryan Tong Minh het volgende geschreven: > On Fri, Oct 29, 2010 at 2:51 PM, Magnus Manske > wrote: >> Multilanguage tags, as well as synonyms, could simply be implemented >> as #REDIRECTs, maybe. [[Tag:Blume]] would redirect to [[Tag:Flower]], >> so a search for "Blume" would know about "Flower" easily. However, >> the >> system would then have to search for both Blume and Flower >> internally. >> Also, that could be a problem with "false friends" (en:Gift=present >> vs. de:Gift=poison). >> > Or force the user to select a language when entering the tag. This > means though that we either need a pre-save transform to transform > [[Tag:en/flower]] and [[Tag:de/Blume]] to their canonical > [[Tag:flower]] and reject tags without language specified, or we need > to have tags entered separately from the page text. But then run into > the history problem again. Ah, now I remember again. The reason I used "100" as example in the first mail was to basically avoid this problem. Since they will be primarily changed from the sidebar (or wherever they will appear), where the i18n applies, the page-text doesn't matter that much. In a diff-view they could be rendered aswell in the sidebar so that there isn't the issue of: " I'm in a diff-view and wonder what this means " (just like categories, page-title and wikitext is rendered below diff- view aswell) So [[Tag:Blume]] would never appear in wiki-text. Instead [[Tag:Flower]] or [[Tag:100]] (depending on the sytem we decide to use). And in sidebar (and whereever else tag_i18n is consulted) the currect language appears. - Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Active projects on Commons
Op 29 okt 2010, om 14:51 heeft Magnus Manske het volgende geschreven: > On Fri, Oct 29, 2010 at 1:36 PM, Bryan Tong Minh > wrote: >> On Fri, Oct 29, 2010 at 2:25 PM, Krinkle >> wrote: >>> For one, tags would not be hierarchical and not stored under a name, >>> rather a number (an id if you will). >> >> I would store the tag-i18n definitions in a separate Tag: namespace. >> Then you don't need to create the history tracking etc. all by >> yourself. You will need a unique identifier though, but I don't see a >> problem making the unique identifier equal to the content language. > > As to "tracking", IMHO it would suffice to just add [[Tag:XYZ]] to the > pages; that's rather inelegant from a database POV, but as Bryan > points out, it would take care of version tracking etc. All one would > need to do is to remove them from the rendering and display them > separately, like categories. @Bryan: Ah, excuse me. You were referring to the history of the File- page. I was under the impression it was about the version tracking of the Tags. Yeah, adding to the page would be similar to categories and extracted from wikitext to a taglinks table. > Multilanguage tags, as well as synonyms, could simply be implemented > as #REDIRECTs, maybe. [[Tag:Blume]] would redirect to [[Tag:Flower]], > so a search for "Blume" would know about "Flower" easily. However, the > system would then have to search for both Blume and Flower internally. > Also, that could be a problem with "false friends" (en:Gift=present > vs. de:Gift=poison). Though that's certainly not a bad option. I was thinking not to use page-title search when searching through tags. Instead the tag-table itself which contains all the i18n versions. An option on the tag-search page could specify whether the search should cover English( and/or user-language), or all languages. Reason being that using redirects would practically mean we are supposed to keep all redirects in-sync with the tag-translations, which seems double work. -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Active projects on Commons
Op 29 okt 2010, om 14:36 heeft Bryan Tong Minh het volgende geschreven:
> On Fri, Oct 29, 2010 at 2:25 PM, Krinkle
> wrote:
>> For one, tags would not be hierarchical and not stored under a name,
>> rather a number (an id if you will).
>
> I would store the tag-i18n definitions in a separate Tag: namespace.
> Then you don't need to create the history tracking etc. all by
> yourself. You will need a unique identifier though, but I don't see a
> problem making the unique identifier equal to the content language.
>
>
> Bryan
>
Now that I re-read my mesage I see I didn't use the word Namespace
litterly but that's what I meant, yes.
A seperate Tag: namespace that contains 'pages' that are either titled
by numbers or by a name in the main content language.
(in contrary to the interwiki-transclusion thing the title of the Tag-
pages are pretty much hidden from everybody)
I just read another discussion about seperating license/author
information from page-text.
This brought me on another idea.
If Tags are stored seperatedly, there's no need to have any 'wiki-
text' at all.
Atleast not visible to the end user.
A tag:-page could simply contain a form with the current translations
(editable)
and a [+]-button to add a translation.
roughly shaped:
Pagename: [[Tag:Flower]]
English flower
Nederlands boem >
Deutsch Blume
...languages not translated yet ...
Saving would extract the info and store it in the tag_i18n table (or
page_props if that's more appropiate - anyway)
Since we like keeping history of everything it may be wise to also
store this as wikitext for the Tag:Flower page as something like:
{{en:flower}}
{{nl:bloem}}
{{de:Blume}}
but that would only be visible in diff-views and history.
--
Krinkle
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Active projects on Commons
Op 29 okt 2010, om 10:13 heeft Magnus Manske het volgende geschreven:
> On Fri, Oct 29, 2010 at 8:32 AM, David Gerard
> wrote:
>> On 29 October 2010 02:11, Neil Kandalgaonkar
>> wrote:
>>
>>> The debate I see on Commons and elsewhere focuses on trying to fix
>>> Categories, but frankly IMO it would be better to migrate them to
>>> some
>>> other systems entirely.
>>
>>
>> :Let me precis several years' wishlisting on the topic:
>>
>> * Tagging would be vastly helpful.
>> * Tags would need to be able to be queried with possibly quite
>> complex
>> Boolean queries.
>> * Categories as tags would make a transition feasible from the
>> content side.
>
> Done:
> http://commons.wikimedia.org/w/index.php?title=File:Vernomia_altissima_(Compositae)_flower.JPG&withJS=MediaWiki:Tag.js
>
> Works with categories prefixed with "TAG:".
> Check "flower" and "pink", click on "subset". This leads to the
> toolserver, and there's only one result, but that could be
> "prettyfied" (dialog on Commons, previews, etc.)
> Click on the "+" to add a tag without reloading the page, and on the
> "x" after the tag to remove it, also without reloading. Everything's
> still a "normal" edit, so the usual revert options apply.
>
> Note that it's still experimental, and showing twice for me for some
> strange reason when I'm logged in, but so what...
>
> Cheers,
> Magnus
I've seen the tagging suggestion come by a lot of times and always
found it a great idea.
The importance is though, in my opinion, that it should not use the
category system (not even temporarily). I asumt it was done now as a
proof-of-concept.
I think an extension could be written for MediaWiki (if not existing
already I might be able to do it myself) that will add tags to
MediaWiki, similar to categories but with a few differences.
For one, tags would not be hierarchical and not stored under a name,
rather a number (an id if you will).
In there a syntax would be a syntax representing the tagname in
different langauges.
Example (dont pay attention to the exact syntax, it's just an idea)
# Tag:100
{{en:flower}}
{{nl:bloem}}
{{de:Blume}}
It would generally be saved as a page with wikitext and a history etc.
When saving the tagname translations could either be saved to
page_props or to a newly created tag_i18n table containing tag_id,
tag_lang and tag_name
When on a file page there'd be a sidebar gadget listing the current
tags. (WHERE tag_from=pageid, just like categories)
And instead of fetching the pagetitle from the page table entry it
would either fetch it from page_props or from tag_i18n with fallback
to English.
When adding tags autosuggest would be used like the Search-function
has. Searching through the different tagnames where tag_lang is 'en'
or where tag_lang is the user's language.
Just an idea, let me know what you think
--
Krinkle
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Fwd: Commons ZIP file upload for admins
On 26 oct 2010, at 01:04 (UTC +02:00) Howard Cheng wrote: > Personally, I'd rather we allow file uploads via URL for admins. > Downloading and uploading is always such a pain when you have slow > connection. > Allowing URL uploads isn't an alternative for the proposal we're discussing. I don't see the link ? -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Nice icons...
Op 7 okt 2010, om 21:34 heeft Andrew Gray het volgende geschreven: > On 7 October 2010 14:23, Krinkle wrote: > >> Main reason being that, although the buttons are highly useful (and I >> can't imagine any big usercase in which they would be unwanted), >> so aside from that they are also in a very visible area that lots >> of scripts, tools and applications do or could potentially use to >> print their buttons and all sorts of triggers aswell. >> In order to not further complicate that area (eg. "Oh I can't program >> it here because some of the users of this particular script puts the >> buttons there also.."); > > Now you mention it, I'm really surprised I haven't seen anything else > using that big white-space area. But it seems a bit odd to keep it > empty just in case someone else wants to use it, especially when > making these prominent is so useful. > > A useful solution might be to implement an option to have the "normal" > sharing buttons display below the images, and then anyone writing a > script which wants to use the right-hand side can include the trigger > for that function - move them out of the way in order to add in your > new exciting rotation tool or what have you, but not affect them the > rest of the time. As long as that second tool is itself an opt-in > option, this wouldn't conflict too much... > > -- > - Andrew Gray > andrew.g...@dunelm.org.uk > Just in case we misunderstood eachother, I didn't mean that it's a problem that the icons are as big as they are now at the position they are now (large and in a vertical row next to the image) However, I'm just saying that it's good to keep it that way (atleast not providing an option like: StockPhoto.position.options = ["top left", "bottom right", "upside down here", "funky cool there", "small icons in the corner", "big icons in the footer"]; I totally agree that it is odd to keep the space empty just becuase someone could use it. We are the ones using it now, so that's fine. But just keep it consistant way :-) -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Nice icons...
As for the inconsistency in the icons (eg. not the same 'style'). I'll see if I can find alternatives all from one set tomorrow (or anyone else feel free to propose or edit yourself): eg. pick one of the below: * http://commons.wikimedia.org/wiki/Category:Tango_project * http://commons.wikimedia.org/wiki/Category:GNOME_Desktop_icons * http://commons.wikimedia.org/wiki/Category:Nuvola_icons -- Krinkle Op 7 okt 2010, om 20:39 heeft Paul Houle het volgende geschreven: > On 10/6/2010 9:55 PM, Neil Kandalgaonkar wrote: >> Yeah, that had its uses, so why was that removed? Deemed annoying? >> >> I've tried to research what's the best way to do "share this" buttons >> and there isn't any clear data or consensus on this. Collapsing the >> various share icons into one popup is probably the most extensible / >> least annoying. >> > Well, I do think the large buttons on the left looked more like > "wikispaces" than "wikipedia" (more commercial) but I thought they > looked great. It might be nice to see more of that style in other > places. > > As for social sharing, that's more complicated. I know of a site > (that you've probably never heard of) that was lucky enough to get on > the list of social media share buttons that came with a popular > wordpress plugin, and they got a number of backlinks that was > absolutely staggering -- and then they got hacked by some S.E.O. > spammers who turned it into their own private playground. The site > was > ranking well for many search terms and presumably getting quite a > bit of > traffic and also boosting the rankings of the spammers' sites, but it > got zapped when somebody uploaded malware to the site. The site > owners > were basically absentee landlords and if there were any honest people > contributing to the site they didn't do anything about it. > > Today any idiot can install Pligg and have a Digg clone running in > a few hours, and I'm sure there's something out there for making a > delicious clone too. So if you make a list, you're in this awful > position of picking winners and losers. You could make a case that > Facebook is so big that it's sufficient to have a Facebook button -- > but > there's people out there who really hate Facebook. Now you might say > "Facebook", "Twitter", "Digg", "Reddit", "StumbleUpon", "Delicious". > Well, some people hate Digg so much that they'll still complain... > There probably are thousands or tens of thousands of 'sharing' sites > out > there, and you can't draw a clear line between ones that are "big > enough", the ones that are somebody's web-spam project (it isn't hard > to make a flock of electric sheep that can beat the average Digger at > the Turing Test), and ones that are just too little to matter... Not > without offending somebody, and in a consensus-driven organization, > that's a problem. > > There's also the question of what value sharing buttons bring. > For > something to get traction in social media, it's got to be not just > cool, but ~really~ cool, and what plays depends entirely on the > community. For instance, I've got a certain content stream that > consistently gets 5-10 votes in reddit and brings in maybe 500-5000 > visitors. I submit the same stuff to Digg or Mixx and I might get 5 > or > 15 visitors. Part of that is that I've got a good account in reddit, > but some content just does well in some communities and doesn't in > others. > > For a project I'm working on, I'm seriously thinking about a > "Facebook-only" approach. I know that would drive some people nuts, > but I own the site lock, stock and barrel and I can do what I want. > Not everybody has that freedom. > > > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Nice icons...
Op 7 okt 2010, om 10:05 heeft Magnus Manske het volgende geschreven: > On Thu, Oct 7, 2010 at 8:52 AM, Liam Wyatt > wrote: >> >> On 7 October 2010 01:55, Neil Kandalgaonkar >> wrote: >>> >>> On 10/6/10 4:44 PM, Krinkle wrote: >>>> The clear icons to the right were better in my opinion without >>>> being >>>> disturbing or overwhelming. >>>> What is the motivation / reason for the change ? >>>> Taking in account that the UsabilityInitiative had a similar >>>> design; >>>> like the one you had for a few days (the larger icons to the >>>> right). >>> >>> Yeah, I liked it much better with the icons on the right as well. >>> >>> Promoting reuse is one of the primary functions of Wikimedia >>> Commons, so >>> we ought to make it as easy and visible as possible. >>> >>> >>>> Op 6 okt 2010, om 22:24 heeft Magnus Manske het volgende >>>> geschreven: >>>>> Also, I had added a bunch of social network "share this" icons, >>>>> but >>>>> Geni removed them. Ah well. >>> >>> Yeah, that had its uses, so why was that removed? Deemed annoying? >>> >>> I've tried to research what's the best way to do "share this" >>> buttons >>> and there isn't any clear data or consensus on this. Collapsing the >>> various share icons into one popup is probably the most extensible / >>> least annoying. >>> >>> >>> -- >>> Neil Kandalgaonkar >>> >> For what it's worth, Several staff of the people where I'm >> currently working >> had noticed the reuse buttons when they were on the right and >> remarked on >> them to me as really cool. These were going to be used as an >> example in a >> meeting about how their own interface could look but when the >> buttons moved >> neither they nor I could find the buttons any more. I only noticed >> the >> buttons again when I read this thread. >> >> Summary - those buttons placed on the right hand side of the image >> were >> noticed by "non-wikipedians" and seen as a good idea. When they >> moved it was >> assumed that they were gone, not merely moved. As for the "share" >> buttons - >> precisely why were they removed? Are we anti-social networks (or >> their logos >> on our pages), or is it because they were too big or something? FWIW >> WikiNews has been using these kinds of buttons for a long time in >> articles. > > By popular demand here :-) I have re-enabled the larger top/side > icons. It is easy to switch back and forth between them. Maybe a user > option? Or would that be overkill? > > I left the "share" buttons turned off; see the discussion here: > http://commons.wikimedia.org/wiki/MediaWiki_talk:Stockphoto.js#Social_networking_icons > > Cheers, > Magnus We all love options and personal perferences. But I think it would be wise to keep this one as simple and equal as possible. Main reason being that, although the buttons are highly useful (and I can't imagine any big usercase in which they would be unwanted), so aside from that they are also in a very visible area that lots of scripts, tools and applications do or could potentially use to print their buttons and all sorts of triggers aswell. In order to not further complicate that area (eg. "Oh I can't program it here because some of the users of this particular script puts the buttons there also.."); So for that reason I would recommand not making options in terms of size or location of the buttons. Anything else that might be wished (text / no text, language, image-sets etc.) wouldn't be an issue though Once again I want to say how much I like these buttons. its so... plain simple and obvious need. Thanks Magnus :-) -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Nice icons...
Op 6 okt 2010, om 22:24 heeft Magnus Manske het volgende geschreven: > On Wed, Oct 6, 2010 at 9:04 PM, Paul Houle wrote: >> I was just browsing wikimedia.org and saw some new icons on the side >> of the image on: >> >> http://commons.wikimedia.org/wiki/File:Marmolejo_summit_cone_on_the_edge_of_collapsed_caldera_close_up_chile_rm.jpg >> >> These say "Download", "Use this file", etc... They look really >> nice >> and I think they're a usability win. > > Thank you! I've moved the icons (and made them smaller) to the bottom > of the image, after some complaints; force-reload your browser to see > the new layout. > > Also, I had added a bunch of social network "share this" icons, but > Geni removed them. Ah well. > > Cheers, > Magnus The clear icons to the right were better in my opinion without being disturbing or overwhelming. What is the motivation / reason for the change ? Taking in account that the UsabilityInitiative had a similar design; like the one you had for a few days (the larger icons to the right). -- Krinkle ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Problems using pictures from Commons in Blogger - making it more of a stock photo repository
Or both :-) Op 29 sep 2010, om 01:07 heeft Andrew Gray het volgende geschreven: > On 28 September 2010 22:10, Magnus Manske > wrote: > >> http://commons.wikimedia.org/wiki/File:Inachis_io_qtl4.jpg?withJS=MediaWiki:Stockphoto.js >> >> Sincerely, >> One Of The Few (TM) > > Magnus, you are if anything the All. It's marvellous! :-) > > I suppose the way to go from here would be to figure out where best to > put it - underneath, with the full resolution link, or in the bar > across the top above the image? > > -- > - Andrew Gray > andrew.g...@dunelm.org.uk > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] "Session data" bug
It happends to me too every once in a while. Using Safari 5 on Mac OS X as primary browser but I see it on other browsers and operating systems aswell. So far people in #wikimedia-tech could only blame mini magical events that happen to intervene somewhere between us and the server, and the general load on the server (only happeneds to me around internet prime time - could be a coincidence though) - Krinkle Op 13 sep 2010, om 23:40 heeft Hay (Husky) het volgende geschreven: > Hi, > i got this error uploading a file to Commons: > > "Sorry! We could not process your edit due to a loss of session data. > Please try again. If it still does not work, try logging out and > logging back in." > > It seems to happen pretty irregularly. I'm using Chrome 6 / Mac OS X. > Is this a known bug? > > Regards, > -- Hay > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Wiki(p|m)edia page display on iPad
Not finished yet, but here is what I got so far: http://commons.wikimedia.org/wiki/Main_Page?withJS=MediaWiki:IPadSidbarSlider.js -- Greetings, Krinkle Op 15 jun 2010, om 19:13 heeft Magnus Manske het volgende geschreven: > On Tue, Jun 15, 2010 at 5:37 PM, Cary Bass wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 06/15/2010 02:30 AM, Magnus Manske wrote: >>> Hi all, >>> >>> since there's already several million iPad (and soon, other >>> tablet) users out there, I thought I'd try one in the Apple store >>> to see what Wikipedia looks/feels like. Generally, I think it's >>> very nice, with one exception. In "portrait" mode, the sidebar >>> takes up a lot of real estate. Especially when you scroll down a >>> long page, there's this annoying white bar on the left that serves >>> no real purpose. Also, IMHO, it destroys that "book feeling" that >>> would fit so well with the iPad. >>> >>> So I wrote a quick JS hack that /should/ hide the sidebar on the >>> iPad. Instead, it shows an icon in the top left corner that, when >>> "finger-clicked", will show the sidebar again, in case you really >>> want it. >>> >>> Demo (on Commons, because of the "withJS" option there): >>> http://commons.wikimedia.org/wiki/Main_Page?withJS=MediaWiki:Adjust4iPad.js >>> >>> >>> >> Now, that should /only/ work on the iPad. Could someone please >> confirm >>> this and tell me if it's an improvement. On image pages it >>> probably doesn't matter a lot, but more text-laden pages like >>> http://commons.wikimedia.org/wiki/Commons:Welcome?withJS=MediaWiki:Adjust4iPad.js >>> >>> >> http://commons.wikimedia.org/wiki/Commons:Reusing_content_outside_Wikimedia?withJS=MediaWiki:Adjust4iPad.js >>> it should make a visible difference. >>> >>> If it is as good as I suspect, we could use it by default on the >>> Wikipedias etc. There's lots of room for improvement; maybe the >>> sidebar could appear when switching to landscape mode (as in the >>> mail app). The usability experts may want to take a look :-) >> According to my local iPad cultist enthusiast, it works. > > Thanks! Any feedback on whether it's better or not? > > Magnus > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Wiki(p|m)edia page display on iPad
I don't have an iPad but I did succeed to fake the User-Agent from the iPad and it worked fine. Tho it does have a few usabilty issues to deal with: - Clicking the logo doesn't make a lot of sense. - Perhaps a fixed-positioned half-round arrow-button about a third down the screen would make more sense - Both ways (being able to show it and hide it again). - If we're going to make work if this, perhaps a dropdown menu could work aswell (one that has a scrollbar, so that the user can stay at the current position in the page). I think the first three wouldn't be hard. The latter would require to digg up the JavaScript event HTML5 and/or Apple iOS for a drag-movement. I'll try some scripting of my own later this week -- Greetings, Krinkle Op 15 jun 2010, om 19:13 heeft Magnus Manske het volgende geschreven: > On Tue, Jun 15, 2010 at 5:37 PM, Cary Bass wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 06/15/2010 02:30 AM, Magnus Manske wrote: >>> Hi all, >>> >>> since there's already several million iPad (and soon, other >>> tablet) users out there, I thought I'd try one in the Apple store >>> to see what Wikipedia looks/feels like. Generally, I think it's >>> very nice, with one exception. In "portrait" mode, the sidebar >>> takes up a lot of real estate. Especially when you scroll down a >>> long page, there's this annoying white bar on the left that serves >>> no real purpose. Also, IMHO, it destroys that "book feeling" that >>> would fit so well with the iPad. >>> >>> So I wrote a quick JS hack that /should/ hide the sidebar on the >>> iPad. Instead, it shows an icon in the top left corner that, when >>> "finger-clicked", will show the sidebar again, in case you really >>> want it. >>> >>> Demo (on Commons, because of the "withJS" option there): >>> http://commons.wikimedia.org/wiki/Main_Page?withJS=MediaWiki:Adjust4iPad.js >>> >>> >>> >> Now, that should /only/ work on the iPad. Could someone please >> confirm >>> this and tell me if it's an improvement. On image pages it >>> probably doesn't matter a lot, but more text-laden pages like >>> http://commons.wikimedia.org/wiki/Commons:Welcome?withJS=MediaWiki:Adjust4iPad.js >>> >>> >> http://commons.wikimedia.org/wiki/Commons:Reusing_content_outside_Wikimedia?withJS=MediaWiki:Adjust4iPad.js >>> it should make a visible difference. >>> >>> If it is as good as I suspect, we could use it by default on the >>> Wikipedias etc. There's lots of room for improvement; maybe the >>> sidebar could appear when switching to landscape mode (as in the >>> mail app). The usability experts may want to take a look :-) >> According to my local iPad cultist enthusiast, it works. > > Thanks! Any feedback on whether it's better or not? > > Magnus > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] About the current Commons homepage
Great :-) So now we know what the status is. Thanks for your quick response. -- Greetings, Krinkle Op 7 jun 2010, om 22:06 heeft Daniel Schwen het volgende geschreven: >> When I get there in about 4 hours and it isn't been done yet, I'll >> put >> the slider up on the frontpage. >> (whether or not as a trial) > > Please don't. > It it not polished enough for the frontpage yet. > I appreciate a bold move, but the slider is not very pretty in its > current form and it has bugs which make it awkward looking in Firefox > (filenames instead of thumbs appearing). The title reads "Other > featured content", other than ''what''? It is at the top of the page > an looks out of place (not integrated into the page layout). The > varying thumbnail heights make the row of images look erratic. > Over all the slider is a neat idea, but it currently is not more > than a hack. > Best, > Daniel > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] About the current Commons homepage
I'm currently not at home. When I get there in about 4 hours and it isn't been done yet, I'll put the slider up on the frontpage. (whether or not as a trial) -- Greetings, Krinkle Op 7 jun 2010, om 19:11 heeft Neil Kandalgaonkar het volgende geschreven: > Does this need some kind of push? Fabulous prizes? > > Of those who had all those great ideas a couple of weeks ago, is there > anything standing in your way? > > > On 06/05/2010 10:49 AM, Gerard Meijssen wrote: >> Hoi, >> Please be bold, go where noone went before ... >> Thanks, >> GerardM >> >> On 5 June 2010 18:16, Gnangarra wrote: >> >>> what ever happened has this been left out in the weather or are we >>> just >>> waiting for someone to take bold step. >>> >>> >>> On 16 May 2010 23:04, Magnus Manske >>> wrote: >>> >>>> On Sun, May 16, 2010 at 4:02 PM, Magnus Manske >>>> wrote: >>>>> On Sun, May 16, 2010 at 2:40 AM, Gnangarra >>>>> wrote: >>>>>> Does the page need any of the banners on the main page, loosing >>>>>> these >>>> would >>>>>> bring all the information up the page. >>>>>> >>>>>> Could there be a Java sript box to cycle through a few images >>>>>> rather >>>> than >>>>>> just one. >>>>> >>>>> Hacked something: >>>>> >>>> http://commons.wikimedia.org/w/index.php?title=Main_Page&withJS=MediaWiki:Main_page_thumbnail_cycler.js >>>>> >>>>> Feel free to alter. >>>>> >>>>> Cheers, >>>>> Magnus >>>>> >>>> >>>> Sorry, should be: >>>> >>>> http://commons.wikimedia.org/wiki/Main_Page?withJS=MediaWiki:Main_page_thumbnail_cycler.js >>>> >>>> ___ >>>> Commons-l mailing list >>>> Commons-l@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/commons-l >>>> >>> >>> >>> >>> -- >>> GN. >>> Photo Gallery: http://gnangarra.redbubble.com >>> Gn. Blogg: http://gnangarra.wordpress.com >>> >>> ___ >>> Commons-l mailing list >>> Commons-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/commons-l >>> >>> >> >> >> >> ___ >> Commons-l mailing list >> Commons-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/commons-l > > > -- > Neil Kandalgaonkar ( > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Fwd: [WikiEN-l] Uploads patrol via a robot (Feedback requested)
See also this bugticket: https://bugzilla.wikimedia.org/show_bug.cgi?id=9501 Being able to [patrol] an upload like we can do with NewPages would make this a lot easier I think. Would enable showing only unpatrolled uploads by non-botbit accounts, and patrolling those (no double work). Op 2 jun 2010, om 14:34 heeft David Gerard het volgende geschreven: > Interesting thing. I commented on the relevant talk page, and it > occurred to me that Commons may have something to inform this idea - > are we still running about 10% of uploads being shoot-on-sight? Please > comment at the page :-) > > > - d. > > > -- Forwarded message -- > From: John Du Hart > Date: 1 June 2010 21:24 > Subject: [WikiEN-l] Uploads patrol via a robot (Feedback requested) > To: wikie...@lists.wikimedia.org > > > Hello Wikien-l, > > Right now I am working on a robot that will process recently > uploaded images > for problems, and respond to them. The amount of images that are being > uploaded and violating policy is currently (in my mind at least) > unacceptable. If we had a robot that could weed out obvious problem > images > it would benefit the project greatly. > > I would appreciate your feedback of its processes and methods at > http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Images_and_Media#User > :Image_Screening_Bot > > Thanks, > FinalRapture > ___ > WikiEN-l mailing list > wikie...@lists.wikimedia.org > To unsubscribe from this mailing list, visit: > https://lists.wikimedia.org/mailman/listinfo/wikien-l > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
[Commons-l] About MediaWiki:Main_page_thumbnail_cycler.js
Hi Magnus, I've checked it out with Web Inspector in Safari (ala Firebug in Firefox) and noticed it tries to load in (one or more times each loop) an "undefined" thing to url: http://commons.wikimedia.org/wiki/ undefined . This sometimes causes a questionmark-image to appear in the flow. Not sure what causes this. Tho I haven't read the script fully and extensively I noticed an additional API call is made to aquire the thumbnail paths. It could be that you need that API-call for some other information, if that's not the case you might be able to save that additional Ajax request by using something like this: http://commons.wikimedia.org/w/thumb.php?f=Example.jpg&w=100 -- Greetings, Krinkle Op 16 mei 2010, om 17:04 heeft Magnus Manske het volgende geschreven: > On Sun, May 16, 2010 at 4:02 PM, Magnus Manske > wrote: >> On Sun, May 16, 2010 at 2:40 AM, Gnangarra >> wrote: >>> Does the page need any of the banners on the main page, loosing >>> these would >>> bring all the information up the page. >>> >>> Could there be a Java sript box to cycle through a few images >>> rather than >>> just one. >> >> Hacked something: >> http://commons.wikimedia.org/w/index.php?title=Main_Page&withJS=MediaWiki:Main_page_thumbnail_cycler.js >> >> Feel free to alter. >> >> Cheers, >> Magnus >> > > Sorry, should be: > http://commons.wikimedia.org/wiki/Main_Page?withJS=MediaWiki:Main_page_thumbnail_cycler.js > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] About the current Commons homepage
Hi Hey, he withJS-param only allows from a MediaWiki-namespace (because of security reasons, think XSS) From our own userspace one can simply wrap a script within an if()- statement of (wgTitle == "Main Page") and the script will load when on the Main Page. NB: Magnus' script already has this ifstatement anyway because the script should (ofcourse) only load on the Main Page, so copying as-is should work). If you'd like to keep your vector.js (and it's history) clean, you could ofcourse also put it on another page (ie. Special:MyPage/ sandbox.js and importScript(User:You/sandbox.js); it like that in vector.js ) -- Greetings, Krinkle Op 17 mei 2010, om 00:54 heeft Hay (Husky) het volgende geschreven: > On Sun, May 16, 2010 at 5:04 PM, Magnus Manske > wrote: >>> Hacked something: >>> http://commons.wikimedia.org/w/index.php?title=Main_Page&withJS=MediaWiki:Main_page_thumbnail_cycler.js > Nice :) Although i guess maybe only one image instead of a few might > be a bit easier on the eye. Is there any way i could edit the > Javascript? I tried loading it from my personal userspace, but > apparently MediaWiki doesn't allow that (only from the Mediawiki: > space). > > I've put a wireframe rendering of the Commons brainstorm sketches on > the Usability wiki: > > http://usability.wikimedia.org/wiki/File:Commons_2010_wireframe_1.png > > Maybe we can take that as a starting point for further discussions on > the redesign. > > -- Hay > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Commons: An initial notice to reduce surprises
Something like that ("review before uploaded media is public") I
believe is already being taken into consideration by the Usability
Initiative.
However I don't quite see what that has to do with the subject ;-)
It's not about preventing data from getting onto Commons. The warning
is not an excuse like "Sorry, we haven't deleted all the bad stuff
yet, there's a lot coming in every day".
It would be a warning more like "Some of our content" -(which we will
keep)- " may not be suited for minors etc. etc. sex, shocking w/e" -
read the Village pump discussion.
--
Greetings,
Krinkle
Op 12 mei 2010, om 03:22 heeft Gnangarra het volgende geschreven:
Really all we need to do is impliment a review process for uploaded
media that way we address not only scope but copyright, derivative
wroks, FOP, permission and licensing issues before the image is
available for use, something like a flagged revisions. Providing it
has an auto review for approved contributors so as not to create
unmanagable back logs it should be a relatively fast process.
On 12 May 2010 03:04, Neil Kandalgaonkar wrote:
Note: replying to Commons-L as I am not on Foundation-L.
Hi -- I'm one of the WMF staff programmers working on Commons
Usability.
And by "one of", I mean "the". ;)
Reiterating arguments I made at the Village Pump, I'd like to note on
this list that in my professional opinion, this would be a step
backwards for usability.
http://commons.wikimedia.org/wiki/Commons:Village_pump#An_initial_notice_to_reduce_surprises
If you feel that the purpose of Commons is not obvious to visitors, I
suggest a tagline that appears at the top of every page.
http://www.useit.com/alertbox/20010722.html
My suggestion would be something like "A vast library of educational
images, movies, and sounds that anyone can use or contribute to."
--
Neil Kandalgaonkar (
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
--
GN.
Photo Gallery: http://gnangarra.redbubble.com
Gn. Blogg: http://gnangarra.wordpress.com
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Counter Vandalism Unit - Looking for helpers !
#cvn-commons reports file-uploads aswell, but only of new users, blacklisted users or watched filenames. Would be nicer if the blacklists were shared between the two. -- Greetings, Krinkle Op 8 apr 2010, om 18:56 heeft Platonides het volgende geschreven: > Krinkle wrote: >> Ah, indeed. I was wondering why it listed so few new files (the >> link I >> gave earlier). Uploads do indeed not get listed there. >> Special:NewFiles does but doesn't allow patrolling, I understand your >> request now. >> >> That project definitely needs attention aswell. >> I'll see if I can find a way to "patrollise" that. >> >> -- >> Greetings, >> Krinkle > > Note that file uploads are reported on irc at #commons-image-uploads > with whitelist/blacklist + some image consistency checks. > > Would be even nicer if gmaxwell fixed it so it reports deleted > reuploads > again, though. > > > ___ > Commons-l mailing list > Commons-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Re: [Commons-l] Counter Vandalism Unit - Looking for helpers !
Hi Eusebius,
Ah, indeed. I was wondering why it listed so few new files (the link I
gave earlier). Uploads do indeed not get listed there.
Special:NewFiles does but doesn't allow patrolling, I understand your
request now.
That project definitely needs attention aswell.
I'll see if I can find a way to "patrollise" that.
--
Greetings,
Krinkle
Op 8 apr 2010, om 17:08 heeft Eusebius het volgende geschreven:
Hi,
Thanks for your link.
Apparently, this only shows the page creations without upload, like
before a Flickr upload bot action. "Standard" uploads do not seem to
show.
Independently from this, even if a page could list all unpatrolled
uploads, I think it wouldn't be suitable, because (for the patrolled
edit be efficiently applied to recent uploads) a file upload should
be marked as patrolled/unpatrolled independently of the edits on the
file page. Indeed, recent edit patrollers will look for vandalism,
and recent uploads patrollers will look for copyright violations,
bad sources, missing permisions, etc. Depending on the experience
and "patrolling profile" of both kinds of patrollers, patrols can
have very different ("colliding") outcomes. This is why I suspect a
different notion could be justified for patrolled uploads.
Here's what we tried to begin about recent uploads, for info:
http://commons.wikimedia.org/wiki/Commons:Recent_uploads_patrol
Regards,
Eusebius
Krinkle a écrit :
Hi Eusebius,
There is actually something that is 99% like what you are describing:
http://commons.wikimedia.org/w/index.php?title=Special:NewPages&hidepatrolled=1&namespace=6
reversed:
http://commons.wikimedia.org/w/index.php?title=Special:NewPages&hidepatrolled=1&namespace=6&dir=prev
It's the NewPage-patrol, with the namespace filter set to "File",
which is pretty much always an upload.
(though theoraticly there could be uploads without a page, and a
page without an upload)
Please note that, like any patrollable action the action leaves the
unpatrolled queue automaticly after 720 hours (30 days).
if you like, I could create a checklist-system for this aswell.
--
Greetings,
Krinkle
Op 8 apr 2010, om 16:38 heeft Eusebius het volgende geschreven:
Hi,
Thanks for this initiative. On my side I've significantly failed
to build something for recent uploads patrolling.
Is there something like a patrolled upload on MediaWiki? Because
I've always found recent uploads more problematic than recent
edits, and being able to tell between patrolled and unpatrolled
uploads would be GREAT.
Regards,
Eusebius
Krinkle a écrit :
Hi everybody.
First of all, for those of you who haven't been here, or didn't
get the complete picture, here is a short summary of some recent
events:
* Last March, I started the Counter Vandalism Unit on Commons <http://commons.wikimedia.org/wiki/Commons:Counter_Vandalism_Unit
>
* Later that month, the edit-patrol function was enabled on
Commons <http://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2010Mar#Marking_edits_as_patrolled
>
* After a Sitenotice, a few users have signed up to be
"patrollers"; and with a small team of 3 to 4 regular patrollers,
we keep a checklist of anonymous edits. <http://commons.wikimedia.org/wiki/COM:ANO#Anonymous_edits
>
The Problem
Vandalism on Commons is a big problem, which generates a large
backlog. Commons is the primary media depository for most media
used throughout Wikimedia. Vandalism on Commons therefore has a
greater likelihood of affecting local projects.
And, this also brings along the source of vandalism: Vandals.
Local vandals are only a click away from Commons. Some don't even
realise they are no longer on the local wiki.
Some, whether or not knowing they've been blocked on a local
project, continue vandalising on Commons.
So, having that said, we are looking for help !
The most important areas, for now, are live watches on IRC or
recent changes, and the Checklists mentioned above.
Live watch
For a long time Commons has it's own cvn-channel on Freenode:
#cvn-commons .
Although there are about a dozen idling users and a bot at any
one time, use of the channel for vandal-fighting is not as
frequent as desired.
Watching live is probably the easiest and most effective way to
fight vandalism.
Also, for those who don't have the time to patrol an entire
daypart-checklist, this is a great way to contribute when they
only have a spare few minutes. One can leave and join at any
time, and click/patrol for all edits that are reported in the
channel.
In comparison to the checklists, the CVN-channel has a couple of
advantages. JelteBot (the recent-changes bot in #cvn-commons)
emphasises edits based on blacklists and watchlists, making it
easier to detect potential vandalism. (I
Re: [Commons-l] Counter Vandalism Unit - Looking for helpers !
Hi Eusebius, There is actually something that is 99% like what you are describing: http://commons.wikimedia.org/w/index.php?title=Special:NewPages&hidepatrolled=1&namespace=6 reversed: http://commons.wikimedia.org/w/index.php?title=Special:NewPages&hidepatrolled=1&namespace=6&dir=prev It's the NewPage-patrol, with the namespace filter set to "File", which is pretty much always an upload. (though theoraticly there could be uploads without a page, and a page without an upload) Please note that, like any patrollable action the action leaves the unpatrolled queue automaticly after 720 hours (30 days). if you like, I could create a checklist-system for this aswell. -- Greetings, Krinkle Op 8 apr 2010, om 16:38 heeft Eusebius het volgende geschreven: Hi, Thanks for this initiative. On my side I've significantly failed to build something for recent uploads patrolling. Is there something like a patrolled upload on MediaWiki? Because I've always found recent uploads more problematic than recent edits, and being able to tell between patrolled and unpatrolled uploads would be GREAT. Regards, Eusebius Krinkle a écrit : Hi everybody. First of all, for those of you who haven't been here, or didn't get the complete picture, here is a short summary of some recent events: * Last March, I started the Counter Vandalism Unit on Commons <http://commons.wikimedia.org/wiki/Commons:Counter_Vandalism_Unit > * Later that month, the edit-patrol function was enabled on Commons <http://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2010Mar#Marking_edits_as_patrolled > * After a Sitenotice, a few users have signed up to be "patrollers"; and with a small team of 3 to 4 regular patrollers, we keep a checklist of anonymous edits. <http://commons.wikimedia.org/wiki/COM:ANO#Anonymous_edits > The Problem Vandalism on Commons is a big problem, which generates a large backlog. Commons is the primary media depository for most media used throughout Wikimedia. Vandalism on Commons therefore has a greater likelihood of affecting local projects. And, this also brings along the source of vandalism: Vandals. Local vandals are only a click away from Commons. Some don't even realise they are no longer on the local wiki. Some, whether or not knowing they've been blocked on a local project, continue vandalising on Commons. So, having that said, we are looking for help ! The most important areas, for now, are live watches on IRC or recent changes, and the Checklists mentioned above. Live watch For a long time Commons has it's own cvn-channel on Freenode: #cvn- commons . Although there are about a dozen idling users and a bot at any one time, use of the channel for vandal-fighting is not as frequent as desired. Watching live is probably the easiest and most effective way to fight vandalism. Also, for those who don't have the time to patrol an entire daypart- checklist, this is a great way to contribute when they only have a spare few minutes. One can leave and join at any time, and click/ patrol for all edits that are reported in the channel. In comparison to the checklists, the CVN-channel has a couple of advantages. JelteBot (the recent-changes bot in #cvn-commons) emphasises edits based on blacklists and watchlists, making it easier to detect potential vandalism. (If you monitor other channels too, you could add /Warning!/ to your IRC-stalklist.) So I recommend the "patroller" right for anybody who wishes to participate, which you can ask for here: http://commons.wikimedia.org/wiki/Commons:Requests_for_rights . Please feel free to join #cvn-commons, or Commons' main channel #wikimedia-commons, for more information about other ways to get involved. Every user in the counter-vandalism channel, watching and reacting to the stream, reduces the backlog even more. Watching live means the user can be reverted and warned directly; s/ he will either get blocked if they continue disruption, or (not unlikely) the vandal will stop when s/he reads the warning. Doing this live, instead of afterwards, prevents more vandalism, and thus generate less edits in the backlog. Checklists Since it's unlikely (though the impossible goal of Live watch) to click and patrol each and every link in the IRC channel, lots of links are missed. Either because no-one was on watch, or it got lost in the fast stream of links. For that, we have the checklists. These contain all unpatrolled anonymous edits from a certain time frame. These are, until we have a much bigger team, the primary and most time-consuming ways of fighting vandalism. Also, when you can't access IRC, or don't like it for some reason, the RecentChanges-page is a good alternative: - <http://commons.wikimedia.org/w/index.php?title
[Commons-l] Counter Vandalism Unit - Looking for helpers !
Hi everybody. First of all, for those of you who haven't been here, or didn't get the complete picture, here is a short summary of some recent events: * Last March, I started the Counter Vandalism Unit on Commons <http://commons.wikimedia.org/wiki/Commons:Counter_Vandalism_Unit > * Later that month, the edit-patrol function was enabled on Commons <http://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2010Mar#Marking_edits_as_patrolled > * After a Sitenotice, a few users have signed up to be "patrollers"; and with a small team of 3 to 4 regular patrollers, we keep a checklist of anonymous edits. <http://commons.wikimedia.org/wiki/COM:ANO#Anonymous_edits > The Problem Vandalism on Commons is a big problem, which generates a large backlog. Commons is the primary media depository for most media used throughout Wikimedia. Vandalism on Commons therefore has a greater likelihood of affecting local projects. And, this also brings along the source of vandalism: Vandals. Local vandals are only a click away from Commons. Some don't even realise they are no longer on the local wiki. Some, whether or not knowing they've been blocked on a local project, continue vandalising on Commons. So, having that said, we are looking for help ! The most important areas, for now, are live watches on IRC or recent changes, and the Checklists mentioned above. Live watch For a long time Commons has it's own cvn-channel on Freenode: #cvn- commons . Although there are about a dozen idling users and a bot at any one time, use of the channel for vandal-fighting is not as frequent as desired. Watching live is probably the easiest and most effective way to fight vandalism. Also, for those who don't have the time to patrol an entire daypart- checklist, this is a great way to contribute when they only have a spare few minutes. One can leave and join at any time, and click/ patrol for all edits that are reported in the channel. In comparison to the checklists, the CVN-channel has a couple of advantages. JelteBot (the recent-changes bot in #cvn-commons) emphasises edits based on blacklists and watchlists, making it easier to detect potential vandalism. (If you monitor other channels too, you could add /Warning!/ to your IRC-stalklist.) So I recommend the "patroller" right for anybody who wishes to participate, which you can ask for here: http://commons.wikimedia.org/wiki/Commons:Requests_for_rights . Please feel free to join #cvn-commons, or Commons' main channel #wikimedia-commons, for more information about other ways to get involved. Every user in the counter-vandalism channel, watching and reacting to the stream, reduces the backlog even more. Watching live means the user can be reverted and warned directly; s/he will either get blocked if they continue disruption, or (not unlikely) the vandal will stop when s/he reads the warning. Doing this live, instead of afterwards, prevents more vandalism, and thus generate less edits in the backlog. Checklists Since it's unlikely (though the impossible goal of Live watch) to click and patrol each and every link in the IRC channel, lots of links are missed. Either because no-one was on watch, or it got lost in the fast stream of links. For that, we have the checklists. These contain all unpatrolled anonymous edits from a certain time frame. These are, until we have a much bigger team, the primary and most time- consuming ways of fighting vandalism. Also, when you can't access IRC, or don't like it for some reason, the RecentChanges-page is a good alternative: - <http://commons.wikimedia.org/w/index.php?title=Special:RecentChanges&hidepatrolled=1&days=1&limit=50&hideliu=1&hidemyself=1 > If you don't know how this works, check the following links to get you up to speed: - http://commons.wikimedia.org/wiki/Commons:Patrol - http://commons.wikimedia.org/wiki/Commons:Counter_Vandalism_Unit (last few headings on File and Tools) - http://www.youtube.com/watch?v=eJXvZ65ttQ4 (short video tutorial on the CVU) Then visit the CVU and check out a portion/day-part: http://commons.wikimedia.org/wiki/COM:ANO#Anonymous_edits Thank you for reading, Yours, Krinkle -- Greetings, Krinkle A Wikipedia Volunteer krin...@wikipedia.be - Wikipedia, the free encyclopedia ___ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
