The file you added has been deleted. If you have written permission from the copyright holder, please have them send us a free license release via COM:VRT. If you believe that the deletion was not in accordance with policy, you may request undeletion. (It is not necessary to request undeletion if using VRT; the file will be automatically restored at the conclusion of the process.)
Warning: Wikimedia Commons takes copyright violations very seriously and persistent violators will be blocked from editing.
The file you added has been deleted. If you have written permission from the copyright holder, please have them send us a free license release via COM:VRT. If you believe that the deletion was not in accordance with policy, you may request undeletion. (It is not necessary to request undeletion if using VRT; the file will be automatically restored at the conclusion of the process.)
Warning: Wikimedia Commons takes copyright violations very seriously and persistent violators will be blocked from editing.
The file you added has been deleted. If you have written permission from the copyright holder, please have them send us a free license release via COM:VRT. If you believe that the deletion was not in accordance with policy, you may request undeletion. (It is not necessary to request undeletion if using VRT; the file will be automatically restored at the conclusion of the process.)
Warning: Wikimedia Commons takes copyright violations very seriously and persistent violators will be blocked from editing.
I have likewise reverted additional closures of nominations that may have merit. Copyright concerns need to be addressed regardless of (perceived or real) ulterior motives underlying their nomination. Эlcobbolatalk18:40, 7 June 2012 (UTC)[reply]
I feel such nominations should be speedy closed regardless of the merit. Fresh DRs can be filed independently. This may be a symbolic move but a necessary one. -- とある白い猫ちぃ？ 21:20, 7 June 2012 (UTC)
He is nominating more of them. I insist that this persons nominations be made invalid regardless of merit as
The user is blocked and is block evading.
The user is preforming this as a means of harassment and not due to copyright concerns.
This is the conduct of the user that has gotten him blocked multiple times before.
しろ猫さん。Türkçe Vikipedi'nin köy çeşmesine atılan Alperen'in yazısını okudun mu ? Attribution-NoDerivs 3.0 Unported (CC BY-ND 3.0) ile mi yüklenmesi gerekirdi acaba ? O zaman yeniden formatlı izni istememiz gerekiyor mu ? Yoksa sadece dosya üzerindeki etikerleri değiştirmemiz yeterli mi ? User:Taysine bir mesajı attım da... kontrol edersen sevienceğim. Takabeg (talk) 14:08, 23 June 2012 (UTC)[reply]
Attribution-NoDerivs 3.0 Unported (CC BY-ND 3.0) Wikimedia sitelerinde kullanılabilir bir lisans değil. Sadece CC-BY veya CC-BY-SA geçerli. Tr.Vikipedi köy çeşmesinde belirtim bunu aslında. -- とある白い猫ちぃ？ 15:37, 23 June 2012 (UTC)
Ayrıca resimlerde watermark problemi var. -- とある白い猫ちぃ？ 16:06, 23 June 2012 (UTC)
Certainly, should I revert all my current renames or just specific ones? I was looking at rename requests older than 50 days. -- とある白い猫ちぃ？ 12:31, 25 June 2012 (UTC)
Most have been reverted by RussBot as you moved to a long standing redirect. The others are scheduled in the Delinker. Please don't insert speedy deletes in categories that are not empty as some admins speedy blindly. --Foroa (talk) 13:05, 25 June 2012 (UTC)[reply]
You mean POTY ones? How were those problematic? Only -en was an issue for protected pages I believe.Fixed! Category:Commons:Poty (en) is empty now. -- とある白い猫ちぃ？ 13:15, 25 June 2012 (UTC)
So let me get this straight. You can decide to rename (without discussion)
Category:Commons:POTY (ar) to Category:Commons:Pictures of the Year (ar)
But I cannot rename (with past proposal)
Category:Commons:Poty (ar) to Category:Commons:POTY (ar)
Why is this? Have you considered discussing your renames with POTY people?
I do not necessarily object to your renames but I do not like your methodology. If I make erroneous edits with my bot, I should be given the opportunity to fix the issue. When you revert through RussBot or CommonsDelinker you create controversy that can be trivially avoided. You also risk creating a revert-war situation with the bots as bots do not know each others activity.
Also I immensely dislike your use of a revert tool for edits that are not vandalism. A manual revert is not that hard.
The most important Poty categories where tagged with a rename request to POTY. I contested them some while ago for the simple reasons of uniformity with "pictures of the day" naming and that POTY equals not "Pictures of the Year" and there was no second opinion. But you decided to move them anyway. We try to avoid and remove all the time acronyms as they tend to be country specific, and here, we keep adding them. When looking at the higher and lower level categories, it becomes clear that "pictures of the Year" is the most consistent solution.
And yes, I moved this year around 12000 categories, so it is not impossible that some of them are contested (moves to disambiguated categories are almost always contested anyway). --Foroa (talk) 15:35, 25 June 2012 (UTC)[reply]
Like I said, I am not contesting the actual rename. I dislike your methodology. You went ahead and reverted my renames without bothering to settle the issue on my talk page first. Had you merely asked here, I would have made the changes you are trying to reach. -- とある白い猫ちぃ？ 17:44, 25 June 2012 (UTC)
I am the bot operator, it should be my job to clean any mess my bot creates. RussBot exists to revert my bot? I do not understand. -- とある白い猫ちぃ？ 17:44, 25 June 2012 (UTC)
I do not see why you are opposing the addition of optional parameters (for location for example) to this template. Can we discuss this on talk pages as village pump is a bit cumbersome for me. -- とある白い猫ちぃ？ 14:07, 18 June 2012 (UTC)
I think the village pump is a good place for such a widely used template as few will have the template page on their watchlist. If the community agrees that it is worth while modifying the template, then the details can be thrashed out on the templates talk page. --Tony Wills (talk) 21:49, 19 June 2012 (UTC)[reply]
No one will agree to that unless details are determined. -- とある白い猫ちぃ？ 21:55, 19 June 2012 (UTC)
Do you understand that by modifying the template at all means that the page cache for every single image page that uses it will be invalidated? And this has nothing to do with the actual number of edits to pages containing {{Location}}, {{LargeImage}} etc (each of those edits will be on top of the load caused by just editing {{Information}}). --Tony Wills (talk) 21:45, 19 June 2012 (UTC)[reply]
I do not believe this is a problem. As devs always say, let devs worry about performance. Code can be throughly tested on Template:Information/sandbox first, can be then proposed and rolled in if approved. -- とある白い猫ちぃ？ 21:55, 19 June 2012 (UTC)
As a user of this site I am concerned at the responsiveness of the system, its performance and efficiency. I am concerned with the idea it doesn't matter what we do, someone will buy more storage, or more computing power. Use our resources wisely, don't squander things even if they are abundant - unnecessary changes are a frivolous waste of donated resources.
At the moment I consider that the template only contains one non essential field "other versions", all other fields are important pieces of information that we should have about every image:
Description
Date
Source
Author
Permission
(there is also another field "other_fields" to easily add other non-standard information fields). Things like "location" are not required for every type of image, exact gps coordinates for stationary objects like buildings and landscape features are useful, but for most things this is not actually relevant and will probably never be provided. eg it is sometimes useful to know where an animal or person or plant was seen when photographed but this is the exception. There are many, many templates we could merge into the information template, but why? Your only argument appears to be a cosmetic one of putting things in some standardised order, when there is not a demand for such ordering, let alone agreement of what it should be. --Tony Wills (talk) 23:00, 19 June 2012 (UTC)[reply]
Please drop the performance argument. It does not affect resources aside from a one time only backlog. It isn't an issue according to the devs so it is not an issue for me as well.
Point of CSS and templates is cosmetic issues. In a website having such uniformity is a good practice.
Location is essential information. You can use GPS location to assist in a wide variety of ways. For instance it can be used for automatic identification of species of plants as elevation data based on GPS coordinates can be used to determine the climate and if that is compatible with the animal or plant. Furthermore with location it is possible to take better quality photos of the said object. Where something geographically is matters just as much as when it was created.
Sorry, I can't agree with any of those three assertions. Especially "automatic identification" sounds rather bogus. That sort of concept may be useful on a statistical basis, but has zero value for individual pictures, especially if it is for instance a photo of a cultivated plant. I stand by my assertion that for our media bank GPS data is primarily useful for static objects, and only a subset of our images. --Tony Wills (talk) 12:36, 23 June 2012 (UTC)[reply]
I cannot likewise agree with your baseless claim either which cannot go beyond mere opinion. As you can see, I can be equally dismissive and this gets us nowhere.
What you call bogus and dismiss is what is being done.
GPS is among the meta data used to identify species. GPS alone would be inadequate but it is among many features that increase accuracy.
You can mow down the list of possibilities strictly by using the GPS info particularly if you have a database where each plant can survive.
You can also use a machine learning algorithm to learn about where plants typically live by cross referencing GPS coordinates with climate data for the said coordinates. Even if the algorithm cannot be 100% sure what the plant actually is, it can shortlist likely candidates to a botanist.
GPS data is more relevant than the date of the files creation (since only a small subset is old enough for date to be remotely useful) and should be integrated into the template.
The proposer of change needs to provide argument and evidence to support the need for the change, not just assertions.
Thanks for that link, an interesting initiative. If they come up with something that reliably classifies plants from pictures of leaves, even just down to the family level it will be useful, a tentative species identification would be wonderful. I would be interested to know exactly what weight they give to location info. I suppose it depends on whether they are cultivated plants or growing in the wild. Mankind has a habit of taking plants and animals with him where-ever we go, so a lot of things are grown well outside their normal range, often we grow plants in places where they wouldn't survive or reproduce successfully by themselves. So I will concede that camera location info of good photos of plant leaves, taken in-situ could be useful :-).
I have just done a quick survey of 30 images (selected with the "random file" link)
My preference would be for all files to have a standard information template (description, author etc), then other templates dependant upon the type of thing depicted (artwork, museum specimen, plant/animal, building, panorama ...). Some things might have say both a artwork and plant/animal template (painting of an animal/plant).
Your comment about the "Date" field brings up a point that has never really been resolved - what is the date field for? For copyright purposes the date of first publication might be useful (= the date uploaded here for many images), but it is also used for the date a photo was taken, or just the date uploaded (whether or not this is the first publication). Which leads to a similar question about what location information we want - at the moment it is primarily "camera location" information, I created an "object location" variation, and if it doesn't already exist a "place depicted" template might be useful with for example landscape paintings. --Tony Wills (talk) 07:15, 24 June 2012 (UTC)[reply]
Opposition to edits also needs valid claims. :) This is a wiki, edits should not require prior approval. On that note... You kind of proven my point. At least one of the files you randomly found while I was browsing randomly had the problem I was talking about: File:Luitré - église.jpg. It was problematic since upload in this case. If the two templates are merged this problem will never happen.
That initiative is among the things I would have presented at Wikimania 2012 had my application gotten the support, it hasn't which is why I have not had a good median to discuss availability of such tools of Artificial Intelligence. The plant identification task uses leaf shape and size as well as other criteria into account mind you so GPS is just one of the many criteria.
Copyright can be very dependent on the location the file is taken. GPS information could be deterministic in establishing which countries FOP applies for example. If a file falls within the coordinates of a country where there is no FOP whatsoever and that image is also in a statue category, you have a FOP violation candidate with fairly high confidence to be brought to DR. A human can verify these and nominate for deletion.
Furthermore there are various tools that can exploit GPS data to express commons images in a different manner. For instance Google earth can use the GPS coordinates to place images and video onto a map where user can click to see the view from those coordinates. Heck, there is an interactive map feature linked from GPS coordinates already!
My point with my examples is that GPS information is important enough to be included in the main template. GPS information will not be usable for every file but same can be said about some of the other parameters of {{Information}}. If GPS information isn't provided the template would simply hide that field.
Camera location, depicted image location & etc can be overloaded to a single template. My point currently is GPS coordinates for camera locations which can be machine generated in bulk.
Going on a tangent here but, date field is more useful to establish copyright of PD-Old files and is not very useful for more recent files as buildings and other stationary objects do not change that much. It is interesting never the less but not as critical. There already is a "Date and time of data generation" filed for meta data so the date field is redundant for an important percentage of the files it appears on. That said the "Date and time of data generation" meta data could be wrong as it could be the scan date.
1 ) I don't have any problem with how File:Luitré - église.jpg looks, in fact I think it looks quite good, it highlights and draws attention to that additional block of information. It's easy enough to have a bot reorder templates if that's what you want.
3 ) You certainly come up with new uses for GPS data. The location/FOP idea would be marginaly useful, you must bring together information about the subject of the photo (some human construction), whether it is new enough to be still covered by copyright, the details of the countries copyright lengths etc. The last thing we need is dozens of false positives. But, yes a tool for a very small subset of images, doesn't get us very much closer to saying that location is essential information for every image.
4 ) That GPS data can be used by third parties using our images still doesn't go anywhere to saying this is an essential field in the info box, as shown above location is only relevant to about 50% of our images.
5 ) I don't think that your examples have demonstarted importance, only usefulness. Nothing yet to dispute the fact that location is irrelevant to about 50% of our files. I agree that location information is useful that isn't what I'm disputing :-)
6 ) Having a single location field in information means it only allows for it's use as either "camera location" or "object location", what if you want both? :-)
7 ) Date Tangent: Out of the various uses for the date field that I listed, I have always supposed it is primarily for publication date (as this relates to source,author,permission). But as regards just dating photographs I disagree entirely, there are often huge changes even just to the exterior of building (let alone streets, landscapes and anything else) in just a few years. I am digitising someones holiday snaps (35mm slide film) of an Australian holiday in the 70's very interesting to compare with today. --Tony Wills (talk) 08:17, 25 June 2012 (UTC)[reply]
I suspect that part of the rationale for including the location as a standard part of {{Information}} is that it will somehow increase the addition of this information? I'm not sure that can occur very readily. If GPS info is in EXIF data, that is already being added as a {{Location}} by a bot. So that leaves people adding the info probably by looking at googlemaps etc, something that isn't going to happen on a large scale considering all the other things that need doing around here. --Tony Wills (talk) 08:17, 25 June 2012 (UTC)[reply]
How about this, comparisons of how a place was in the past and today is uninteresting to me and can be used by third parties. What is more interesting to me is location based browsing. You cannot expect everyone to have the exact same reason to look for information on commons as you.
I do not see any reason why you are objecting beyond "it isn't necessary to merge". I am sorry but that fails to convince me that how addition of optional fields to {{Information}} would cause problems to the project. The only issue you tell that is worth some further investigation is the performance impact as the template is transcluded in over 10 million pages - which devs I have talked to do not consider it too big of a problem. But I intend to come up with numbers for that too.
I trust that is just a rhetorical argument, and that you really do value the educational value of the history things depicted by images. Please note that I am not arguing against associating location info with images, to the contrary I wish to see such info about all images where it is relevant. Your proposal has nothing to do with the inclusion or exclusion of location info, and you have not demonstrated or even argued how the arbitrary placement of this information in one particular place, within the standard {{Information}} template, improves the provision of that information or the useability of that information via things like google maps, to browse by location.
The precendant of adding fields only relevant to a subset of images to the information template will just mean that the addition of everyone else's favourite field can be argued on the same basis. Maybe, for some reason, that is what you envision?
To the contray you have demonstrated no advantage to the project of your proposed addition. Where is the call for the location info to be in a particular place within the {{Information}} template, or even the consensus for its placement relative to that template? --Tony Wills (talk) 00:19, 26 June 2012 (UTC)[reply]
Actually, I really do not care about the date filed all that much unless image is historic and that info is needed to determine the age of the file. Like you I am not suggesting this information should be removed, it may be useful to others, just not to me. I am not suggesting we should break the template but all of the individual fields on the template would not survive the "demonstrate why it should be merged" ad hominem argument. This is a wiki, edits of one user could be viewed as unnecessary as others. If the edits to not disrupt the site, they are fine.
There is no current precedent banning expansion of information template, why would there be a precedent if template is edited?
I do not need to demonstrate the advantage to make edits... I gave a few examples of advantages such a merge would have which you have dismissed. There is no consensus against it either. It is additional optional fields. Template functionality can be increased, this isn't banned.
You seem to want to dismiss anything and everything I say. If you do not have a real reason to object beyond performance concerns, what are we discussing?
Could I ask you to add something like 51 more images to this? :) I think more randomness would be nicer. -- とある白い猫ちぃ？ 21:38, 20 June 2012 (UTC)
Accelerating history, originally there was no image on the VP page then in 2004 User:Bdk added a picture of a hot pool in Iceland, that sort of looks like a well [1]December 2004 (It looks as though it was originally a slightly larger image on the Icelandic wiki and was cropped slightly, the author was given as "Jón Jónsson" which google translates as "John Doe" ... but the only versions of the original file that I've found on the internet are smaller and later than our original upload, eg [2]).
Then in 2009 I finally found a good image on Commons of an actual village pump that also looks like a meeting place [3]March 2009.
That started something and we got
July 2010
December 2010
January 2011
April 2012
Then you gave us 6 images that can change every minute (I think it can only change if the VP has been edited and the template reloaded), now you want 60! ;-). This is a very steep expotential curve, where will it end!
The idea is I want to have more than 6 "random" images which will get old quickly. The thing is if we have more than 24 of them they would rotate over time slowly so that they do not become boring again.
The files (should) update every hour (I just fixed this) even if the village pump isn't edited much like the main page & POTD. I do like the concept of "village pump" as a gathering place rather than a display of rusty relics. That said it could be nice to have one machine pump if we decide to have a lot of images. I like Balga, February 2010, Women around the water pump.jpg better since it has people but do not really object to any of the pumps presented here.
"Gathering place" or rather "meeting and chatting place" is the whole idea behind calling it "Village pump" (ie people lined up to collect their daily supply of water run into other people in a slightly random way and chat while waiting their turn), but I think that metaphor is somewhat lost, and most people don't know why it's called village pump. Someone started a Commons:Beer parlour at about the same time as VP, but they were quickly merged.
The purpose of the picture is not just to decorate the page, but to illustrate the page's purpose so I would actually be quite happy with a single good image, but a variety is nice :-) --Tony Wills (talk) 09:53, 25 June 2012 (UTC)[reply]
new version - emphasise conversation & pump, now we just need 59 more ;-)
Human brain ignores repetition after a while. This is why a new image would remind people of the purpose of village pump. The image is inherently decorative as the page would function without it. But that is fine! We are an image repository, demonstrating our images is what we do best. :) -- とある白い猫ちぃ？ 08:22, 27 June 2012 (UTC)
Would you mind subst:ing all usages so we can start to autotranslate this template (just if you already have a bot-code for this). Thank you. -- RE rillkequestions?09:04, 25 June 2012 (UTC)[reply]
I translated valued and quality but there's a problem.
They appear translated only in some examples(last two sample usages) but not in the main ones(sample usages ten and eleven).
Another unrelated problem with the current english translation. In the sample usages about only quality and valued(10 and 11), "If you think this file should be featured on Wikimedia Commons as well, feel free to nominate it.".
I don't think that as well should be there for we are talking about assessments on commons only. That's for pictures featured on other wikis but not on commons.
I suppose that should be "If you think this file should also be featured on Wikimedia Commons, feel free to nominate it." but changing it would require some template-code editing.
--Gauravjuvekar (talk) 18:05, 23 June 2012 (UTC)[reply]
Hi,
I have fixed the issue. Not sure why it happened but it is fixed now. :)
"As well" here refers to files that have an assessment of some sort that are not featured on commons - that said the language can be adjusted to "also".
Thanks for that. Now I've prepared a rough translation of the main Featured part but since that's the wickedest part, I'm gonna need a lot of help. From what I understand, that part works as follows.
This {switch1|is/formerly was} a featured {switch2|sound/picture} on {project name} and {switch3|is/was} considered one of the finest {switch4|sound files/images}.
where switch selects one of the options and switch1,3 and switch2,4 are related.
Based on that, I found a translation which would perfectly fit in with just a little rearrangement.
यह {project name} पर एक निर्वाचित {switch2|ध्वनि/तस्वीर} {switch1|है/थी} और सर्वोत्तम {switch4|ध्वनि संचिकाओं/छवियों} में से एक [[मानी गई {switch3|है/थी}.]]
with squared brackets denoting the link from 'considered'.
I can't figure out which part of the code controls switch3,4 so could you rearrange the code as explained?
switch1 is {{#switch:{{{num|{{{3|}}}}}}|1|3=is|2|4=formerly was}}
switch2 is {{#switch:{{{num|{{{3|}}}}}}|3|4=sound|1|2=picture}}
switch3 is {{#switch:{{{num|{{{3|}}}}}}|1|3=is|2|4=was}}
switch4 is {{#switch:{{{num|{{{3|}}}}}}|3|4=sound files|1|2=images}}
I've numbered them 1-4 for convenience. I have to rearrange them but I don't know if any part of
([[{{#ifeq:{{{project|{{{2|}}}}}}|com||{{{project|{{{2|}}}}}}:{{{lang|{{{1|}}}}}}:}}{{{namespace|{{{4|}}}}}}:{{{name|{{{5|}}}}}}|{{{name|{{{5|}}}}}}]]) and {{#switch:{{{num|{{{3|}}}}}}|1|3=is|2|4=was}} [[{{#ifeq:{{{project|{{{2|}}}}}}|com||{{{project|{{{2|}}}}}}:{{{lang|{{{1|}}}}}}:}}{{#if:{{{nomination|{{{7|}}}}}}|{{{nomination|{{{7}}}}}}|{{{namespace|{{{4|}}}}}}:{{{candidacy|{{{6|}}}}}}}}|considered]] one of the finest {{#switch:{{{num|{{{3|}}}}}}|3|4=sound files|1|2=images}}
where the asterisks denote text to be entered. I want the entire text in single square brackets at the end to link to the nomination page(the link from "considered" in english) meaning the last switch should be a part of the link.
Could you please rearrange the code so I'll just substitute parts of it in Hindi.
I do not quite understand your request, you already rearranged it as above. :) You can move the switch code around they are each independent of each other. I don't know Hindi grammar so I cannot understand what you want me to do. Do not worry about breaking the code, I will fix any problems that may arise. -- とある白い猫ちぃ？ 07:59, 27 June 2012 (UTC)
Done. It sort of works except for examples 6, 7, 8 & 9 i.e. for former featured. The wiki-text of the link is shown like "[[Commons:|मानी गई]]". I haven't yet translated the names of all the other projects. Also, I guess you need to translate COM:Featured pictures into Hindi for the link to (Featured Pictures) to appear in Hindi. I'm not going to translate that any time soon so I guess it's okay if it's in English.--Gauravjuvekar (talk) 13:58, 27 June 2012 (UTC)[reply]
Thank you for the translations so far. The "featured pictures" text is dependent on the project except commons which is multilingual. The translation for that is here but there doesn't appear to be a Hindi translation for Commons:Featured pictures.
यह चेक विकिपीडिया पर एक निर्वाचित तस्वीर (Obrázek týdne) है और सर्वोत्तम छवियों में से एक मानी गई है.
यह ज़र्मन विकिपीडिया पर एक निर्वाचित तस्वीर (Exzellente Bilder) थी और सर्वोत्तम छवियों में से एक मानी गई थी.
यह अंग्रेजी विकिपीडिया पर एक निर्वाचित ध्वनि (Featured sounds) है और सर्वोत्तम ध्वनि संचिकाओं में से एक मानी गई है.
यह स्पेनिश विकिपीडिया पर एक निर्वाचित ध्वनि (Recursos destacados) थी और सर्वोत्तम ध्वनि संचिकाओं में से एक मानी गई थी.
Do these four read correctly? These are the visible in the last item on the page.
Yup, they are fine but the last entry in the last sample usage, the 'Cantonese' doesn't get translated(rather transliterated). Also, see the 6,7,8,9 usages. The link from considered (to the nomination page) is broken and shows as [[Commons:|मानी गई]].--Gauravjuvekar (talk) 07:53, 28 June 2012 (UTC)[reply]
Cantonese is an issue I am aware of, it has to do with MediaWiki localization.
I fixed the broken "considered" link for former featured pictures just now. It was a mistake on my end not yours. :)
Let me know when you have time to translate remaining lines. :)
.jpg){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg){kind=link}
_V1_278.jpg){kind=link}
![[2]](http://www.vestfirdir.is/resources/photographs/580-gvendarlaug.jpg){kind=link}
