Commons talk:File renaming/Archive/2012

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Rename identically named different files


Could we make this a policy? I do not want to move valid requests over the grounds that they will be deleted anyways. -- とある白い猫 ちぃ? 23:41, 14 March 2012 (UTC)

I have added this as the 4th rationale to decline rename requests. -- とある白い猫 ちぃ? 13:55, 18 March 2012 (UTC)

Reference to obsolete processes in See Also

Moved to talk page, as I don't think it's particularly helpful to have it on the page any more:

  • Commons talk:MediaMoveBot — when file renaming wasn't active on Commons, this robot would reupload the image under the target name; an administrator would then review this and instruct another robot to replace the image on the several Wikimedia projects; finally the administrator would delete the bad named file.
  • Commons:File renaming/requests — obsolete page. The template + category should work for this from now on.

Rd232 (talk) 09:10, 28 March 2012 (UTC)

The disastrous effects of needless renames

I really do not understand why someone would first rename File:Soldat de première classe.svg to File:Army-FRA-OR-02.svg, and then crop out most of the items in that file (see previous versions). For a whole series of files. Look what happened in the history of a French article what effects such operations have. There is no need for any of that. If someone wants a different crop or a different orientation, just make a new file with your favorite naming scheme, and use that one on your own page. /Pieter Kuiper (talk) 01:42, 6 April 2012 (UTC)

A problem with the Sardinian flag

I would like to point out that the official flag of Sardinia region is this (check here) and not this (just an artistic rendition). The first one should be renamed Flag of Sardinia.svg while the second one should be renamed Flag of Sardinia alternative.svg or something similar, but this could cause some problems with redirects.--Carnby (talk) 16:35, 6 April 2012 (UTC)

Breaking up criteria

Below criteria could perhaps be made more specific.

  • Change from completely meaningless names into suitable names, according to what the image displays
  • Correct misleading names into accurate ones
  • Change meaningless bio-names into binomial scientific names
  • "Correct obvious errors in file names (e.g. wrong proper nouns or false historical dates)"
  • Harmonize file names of a set of images (so that only one part of all names differs) to ease their usage in templates (e.g. diagram symbols, scans of pages of a book, maps)
  • Remove pejorative, offensive or crude language that would not be appropriate in the file description

For instance wrong proper nouns and false historical dates should perhaps be separate criteria such as

  • Correct obvious spelling & grammar errors
  • Correct obvious historic date & reference errors

-- とある白い猫 ちぃ? 18:28, 3 April 2012 (UTC)

Obvious errors do not matter. Why would one want to correct a spelling error in a file name? If someone feels a need to be pedantic, they can fix refine the category structure. That is useful. /Pieter Kuiper (talk) 18:37, 3 April 2012 (UTC)
Why would one want to correct a spelling error in a file name? - for one, because words in filenames are currently given great weight in search results. Rd232 (talk) 18:41, 3 April 2012 (UTC)
The best way of ensuring that files can be found is by proper categorization, which also helps search engines. There are loads of uncategorized or poorly categorized files, it is a great area to work in for people who like putting things in proper order. File names are just tags for identification. /Pieter Kuiper (talk) 21:17, 3 April 2012 (UTC)
  • Having a search facility optimised for filenames containing the keywords makes sense for mono-lingual projects - the keywords and filename are going to be in the same language, and assuming the filename is somewhat descriptive of the content this helps in search optimisation. But on Commons, optimising the search results on the basis of the uploaders language preference (ie the language in which they named the file) makes far less sense - unless (for example) you want to bias French speakers towards files uploaded by other Frenchmen. That is why multilingual descriptions are so important - the filename is only in one language (normally). We really should just view the filename as a "handle" with which to refer to the file and differentiate one file from another. It shouldn't matter to me whether the filename is in Greek, SMS txt language, abbreviated or mis-spelt (or mis-spelled if you prefer).
Obviously it is "nice" to have things spelt "correctly", but are we going to insist on renaming SMS txt language, abbreviations and alternative dialect spelling? Improving the search ranking in a particular language for an individual file needs to be balanced against the necessity to keep the mis-spelt redirect: just because a filename was mis-spelt doesn't mean we should break any incoming links that are trying to satisfy CC license attribution requirements. --Tony Wills (talk) 23:32, 3 April 2012 (UTC)
  • To my mind there are three reasons to rename a file on Commons.
1) Remove pejorative, offensive or crude language that would not be appropriate in the file description
I don't think this needs any further justification
2) At uploaders request (or perhaps authors request)
In the case of the author, there is some moral right to have their work presented as they see fit, but in general their filename needs to conform to our file naming guidelines, so although not a definitive reason, a very strong criteria for renaming
3) Immediately (perhaps days to a month) after upload to correct any number of typos or mistakes
As long as the change conforms with our naming guidelines or has a good reason not to (most of these are probably at uploaders request anyway).
4) To correct undisputed errors that are misleading (e.g. wrong proper nouns or false historical dates)
"Obvious errors" isn't quite right, eg the date for a country's map outline may not be agreed by all! This criteria should not be used to just give a "better name" as there is always a "better name" in somebodies opinion.
Specifically I would leave out justifications based on typos or spelling mistakes, and attempts to give all images of animals/plants "binomial scientific names". The latter is because it is unnecessary (put it in the description) and such a policy justifies (if not mandates) renaming all files of a particular species whenever it is reclassified. If the filename is a common name, descriptive name or synonym/previous-classification it is adequate. If it is wrong eg File:Loxodonta africana.ogv instead of File:Mus musculus.ogv then it falls under the "undisputed errors" criteria. Upload an unknown plant as File:Yellow flowers with black-orange caterpillars.jpg rather than Unknown caterpillar.jpg, and even when you find out it is "Nyctemera annulata" on "Senecio jacobaea" don't rename it because the next year someone will probably decide it is actually "Nyctemera amica" on what is now called "Jacobaea vulgaris" - just update the description.
  • To summarise: This is a multi-lingual project, file names are not article names, file description, nor of great import (, though you may fill them with keywords to optimise your file in the search results for people using the same language ;-). Refrain from renaming files unless it is really needed by the project. Concentrate on decent file descriptions (in multiple languages) and perhaps categories (once we sort out how to stop category churn and make that system useful ;-). --Tony Wills (talk) 23:32, 3 April 2012 (UTC)
    • If you want to revoke this guideline entirely, feel free to post a separate request. This is not the point of this thread. This thread is to break up existing criteria so that rename rationale is clearer. When I move a file over false historic dates I am also suggesting there are problem with proper nouns. It is confusing to anyone who looks at the log. -- とある白い猫 ちぃ? 16:09, 4 April 2012 (UTC)
I think the tone of the current guideline is about right and I wasn't advocating revoking it. Perhaps it is just a matter of interpretation, and you are then right that it needs to be clarified. But "Correct obvious spelling & grammar errors" is a serious matter of instruction creep, that is not what the current guideline says. Instead it says ""Correct obvious errors in file names (e.g. wrong proper nouns or false historical dates)". A wrong date is "1987" instead of "1897", a wrong proper noun is "Phar Lap" instead of "Seabiscuit" . Admittedly the example is of a mis-spelling resulting in a different but incorrect name. "Ayres Rock" is a different place than "Ayers Rock" - Ayres Rock, Sanday, Orkney, Orkney Islands, Scotland eg [1] (I think a local area has the name Ayres and they are perhaps feeding off typos by using the name "Ayres Rock") vs Ayers Rock, Northern Territory, Australia. I am not sure about your reference to logs, but at first glance the move-log may be misleading as many moves should actually be classified as "at uploaders request". --Tony Wills (talk) 01:51, 7 April 2012 (UTC)
The criterion to "Harmonize file names of a set of images" should be made clear that it is about sets of files that already has well established and widely used file naming schemes. For example the widely used BS icons across multiple projects, or that scans of book pages only differ in the page number (although a single DjVu may be better than individual images). It should not be to create completely new schemes, e.g. by changing all or the set of portraits to "Portrait <surname> <firstname> <date> <location>.jpg") or by merging already existing schemes into larger sets with a single scheme (like "Blason ville fr <name>.svg", "<name> vapen.svg" and "<name> Wappen.svg" to "Coat of arms <country> <placename>.svg"). /Ö 18:05, 5 April 2012 (UTC)
I think it makes sense to say that harmonisation to a naming scheme should only be done when there is a demonstrated consensus for a scheme. That brings us back to the question I raised at COM:VP about how we demonstrate such consensus. Rd232 (talk) 18:20, 5 April 2012 (UTC)
To me it is quite frustrating to hunt down set items in categories and elsewhere when they do not follow one single pattern. As far as search engines are concerned, filename is very relevant. A spelling error could significantly change the files ranking in google images particularly if the alternate word is not a common spelling error or if it means something else altogether (even in a foreign language). A good example that comes to my mind is the word wikt:dürüm verus the word wikt:durum. It is the same word, one with umlauts. If I see a file named "durum" (that depicts the food stuff) I should be able to rename it to "dürüm" even if the file is slightly better.
I noticed several references in the discussions on this issue and other similar issues where people talk about links being broken after files are moved. I think this is a software bug that needs to be addressed, not a policy rationale.
-- とある白い猫 ちぃ? 16:11, 9 April 2012 (UTC)

Renaming of categories not named in English

This conversation has been moved from User talk:CommonsDelinker/commands  — billinghurst sDrewth 15:44, 10 April 2012 (UTC)

{{move cat |Cimetière Français d'Auvelais |French cemetery Auvelais |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:14, 6 March 2012 (UTC)}}
{{move cat |Presbytère polonais de l'église Saint-Louis de Rouvroy |Polish rectory of the church of Saint Louis Rouvroy |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:14, 6 March 2012 (UTC)}}
{{move cat |Presbytères français et polonais de l'église Notre-Dame des Mineurs de Waziers |French and Polish presbyteries of the church of Our Lady Miners Waziers |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:14, 6 March 2012 (UTC)}}
{{move cat |Société des anciens textes français |French society of ancient texts |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:14, 6 March 2012 (UTC)}}
{{move cat |École du ski français |French ski school |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:14, 6 March 2012 (UTC)}}
{{move cat |Collection de costumes polonais, Dessinés d'après nature par Norblin et gravés par Debucourt |Polish costume collection, drawn from nature by Norblin and engraved by Debucourt |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:14, 6 March 2012 (UTC)}}
{{move cat |Muzeul Național al Hărților și Cărții Vechi |National museum of maps and rare books, Bucharest|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:14, 6 March 2012 (UTC)}}
{{move cat |Faaborg Klokketårn |Faaborg Clock Tower |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:30, 6 March 2012 (UTC)}}
{{move cat |Fabrique de porcelaine Gaucher et Vincent-Blin Vierzon‏‎ |Porcelain factory of Gaucher and Vincent Blin Vierzon |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:30, 6 March 2012 (UTC)}}
{{move cat |Fachhochschule Köln, Campus Gummersbach‏‎ |University of Applied Sciences in Cologne, Campus Gummersbach |3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 21:30, 6 March 2012 (UTC)}}
{{move cat |Musée des monuments français|Museum of French Monuments|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Fontaine du Théâtre-Français (Paris)|Fountain of the French Theatre (Paris)|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Musée français de la brasserie|French museum of the brewery|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Croquis de plantes en français|Sketches of plants in French|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Club français de football féminin|French female football club|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Institut français de la mode|French institute of fashion|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Musée français de la photographie|French Museum of Photography|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Étoiles d'or du cinéma français|Golden stars of French cinema|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Lycée français de Los Angeles|French school in Los Angeles|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Agence pour l'enseignement français à l'étranger (AEFE)|Agency for French education abroad (AEFE)|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Cimetière français de Dinant|French cemetery in Dinant|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
{{move cat |Elève français en formation à l'École navale allemande|French student in training at the German Naval Academy|3=Language policy [[User:PereslavlFoto|PereslavlFoto]] ([[User talk:PereslavlFoto|<span class="signature-talk">talk</span>]]) 14:51, 26 March 2012 (UTC)}}
 Comment before doing these moves, it would be useful to get a bot to run through and create language templates under the existing name, and then to repeat the process after a move. Put on hold pending that discussion/action.  — billinghurst sDrewth 02:07, 9 March 2012 (UTC)
 Comment Noone arranged any discussion and proceeded any action, because this is useless, and the above-mentioned category names are illegal.--PereslavlFoto (talk) 09:56, 27 March 2012 (UTC)
 Comment Half the suggested changes are just wrong; it would never be French cemetery of Dinant, it might be French cemetery in Dinant. French museum of photography isn't correct; it'd have to be French Museum of Photography. Furthermore, it's likely that the most commonly used name in English is "Musée français de la photographie".--Prosfilaes (talk) 10:00, 2 April 2012 (UTC)
This does not matter, because the Rule orders all the categories to be in English. The categories in French or Russian are prohibited.--PereslavlFoto (talk) 20:00, 2 April 2012 (UTC)
 Comment: my understanding is that for the names of places, English names are only necessary where there is an official English term by which the place is known (e.g., "Palace of Versailles" rather than "Château de Versailles", but "Musée d'Orsay" and not "Orsay Museum"). If there is no such official English term, it is unnecessary to artificially create an English translation. (I'm not sure whether we have a policy about place names written in non-English scripts.) — Cheers, JackLee talk 07:27, 3 April 2012 (UTC)
There is no strict policy about this; the only policy idea is the caterogy names should be in English. But anyway, the Practical Rule I heard from many wiki users says there must be no categories other than English, no Russian and no French. Any Russian word has to be translated, so why French words don't have to? There is no special policy to protect French names.--PereslavlFoto (talk) 09:00, 3 April 2012 (UTC)
Maybe this discussion should be moved to "Commons talk:File naming"? — Cheers, JackLee talk 08:03, 10 April 2012 (UTC)
No. The discussion is about category renaming, so Commons talk:File renaming is not the right place. /Ö 16:44, 10 April 2012 (UTC)
The approach often taken is to use the name most often used in English literature. In the past I was using number of Google hits as a proxy for what terms might be more common. The most commonly used names of different places or people might end up being the one in the native language. In cases when the native language does not use Latin alphabet (or Latin based alphabet), names are often transliterated. --Jarekt (talk) 17:19, 10 April 2012 (UTC)
So I may use any language in category names? The policy statement about "should generally be in English" means "should be in any language"?--PereslavlFoto (talk) 18:08, 10 April 2012 (UTC)
Depends on the subject. If the subject is local, there is no problem with local names (but it should be in Latin script). The problem is with Spanish or Polish categories of general subjects, like science, because those would be parallel category trees. /Pieter Kuiper (talk) 18:22, 10 April 2012 (UTC)

In addition to the comments of Jarekt: Category renaming is a complex issue and takes quite some research and energy. A list of the factors that influence it:

Is the name existing in (English) reference works or school books. En:wikipedia tends to be a quite unreliable reference as people tend to invent translations that are often suboptimal.
Are there dependencies and subcategories: some people try to translate for example Schloss xxx in xxx Castle, while there is beer brand with that name produced in that area or there are many other categories or objects referring to the same name (roads, hills, buildings, pubs, ...)
The international importance of the item: are they referring/connected to famous people, events, artists, cultures ...
The role and place in the category tree: an end leaf in a tree will attract less critical reviews
The general comprehension by people; the closer the name is to germanic and/or romance languages, the less it will be criticised. Category names in languages of central and eastern Europe will be translated quicker, category names using non-latin characters sets and scripts will be translated almost immediatly as only a very small fraction of the Commons community can even read and memorize them. --Foroa (talk) 06:16, 11 April 2012 (UTC)
With reference to Ö's comment above, should this discussion be moved to "Commons talk:Categories"? — Cheers, JackLee talk 14:37, 11 April 2012 (UTC)

Naming convention for ranks and insignia

This is a fork of Commons:Village pump#Naming convention for ranks and insignia.

This is a semi-fork of Commons:Village pump#File naming schemes.

Commons follows naming conventions for symbols typically if these are a set of objects. This can be observed in many ways including with flags where they are always named Flag of foo which makes their template use significantly easier.

My proposed naming convention is: "[Branch]-[TLA]-[OF/WO/OR-level][a/b/c (optional)].ext" where

  • [Branch] is the branch of the armed forces (Army, Navy, Air Force, Marine, Gendermerie, etc.)
  • [TLA] is the three letter abbreviation of the county per w:ISO 3166-1 alpha-3 also used by the United Nations.
  • [OF/WO/OR-level] denotes the level and type of the rank as denoted by NATO STANAG 2116 - edition 6 (25 February 2010) where
    • STANAGs are required to be ratified by every member nation to enter service. They are not arbitrarily created.
    • OF means Officer
    • WO means Warrant Officer (only applies to US Warrant Officer ranks)
    • OR means Other ranks that refers to both Non-commissioned officers (NCOs) and Enlisted personnel
    • Levels (OF-01 to OF-10, WO-01 to WO-05, OR-01 to OR-09) are based on as they appear in the STANAG itself which covers 28 countries.
      • OF-06 to OF-10 refers to flag officers (Generals/Admirals)
      • OF-03 to OF-05 refers to senior officers:
        • OF-5: Colonel, Captain (navy)
        • OF-4: Lt. Colonel, Commander
        • OF-3: Major, Lt. Commander
      • OF-01 to OF-02 refers to junior officers:
        • OF-2: Captain (army), Lieutenant (navy)
        • OF-1: (first) Lieutenant (army), Lieutenant (junior grade)
        • OF-1: (second) Lieutenant (army), Ensign
  • [a/b/c (optional)] is an optional letter to be used if the rank level has more than one rank associated with it. practically every country has two or more OF-1 grade officers for example.
  • ext is the file extension (typically svg)

The scope of this proposal only extends to the ranks and insignia of the 28 countries since their membership to NATO and if the rank is mentioned in the NATO STANAG. Ranks outside the scope of this should be subject to a different discussion.

Why is this needed? The use of rank files becomes significantly difficult when there is no pattern in the file names where every uploader employs their own standard. This also makes equivalence difficult to asses. The confusion intensifies particularly with some countries. To give a few examples:

  • Naming for some countries is particularly difficult. For instance Greece has no "Greek Army" but instead has a "Helenic Army". Some countries refer to their "Army" as "Land Forces" or "Defence Force". Three letter ISO abbreviation avoids these problems.
  • As visible in above chart the ranks "Captain" and "Lieutenant" is insufficient to establish seniority. A navy Captain is a Senior officer while an Army Captain is a junior officer. Some countries (like the UK) only denote a First Lieutenant as a "Lieutenant"
  • A Belgium corporal ranks below a US corporal. A Belgium corporal is the equivalent of a US private first class.
  • Insignia alone is sometimes confusing.
    • British generals have no "star" association as far as their insignia is concerned.
    • A French two-star general is actually a brigadier general (one-star). French do not have a 1-star general.
    • Likewise a 5-star french general is a full general (four-star general)
    • A 5 star US general is the equivalent of a French 7-star general. French do not have a 6-star general.
    • A Croatian Brigadir is an OF-5 rank (Colonel) a British Brigadeer is an OF-6 rank (one-star general)
    • It is difficult to follow German rank seniority if one only relies on the insignia.

Examples (to demonstrate the mentioned issues):

I hope to make rank insignia more available through template use. Aside from comparison charts I am working on, I hope to make the ranks appear on for example info boxes. It is near-impossible to program a template that translates "give me the rank of level' for country" if there is no standard naming scheme.

This makes the files more machine readable but also elevates the human readability as well as confusion is reduced.

-- とある白い猫 ちぃ? 14:37, 7 April 2012 (UTC)

And nowhere in the name is the word "Insignia" or "Rank Insignia" ? Is there a reason why the country must be named with a TLA rather than its spelled-out name? Ah, I see that -- not sure I completely agree with that, but maybe. Also, you would have to allow for multiple versions of the same insignia -- artists could make separate versions of the same insignia, and we'd want them all. Does this scheme allow for historical insignia no longer in use? Dunno... such a naming scheme is really only readable by people very familiar with such codes, and looks like gobbledygook to others. If really needed for a template, wouldn't a file redirect work, pointing to the current "best" version of the corresponding insignia, itself named with a better spelled-out name? Which could use "Helenic Army" etc.? Carl Lindberg (talk) 15:08, 7 April 2012 (UTC)
Even if the reader is unfamiliar with the STANAG itself assessing that OF-5 ranks above OF-4 isn't really a stretch of imagination. It is confusing to me if the STANAG designation and branch isn't denoted in the filename. This is despite my familiarity with rank insignia of multiple countries in general.
Another reason why I have chosen to remove what the rank is called in the local language is that there are cases where this is problematic. Belgian and Canadian ranks are referred to in two languages for example. We cannot favor one over the other. Rank name is something more suitable for file description as the name of the rank can change at times. Also consider the case with Belgian corporal, where the word "corporal" would imply a higher grade than the rank equivalency.
A redirect can maybe be an acceptable compromise (technically) however file-names should still contain the STANAG equivalence and denote the branch of the service. My above concerns also makes me feel uneasy about the redirect option.
Naming convention can incorporate the words "Rank" and/or "Insignia" but I am trying to make the convention as international as possible. I do not have an objection beyond that.
-- とある白い猫 ちぃ? 15:28, 7 April 2012 (UTC)
 Oppose to such a complex and very incomplete naming encoding rule.
The so called standard for insignia is not a standard, it is a complex encoding rule for the first part of a file name, which can still exist in many variations (cropping, resolution, orientation, color variations, ...). It has several restrictions:
  • Many fields are Nato defined, which covers only part of the countries and regions of the world where the NATO is active
  • The rules and concatenation are some loose interpretation of the Nato standard, I know of no comprehensive documentation that documents it, a primary requirement for any standard of such type and complexity
  • The Nato only covers items of the Nato history, so the many thousands of items that are are outside the Nato time-line or activity area are not covered
  • It is not clear if it concerns a badge, an insignia, ... Moreover, it is not defined how the insignia should look like: portrait, landscape, cropped till n millimeters, resolution, ...
So even if the scheme had not the restrictions of the Nato as mentioned above, it would be far too complex and incomplete to be practical in a worldwide Commons context.
The nice thing of redirects as used by templates is that a better version, resolution, crop or coloring scheme can be selected without having to remove the original file first or to to overwrite the existing file with a better one. This should avoid many edit wars and discussions as for example the one around File:Army-FRA-OR-01_(alt).svg. --Foroa (talk) 18:08, 7 April 2012 (UTC)
  • As already explained, the scope of the convention is for NATO member nations only so for instance even countries such as Ireland, Austria and Finland would be outside of the scope. I do not have a reliable source to create equivalences for them.
  • NATO STANAG 2116 - edition 6 (25 February 2010) is the document you are looking for. This single document compares all NATO member nation ranks. It is not an interpretation of it at all. The +80 paged document talks about rank insignia from 5-star generals all the way down to nurses.
  • As already explained, the scope only considers countries after they joined NATO. For example Poland abolished a number of ranks before joining NATO to meet NATO STANAG 2116.
  • It is not that hard to achieve this: w:Template:Ranks and insignia of NATO/Generic/Army can give you a demonstration.
    • Alternate versions of rank insignia exists for practically every military depending on the type of the uniform all the way to the specialization.
    • The specific example you have linked clusters irrelevant variants together (I believe it has military band together with regular army insignia). For that reason I have moved and rotated it and updated every article using it. Its rotation back only created problems.
I'd be happy to try to address your concerns but I feel it would be easier for us to discuss one concern at a time.
-- とある白い猫 ちぃ? 18:42, 7 April 2012 (UTC)
Oppose; there is not one true SVG file for each of these images, and using cryptic filenames makes it a lot harder on users.--Prosfilaes (talk) 07:58, 8 April 2012 (UTC)

I think it is sufficient for each set to have its own consistent naming scheme (like I think most of these files had before they were moved around). I think trying to force multiple image sets with different styles and from different sources will only complicate things. This is similar to the book scans used for Wikiource which use consistent naming within a set/book, so that scans from the same book only differ in the page number, while different sets/books can use different naming schemes. But it is different from the BS icons which were created specifically to be a single set of files with a single style and the single purpose of railway templates, and has no or little use outside of that purpose. /Ö 19:36, 7 April 2012 (UTC)

What would this naming scheme be? It is very difficult to follow any set that does not have STANAG designaiton incorporated in them. -- とある白い猫 ちぃ? 19:40, 7 April 2012 (UTC)

 Comment this standardisation is intended to support templates, yes? Can you point to them? It would be easier to judge whether all this is worth it if we could see them. Because I'm wondering why you can't simply create a lookup table, so that eg {{insignia-lookup|Army-FRA-OR-01}} gives you File:lengthy and nonstandard filename bla bla.jpg. Also, as Carl Lindberg said, if this naming scheme is worth following, then creating new file redirects is probably preferable (or if it isn't, we should be clear why not). Rd232 (talk) 23:15, 7 April 2012 (UTC)

MediaWiki restricts on how complicated each template can be. Currently w:Template:Ranks and insignia of NATO/Generic/Army barely works because I removed a few checks. If I introduce them, half of the table will not render. Filename complexity makes checks difficult. I do not want to create 2500 if/else conditions
  • I can code to check if File:Army-FRA-OF-10.svg exists or not. If not, I can then check if File:Army-FRA-OF-10a.svg. If that doesn't exist the code can determine that the rank does not exist. If that rank exists then I would check for File:Army-FRA-OF-10b.svg, File:Army-FRA-OF-10c.svg to generate the needed errors or outputs. If the country has multiple ranks of same grade the input would be asked to provide the relevant letter.
  • What I want to be able to do is throw in {{insignia-lookup|FRA|Army|OF|10}} and get the insignia and its name if the rank exists. For instance an article on w:Martin Dempsey displays the 4 star rank insignia. If you check the code, Infobox military person uses a direct file link as well as a manual article link to the rank. I want to just toss in "OF-9" and it will pull the insignia and name.
What I want to do already has enough complexity as you can see.
I do not oppose the use of redirects but I would prefer file moves for the reasons discussed above. Filenames should still be moved in a manner that they incorporate STANAG designation, country name and branch of the military.
-- とある白い猫 ちぃ? 01:19, 8 April 2012 (UTC)
I still think redirects would be better in this case. They are easier to change if a "better" graphic for a particular insignia comes along, or if we need to repoint due to discovery of copyright violation, and that kind of thing. They could also be done locally on a wiki (or overridden) if their editors prefer a different graphic for a particular insignia, while keeping all of the versions available if needed. Renaming can be a bit aggressive too -- perhaps someone has a named series (or names in a native language or alphabet) -- you are basically "owning" these files for your template, and someone else's template, perhaps along different lines, may then not work. You are leaving a file redirect on the old name anyways; it seems easier to just make a redirect for this name style instead, without involving the admins. Carl Lindberg (talk) 13:04, 8 April 2012 (UTC)
This is a fair point, it would make the template more robust particularly during deletions and when the country changes the rank insignia. However, it is still difficult to follow the files as a human if they do not follow the STANAG equivalencies and also mention the branch of the military. Each set should incorporate these two elements somehow in their naming scheme. Some existing files do incorporate this.
How about a naming scheme (going back to your idea above) that contains the
  • Military branch
  • STANAG equivalence
  • Military's name (In local language perhaps?)
  • Name of the rank in the local language (both languages in the case of Canada and Belgium)
  • redirects to allow templates to operate
This is necessary because I do not want to rely on an 80 page STANAG document to try to establish how the ranks go together whenever I look at them. This would also line them up correctly in categories. If this standard is maintained on commons, I feel it would improve quality. We could apply the standard only to svg files since jpgs/pngs/gifs for rank insignia need to be phased out anyways. There only are 8 Army sets (Canada, Denmark, Germany (partially - NCO only), Italy, Netherlands, Spain, Portugal, UK (partially - officer only)) that would be affected all others would need to follow the naming scheme during upload.
-- とある白い猫 ちぃ? 13:42, 8 April 2012 (UTC)

OK, I'm going to  Support the scheme for file redirects to support relevant templates. Besides problems with moving files, I think the various points made by Prosfilaes, Foroa and Carl Lindberg all speak to creating new file redirects for this type of purpose, rather than renaming. I think this discussion has been quite helpful, and I would suggest this conclusion be proposed (at Commons talk:File renaming) for adoption in Commons:File renaming, to basically remove point 6 and replace it with a "create file redirects instead" footnote. Rd232 (talk) 00:38, 9 April 2012 (UTC)

It would be good to move this discussion to Commons talk:File renaming so that it can be archived there. I agree that using redirects is a good idea. --Tony Wills (talk) 11:42, 9 April 2012 (UTC)
I think creating redirects is often a better solution than moving files if specific names are needed for specific purposes. So I can also support that. Problems with the same file belonging to conflicting schemes will be avoided.
File names does not need to contain all information about files. Much information can be added in the file description (for example what the NATO code is for some rank). For groups of files galleries can be created with information about how the files relate to each other. /Ö 17:07, 10 April 2012 (UTC)
I feel it is as relevant to have the NATO code for a NATO rank as it is to specify the country and branch. Moreso for NCO ranks. -- とある白い猫 ちぃ? 16:17, 12 April 2012 (UTC)

The abovementioned photo has a wrong title. The photograph is about the victory in the Copa Interamericana. Is not just that the name of the competition was Copa Interamericana at time, is just another competition different from the Copa Libertadores. Since this file is used by a lot of chapters I wanted to write here down whether i can safely move it to its proper name. -- SERGIO (aka the Blackcat) 09:21, 4 June 2012 (UTC)

Renaming from cyrillic script?

The file Евровизия лого.png is used for creating other Eurovision Song Contest logos, but the file name is written in cyrillic script. Is it right to rename it to "Eurovision Song Contest logo" or is that against "Files should NOT be renamed only because the filename is not English and/or is not correctly capitalized (Remember, Commons is a multilingual project, so there's no reason to favor English over other languages)."? /abbedabbtalk 13:03, 3 June 2012 (UTC)

No. You could create a redirect for it though. --  Docu  at 13:11, 3 June 2012 (UTC)
What do you mean? "No it is not right" or "No, it doesn't go against any rules"? /abbedabbtalk 15:19, 3 June 2012 (UTC)
File names just need to be in UTF-8, there is no limitation to some scripts (see Commons:File naming), thus it shouldn't be renamed merely because it's not in English (or in Roman script). --  Docu  at 16:02, 3 June 2012 (UTC)
On an aside, if this is an official logo, surely it is copyright because the word "Eurovision" certainly passes the threshold of originallity. If it is, then renaming is irrelevant. Ww2censor (talk) 16:12, 3 June 2012 (UTC)
Official or not, {{PD-textlogo}} might apply. --  Docu  at 16:30, 3 June 2012 (UTC)
It wouldn't pass the U.S. threshold of originality, nor the German. Not positive what the country of origin would be there. Carl Lindberg (talk) 18:17, 3 June 2012 (UTC)
I agree, and I have tagged it as a copyvio.   — Jeff G. ツ 19:12, 12 June 2012 (UTC)
This seems contradictory. --  Docu  at 04:15, 13 June 2012 (UTC)
"12:49, 13 June 2012 (UTC) Mathonius (talk | contribs) deleted page File:Евровизия лого.png (Copyright violation: non-free logo) ( global usage ; delinker log)".   — Jeff G. ツ 11:41, 14 June 2012 (UTC)

Semantics

Are these polices, or simply guidelines? Is there a difference? DS (talk) 00:00, 9 June 2012 (UTC)

The top of the page says "guidelines". Policies are mandatory, while guidelines are optional, a pretty big difference. Stan Shebs (talk) 16:53, 9 June 2012 (UTC)
Further to what Stan wrote, you should really know the difference, which is the same here as on English Wikipedia.   — Jeff G. ツ 19:54, 12 June 2012 (UTC)

Require a numeric reason parameter #2 in the range 1-7 for Template:Rename

Template:Rename was changed at 18:00 (UTC) on 8 March 2012 (over three months ago) to use a numeric reason parameter in order to increase internationalization and ease of use. The numeric reason parameter is #2 and the text reason parameter moved to #3.[2] The documentation was changed 16 minutes later.[3] Valid numeric reasons range from 1-7. One user, DragonflySixtyseven (talk | contribs), is resisting the change, first using text for parameter #2 as before, then using an empty parameter #2, and finally using "0" without quotes for parameter #2, all despite documentation changes and pleas to comply with the change. This section seeks to establish a consensus to require a numeric reason parameter #2 in the range 1-7 for Template:Rename. Please !vote below. Thank you.   — Jeff G. ツ 19:30, 12 June 2012 (UTC)

This is blatant process masturbation. Go do something useful. DS (talk) 19:33, 12 June 2012 (UTC)
I would not use such language, but I am very frustrated by requests for votes that turn up everywhere on Commons nowadays (did I just not notice them before?), often before any deeper thought is put into the proposal.
On the subject matter, I am not happy with the change. I have a good grasp about the allowed reasons, but I cannot remember which number is for which reason, which mean I have to click preview, click the link, find the right reason, memorize the number and return to the page.
If this saves considerably amounts of time because of fewer mistakes, then I suppose I have to do this procedure. But the rationale, easier internationalisation, is beyond me: I think those moving files are mostly fluent in English and would understand the rationale without a translation. Regardless, one usually need to understand the old and proposed name, the verbal problem description or the file description to be able to judge the validity of the request.
--LPfi (talk) 20:57, 12 June 2012 (UTC)
As far as I know there was no discussion about adding the numeric parameter before it was introduced. I see it as having no real advantage and should just be an optional parameter for those who want to work that way. At present it is just an added pain when requesting renames, which is perhaps useful in that it may discourage people requesting unnecessary renames ;-) --Tony Wills (talk) 21:21, 12 June 2012 (UTC)
Currently using the number 0 would override the number codes. I feel number codes could be a worthwhile endeavor but I am not sure if it is a good idea to force people to use it. We could create a section on the policy page that lists reasons why using numbers are worthwhile to recommend (not require) their use. Would that be a problem for anyone? -- とある白い猫 ちぃ? 21:57, 12 June 2012 (UTC)
Functionally my preference would be to have two parameters, the first is the requested new name, the second is the reason for the rename. If that second parameter is a single digit, then substitute the appropriate rename justification, otherwise treat it as the text of the justification. --121.73.5.55 00:00, 13 June 2012 (UTC)
You wouldn't want to allow an optional text reason appended to a numeric reason?   — Jeff G. ツ 13:12, 16 June 2012 (UTC)
I have a problem with that. Without a numeric reason, a filemover who only reads language A cannot understand the reason if the rename requester only writes in language B, or provides an unintelligible reason text. Also, based on past experience with DS's rename requests, they are much more work due to invalid and unviewable reasons, and therefore much more risky for me as a filemover, or any other filemover.   — Jeff G. ツ 14:33, 16 June 2012 (UTC)
The important thing is the written explanation of why the file should be moved. If someone does not understand that explanation for the move and how it satisfies the file renaming guidelines, then the move shoud be left to someone else. I don't oppose an optional numeric parameter, but I think it is enough with a text parameter since the written explanation should make it clear which file moving rules are relevant. /Ö 20:30, 16 June 2012 (UTC)
Please feel free to bookmark or transclude {{File renaming reasons/en}} (or your preferred language) with your other reference materials.   — Jeff G. ツ 14:42, 16 June 2012 (UTC)
A legitimate question was raised about consensus for the change. This section seeks to establish such consensus for what has been working for the rest of us for over three months.   — Jeff G. ツ 14:48, 16 June 2012 (UTC)
There was no discussion, and no consensus. The change was not necessary, and not requested. I tend to disagree with most of User:DragonflySixtyseven's rename requests as unnecessary, so his reasons for opposing this change are not mine ;-). I suggest any difficulty in handling DS's requests is because of the messed up template. I certainly had no problem previously.
If filemovers can't understand the rationale (because of language differences) then leave it for someone else, I would expect that in many cases of language differences we are talking about the filename too being in a different language - if you can not understand the existing and proposed filename, you can not sensibly move the file whatever the nominated reason. Having a number isn't actually much help, people just choose a rationale that is vaguely related to their reason, using a number just saves them from actually articulating a reason. So have numeric and text parameters - allow people to include either or both. The rename request is a hint to file movers, giving them an argument as to why it would be worth moving the file. --Tony Wills (talk) 23:54, 21 June 2012 (UTC)

Filenames with invisible characters

I noticed that a lot of filenames (in particular among the images from the Geograph British Isles project) contain the invisibile control character (U+0092) instead an apostrophe. For example: File:St Ethelreda’s Church Horley Oxfordshire - geograph.org.uk - 1771691.jpg has got an invisible character in Ethelreda’s between a and s. Here is the complete list of the affected files on Commons. The invisible character creates confusion (example) and it's almost impossible to create a link or to use the image without cut&pasting the filename. I suggest to mass move these files replacing the invisible character with the apostrophe '. What do you think? -- Basilicofresco (msg) 18:37, 16 June 2012 (UTC)

The character U+0092 is not a valid Unicode character, but 0x92 is the "’" character in the Windows-1252 encoding. Many web servers serve pages in the latter encoding claiming Latin-1 (where this block is control codes) - and so did many Wikipedias before transition to UTF-8. Using invalid characters is bad and I think renaming is safe, but check Unicode documents to get the right character (it might be used in other contexts). And do change all such invalid characters in the filename in the same run. --LPfi (talk) 22:01, 16 June 2012 (UTC)

You are right, I updated the list in order to include every character in this forbidden range: filenames that contain one or more characters between U+0080 and U+009F. They are about 2200 images, what is the procedure in these cases? I could add with my bot to each page the proper {{Rename}} template with the corrected filename and a detailed reason. I could also ask the filemover flag for my bot and perform directly the mass moving. What do you suggest? -- Basilicofresco (msg) 21:52, 20 June 2012 (UTC)

Hi Basilicofresco, just to let you know I changed the name of this file on your list because I use it in an article. Lotje ʘ‿ʘ (talk) 11:03, 21 June 2012 (UTC)
This might be better discusssed and done at COM:BWR. --Foroa (talk) 12:19, 21 June 2012 (UTC)
✓ Done Lotje ʘ‿ʘ (talk) 13:31, 21 June 2012 (UTC)

You are right, this is probably not the best place (I was looking for the relevant process). Now I asked in Commons:Village pump/Proposals in order to better evaluate the consensus and receive suggestions. I'm able and ready to perform the task, so I think I will ask in COM:BWR only if will not be considered appropriate to give the filemover flag to User:FrescoBot. -- Basilicofresco (msg) 06:22, 23 June 2012 (UTC)

Policy on very short filenames


Renaming of non-Roman script names

I get that Commons is a multilingual project. But should files, pages, categories, etc. using non-Roman script, maybe Devanagari or Nastaliq or others be moved to some Roman equivalent? Most of the keyboards do not facilitate use of these scripts and hence searching these files is difficult.
I am not well-versed with Commons yet. So if this has been discussed previously, which is probably done, you may point me to that discussion. I come here after having come across these two files using Devanagari script. File:के. क्षीरसागर.jpg and File:धर्मानंद दामोदर कोसंबी.jpg. I tried placing a move request on them but then read the Commons:FR#Which_files_should_not_be_renamed.3F Point 2. It speaks about the language but not about any script. A number 8 reason in "Which files should be renamed?" may be added for non-Roman names. §§AnimeshKulkarni (talk) 09:30, 9 August 2012 (UTC)

AFAIK such filenames are acceptable, even though many people can only use the files by copy-pasting the title, and the title won't mean mean anything to them when seen in categories. As for searching - that's what the file description page is for, to provide description in different languages. Rd232 (talk) 10:23, 9 August 2012 (UTC)
Wouldn't it be just easier if Roman script was used? Not all files have description or are categorized. §§AnimeshKulkarni (talk) 15:19, 9 August 2012 (UTC)
I understand Commons policy on this, but the problem is that some of these files don't have descriptions, so often when I see Malayalam file names (which is quite common here as we have a lot of image contributors from ml.wiki) it becomes difficult for me to figure out where they can be used. I can read a few Indic languages, but now with the increased no of Indic script names it is becoming difficult. Perhaps a bot to go around and updating a "description required" template on these files and also identifying the language would be helpful? —SpacemanSpiff 15:27, 9 August 2012 (UTC)
A hidden category could also be useful. Preferably with language's/script's name like Category:Files with Marathi names or Category:Files with Devanagari names; whatever is possible. §§AnimeshKulkarni (talk) 15:39, 9 August 2012 (UTC)
That sounds sensible. In a perfect world, we'd have some way to automatically identify files with no description and filenames most editors can't read, so we can make a point of automatically asking the uploader to provide more info soon after upload. Failing that, some kind of "what is this exactly??" marker template would do (we may have one hidden somewhere already, I'll have a look). Rd232 (talk) 17:08, 9 August 2012 (UTC)

How does {{Description insufficient}} look? Rd232 (talk) 18:52, 9 August 2012 (UTC)

That should work. Will some bot be employed to do dig out all similar files? Do we have to make subcategories, like you did for Marathi? Or else we won't notice red link categories. Or can we track those down too? §§AnimeshKulkarni (talk) 20:23, 9 August 2012 (UTC)
I don't see how a bot is even possible; but even if it is, bot skills are in very short supply! The subcategories can be created as needed (I've added a note to the template doc); if need be, What Links Here can be used on the template to check people haven't ignored those instructions. I don't think it makes sense to create hundreds of categories that may never be used... Rd232 (talk) 21:54, 9 August 2012 (UTC)
This is kind of what I had in mind. I'm not good with template syntax and other tech stuff, but could this be customized to something like Riilke's license review script (you can see the link on my monobook) wherein a drop down is provided for the list of languages. The reason I ask is because, the language parameter is not something most people use on a regular basis, so Marathi could be keyed in as "mr", "ma", "marathi" etc by different people. Once a cat is populated enough I'm sure a few of us from here would definitely send the cats to Indic language contributors to fix. As far as the bot, I was basically thinking of something that looks at the title (non-latin script) and checks for an English description and if it doesn't exist, places it in a master cat, which can then be recatted to the appropriate language cat. cheers. —SpacemanSpiff 03:39, 10 August 2012 (UTC)
I'm not comfortable with that template actually. I worry that it will be considered imperialistic/unwelcoming/intolerant by those who do not speak English, and thus cannot translate the description of their own files. For example, if this were shoved en-mass on all a French speaker's (well described in French and German) pictures of France, I can imagine him/her getting pretty annoyed. All we really need from the uploader is a good description in one language. Eventually that can be translated into more widely understood languages, but I don't think it's right to require that capability of the uploader. --99of9 (talk) 04:01, 10 August 2012 (UTC)
The ones who work on non-latin script images are who want this. We're not asking for the uploader to add English or any other descriptions, but we need to be able to categorize individual languages and have a common language description. There are so many indic-Wikipedias now and the few of us editors who work on them can not read all the languages, but have the ability to use the same images in other languages. If that's a bad goal, then that's fine, we can knock off one task from our list. —SpacemanSpiff 06:26, 10 August 2012 (UTC)
Agree with 99of9 that its bit too much to expect that everyone can provide descriptions in english, I suggest that the template says "we have been unsuccesful at translating this description please identify the language by way of adding a national flag, provide a translation into any of these languages en,de,fr,sp or place the image on the talk page of the subject on any language Wikipedia" any of which would help someone identify the language and seek out a translator the last option would also serve to let people who are familiar with the subject knwo that new images are avaiable. Gnangarra 09:44, 10 August 2012 (UTC)
Wow! So instead of directly writing something anything in English you want users to insert some flag (they have to go and search it) and then find some appropriate article in sister projects and put that image there. And that image should remain there till one of the editor from here reaches this image. If the image is of low quality, unnecessary as other images are available, etc. the image will be removed from that article instantly (depending on which article and which wikiproject it is). And you want those uploaders to keep doing this, instead of writing anything in English. And they dont have to write it in English!! If a category exists, other regular editors can keep clearing images from it.
In case you find the language of template is very harsh or discouraging, suggest changes to that. But don't put more tedious responsibilities on uploaders. They won't bother themselves with that. §§AnimeshKulkarni (talk) 10:02, 10 August 2012 (UTC)
I did suggest a change to template as not everyone can read and write english all i did was suggest more flexible response options that enables every contributor a way to respond to the request. As for friendly edits I suggest you practice that yourself. Gnangarra 11:28, 10 August 2012 (UTC)
Animesh, a simpler solution is to just ignore the image. I already do it for Malayalam, Bengali and Gujarati file names that I come come across, no reason to change that if consensus here is that we shouldn't try to get these translated or highlighted for translation. —SpacemanSpiff 10:11, 10 August 2012 (UTC)
I suppose no one has brought the concept of friendly edits in Commons.
@99of9 and @Gnangarra, the system works! I tagged this image File:மாம்பூக்கள்.JPG today for English description as it had only in Tamil. User:தகவலுழவன் not only added English description but also added appropriate categories and moved the file to a better name. §§AnimeshKulkarni (talk) 10:41, 10 August 2012 (UTC)

 Comment I was uncertain how exactly to word the template. (i) English is Commons' lingua franca, and ideally all files should have a description in English. At the very least, English speakers should be able to identify the subject (who is the person? etc) (ii) many files are only described in some other commonly-spoken-on-Commons language (eg French, German, Spanish), and such Latin alphabet descriptions are often enough for English speakers to at least identify the subject. (iii) but we want to encourage good description in as many languages as possible - including English, major languages and any languages relevant to the subject. So I tried to word the template to convey this, but I'm open to suggestions. Rd232 (talk) 12:04, 10 August 2012 (UTC)

I did some rewording, asking for a description in "some major language" and in English "if possible". It seems the template is meant to be read by the uploader and I think we cannot (and should not) require knowledge in English. I did not define "major language", but I think a reasonable definition could be "a language you find major, which has enough contributors that you can expect to get help by placing a note on the Village pump or Embassy page". --LPfi (talk) 19:44, 15 August 2012 (UTC)
That's right. Mandarin, Arabic and Hindi languages outnumber by far English. --Foroa (talk) 19:58, 15 August 2012 (UTC)
Thanks. Rd232 (talk) 20:36, 15 August 2012 (UTC)

Replacement is done under user account

To your attention: COM:AN#Replacement is done under user account -- Rillke(q?) 19:28, 27 November 2012 (UTC)

Renaming to a language

  • Files should NOT be renamed only because the filename is not English and/or is not correctly capitalized (Remember, Commons is a multilingual project, so there's no reason to favor English over other languages).

Does the above also mean that a file should NOT be renamed because the filename is English? Hyacinth (talk) 00:11, 2 December 2012 (UTC)

Presumably. – Philosopher Let us reason together. 00:27, 2 December 2012 (UTC)

Redirects

Please see the section that talks about redirects. I hope these problems are fixed. I am confused by the difference between the "move" and "move and replace" options when changing a file name. I have only moved a few images since I got the filemover tool.

I did not even notice the "move and replace" option in my menus. I have gadgets set up by my preferences that add drop-down menus and items to those menus. So the "move and replace" option is not next to "move" in the menu.

I read some of the Bugzilla threads. I voted for them all too. I hope we end up with just a "move" option. The simpler things are made, the better things will be for everybody. --Timeshifter (talk) 17:08, 19 December 2012 (UTC)

The problems are unfortunately not fixed but you are invited to join the discussion at COM:AN#File moving: "Move & Replace" vs. "Move". If a file was not in use before it was moved, there is no issue. Thank you. -- Rillke(q?) 18:28, 19 December 2012 (UTC)
Thanks. I commented at that discussion too.
Does the purge happen naturally in a few days? Or does the problem remain until someone actually edits the page with the file?--Timeshifter (talk) 03:27, 20 December 2012 (UTC)
It doesn't happen automatically AFAIK but in Wikipedia there are so many templates and local images (file-updates and moves purge local pages where the file was in use) and if any of them included in the article is changed, a purge is queued in the job-table. -- Rillke(q?) 08:56, 20 December 2012 (UTC)