Template talk:Information/Archive 2

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

Autotranslation

My plan is to convert this template in a autotranslated template quite soon. See {{Information/autotranslate}} for the code. Multichill (talk) 23:45, 26 December 2008 (UTC)

✓ Done. Multichill (talk) 14:18, 2 January 2009 (UTC)
Can you put back in the table code for the other versions? The old version supported multiple other versions, the new one does not. See File:Ontariowindfarmshourlyoutputover5days.gif which has two other versions. Delphi234 (talk) 21:04, 25 January 2009 (UTC)
You can use galleries or normal file notation to provide several files under other versions. I am not aware of any old versions that supported multiple other versions. --Slomox (talk) 21:45, 25 January 2009 (UTC)

I need a template created on 'Alan Beckwith' so that a photo image of the actor can be uploaded in Wikipedia http://en.wikipedia.org/wiki/Alan_Beckwith 14.36, 19 March 2009 (UTC)

Own work

I propose to change {{ #if: {{{source|}}} | {{{source|}}} | {{Source missing}} }} in Template:Information/layout to {{ #switch: {{{source|}}} |own work= {{{own work|}}} |={{Source missing}} |#default= {{{source|}}} }}. That means, if the parameter "source" says "own work" the words "own work" localized in the user language will be displayed (and else the behaviour is the same as before). "Own work" is the most common value for the "source" parameter and this will add much to the localization. After that we could use a bot to change the most common synonyms of "own work" like "self-made" or "selbst erstellt" to "on work". What do you think? --Slomox (talk) 02:41, 12 January 2009 (UTC)

I think this is a good idea. Giggy (talk) 05:26, 12 January 2009 (UTC)
Before I implement it, I'd like to ask another question. If we use a switch, we have the possibility to add even more values. For example, when I made a search for common synonyms of "own work", I came across "Scanned by myself", which is of course no synonym to "own work" (cause the original text is not created by you). It would be possible to give a warning about "unsufficient source information" if the source parameter says "Scanned by myself". I guess, "Scanned by myself" is not common enough to deserve a special warning, but perhaps you have ideas about other typical cases, that should be cared about. --Slomox (talk) 12:49, 16 January 2009 (UTC)
I'm not sure if i like this option. This template is pretty clean at the moment and this might make the template more difficult for users to understand. Multichill (talk) 13:23, 16 January 2009 (UTC)
The idea of additional parameters or the idea to standardize on "own work" and localize? At Commons talk:WikiProject Templates#Collecting I collected almost 200 different ways of saying "own work" in different words and different languages. They are all used on Commons. And I guess there are several hundred more ways hidden in the bulk of files on Commons. If you know English, you are well off. If you don't you are not. At the moment there are 1,390,755 files in Category:Self-published work. Almost 1,4 million files where an "own work" statement in the source section would be valid. I have absolutely no idea how many of our files use the information template and how many do not have additional source information, but if we could improve the localisation of, let's say 100,000 files, is that not a big step forward? I think, the understandability of the rendered text is more important than the understandability of the template. --Slomox (talk) 14:25, 16 January 2009 (UTC)
I would rather create a template {{Own work}} (now unrelated template) and use this than put everything in information. Multichill (talk) 15:54, 16 January 2009 (UTC)
Personally I like the switch better ("own work" is already now the most common value for the source parameter and the change would immediately take effect in thousands of images, whereas the template has to start from zero and be introduced by a bot), but I have no strong preference against using a template. {{Own work}} is taken, but there are already {{Own}} and {{Self-Made}} for the same purpose (both notoriously not used). I will start building an autotranslated template from {{Own}}. (If consensus for using a switch will crop up, we can still use the template in the switch ;-) ) --Slomox (talk) 17:46, 16 January 2009 (UTC)
Autotranslate for {{Own}} might be overkill. Take a look at http://commons.wikimedia.org/w/index.php?oldid=17710797 . Multichill (talk) 18:44, 16 January 2009 (UTC)

Adding hCalendar microformat

Having examined this and other templates, following discussion at Template talk:Places by decade#Microformats, it seems to me that the best way to apply an hCalendar microformat (see the Microformats Project for background) to each image page, would be to use this template. It will require a small number of changes, chiefly adding class="vevent" to the whole table, and classes summary and description to suitable fields; then applying the class dtstart to the date of the image (not the date of the upload) using a sub-template like "Start date" on Wikipedia-en. Before I finalise the code, does anyone have any questions or concerns? Or alternative suggestions for the date? (there's some previous discussion from 2007; and Event start time). Andy Mabbett (talk) 01:09, 25 January 2009 (UTC)

There are plans to localize the date to local format by using {{Date}}. --Slomox (talk) 10:03, 25 January 2009 (UTC)
Thank you. I'll have a look at that. Andy Mabbett (talk)
I have now added mark-up, hidden by CSS, which emits the ISO-format date, wrapped in the relevant class. Some tweaking is needed; please see Template talk:Date#Use in hCalendar microformat. Andy Mabbett (talk) 11:41, 3 February 2009 (UTC)

Adding 'description' class

{{Editprotected}} As a preliminary to the above, please change: 

| description = {{{description|}}}{{{Description|}}}

to: 

| description = <span class="description">{{{description|}}}{{{Description|}}}</span>

Thank you. Andy Mabbett (talk) 11:50, 3 February 2009 (UTC)

✓ Done. Thank you. Andy Mabbett (talk) 23:05, 7 February 2009 (UTC)

Clash of classes

The above change had to be reverted, as the class "description" is also used by {{Description}}, causing data to be lost from the hCalendar microformat when {{Description}} is nested inside the "description" parameter of {{Information}}. There are two possible solutions: 1) Leave things as they are. Omit the optional description property from the microformat. This has the disadvantage that the most useful information will not be available to parsers. 2) Rename the class in {{Description}} (perhaps to "descriptor") and in any CSS which styles it; once done, restore the above edit. Can anyone see any problems with the latter course of action? Andy Mabbett (talk) 19:55, 8 February 2009 (UTC)

You have to ask this on a more widely-read page. Post the question at Commons:Village pump and leave a note on Template talk:Description. There could be some CSS and Javascript dependencies. This shouldn't be done without being very careful. --Slomox (talk) 20:35, 8 February 2009 (UTC)
I have already posted pointers to this page (centralising here, because the previous discussion is here) on both of those pages. Andy Mabbett (talk) 21:05, 8 February 2009 (UTC)

Adding 'summary'

The next stage of making this template emit an hCalendar microformat is to mark up something as a "summary"; which is effectively the name of the event. Since the event is the making of the image, it seems reasonable to use the file name for that (the description field is far too verbose for such use). Would anyone have any objection to repeating the file name in the template? Or does anyone have an alternative proposal? Andy Mabbett (talk) 11:55, 3 February 2009 (UTC)

The above could, perhaps, be achieved by adding a new row to, say, the bottom of the table: 

|- valign="top"
! style="background: #ccf; text-align: right; padding-right: 0.4em" id="fileinfotpl_perm" | File name:
|<span class="summary">{{{pagename}}}</span>

if a "Pagename" magic-word is available. Andy Mabbett (talk) 20:10, 3 February 2009 (UTC)

{{PAGENAME}} => Information/Archive 2. {{FULLPAGENAME}} => Template talk:Information/Archive 2.
But why make it visible? Why not hide it? Making it visible willl hardly find many friends. --Slomox (talk) 20:43, 3 February 2009 (UTC)
That's an option; would you like to suggest some code please? Does anyone else have a view? Andy Mabbett (talk) 21:01, 3 February 2009 (UTC)
Just <span class="summary" style="display:none">{{PAGENAME}}</span>. As it's not visible, the position in the template doesn't matter much. --Slomox (talk) 22:31, 3 February 2009 (UTC)
OK; I suggest we go with that - it can always be changed later if people want that. Does that get added to the parent template, or one of the sub-templates, or doesn't that matter? I'm away from my PC for a while, please add {{Editprotected}} to your reply - or make the edit. Thanks.) Andy Mabbett (talk) 23:11, 3 February 2009 (UTC)
Does this need to go into "vevent"? --Slomox (talk) 18:38, 7 February 2009 (UTC)
Eventually. I'm building and testing the microformat "from the inside out" (see the above edit request, to add class="description", for instance); and will make a request to add class="vevent" to the relevant sub-template, as the last step, thereby enabling the microformat. Andy Mabbett (talk) 20:34, 7 February 2009 (UTC)
What else is needed? This template is used in almost 3 million pages and every edit forces all pages which are stored in cache to be rerendered. If we want to edit it, we shouldn't do it step by step, but in one single edit. --Slomox (talk) 20:47, 7 February 2009 (UTC)

←Fair enough. It just needs the addition of four things:

  • class="description" as discussed in the previous section
  • class="summary" as discussed in this section
  • class="vevent" in the wrapper for the whole template, possibly via changing class="toccolours" to class="toccolours vevent" in {{Information/layout}} (note - this has not been tested.
  • Category:Templates generating hCalendars.

This related request: Template talk:Creator#Code rationalisation could be done afterwards (instead of first), to no ill effect; we then need to arrange a bot run to use {{Date}} instead of prose-only dates, where appropriate. Andy Mabbett (talk) 21:07, 7 February 2009 (UTC)

Thank you. Andy Mabbett (talk) 21:07, 7 February 2009 (UTC)

✓ Done. Thank you. Andy Mabbett (talk) 23:05, 7 February 2009 (UTC)

Adding hCard microformat

…and the best way to add hCard microformats is to have sub-templates for event "attendees" such as human subjects and (the already existing) photographer and creator and for the location. Andy Mabbett (talk) 21:53, 2 February 2009 (UTC)

Possible refinements

Make hCalendar conditional

At some point, it would be good to make the class "vevent" conditional on their being a value in the "date" field. Something like (pseudocode):

If date has a value, then class="toccolours vevent", else class="toccolours"

Thoughts? Andy Mabbett (talk) 23:09, 7 February 2009 (UTC)

Location template

Could we make it possible for a bot to move {{Location}} inside {{Information}} as in this edit? Then the coordinates would be included within the hCalendar. Andy Mabbett (talk) 00:36, 8 February 2009 (UTC)

Look at the design of the location template. It's supposed to be below information and not in the description. But Template:Information2 might be interesting to you. It uses the "other_fields" parameter to provide the location.
Providing location is a very old problem. There are at least 13 different templates to provide location information in different styles and different places. Unifying all these templates and providing location information in a uniform style would be a great improvement. But it will be a heavy fight to make this happen. --Slomox (talk) 20:30, 8 February 2009 (UTC)

Broken Description

When I added an EN description to this file; it shows in a horrible BOLD, and larger font??? - Mjquin id (talk) 00:02, 28 January 2009 (UTC)

Well, that's cause you checked "MyLangNotify: Emphasizes your language description, or asks you to add one if it is missing." in your preferences under 'Gadgets'. --Slomox (talk) 00:23, 28 January 2009 (UTC)

Date

I'd like to replace "{{{date|}}}" with "{{ISOdate|{{{date|}}}}}" in Template:Information/layout. That would render dates in ISO 8601 format as e.g. "1 February 2009" in English, as "1. Februar 2009" in German or in the preferred local format of the language the user has specified in his language (as soon as that format is implemented in Template:Date). If the parameter "date" is not in ISO format, the string will be displayed normally. Any objections? --Slomox (talk) 01:06, 1 February 2009 (UTC)

Done. --Slomox (talk) 01:13, 3 February 2009 (UTC)
I also added {{Parse source}}. Multichill (talk) 17:31, 6 February 2009 (UTC)

Proposing subject matter date.

I notice you guys have added vevent to this infobox. Is there an overall plan for what you are doing with microformats and this template? If so, have you documented it anywhere? For example, is the idea here to emit the date parameter as the date of an event? That would be a little problematic, because in huge numbers of cases the date has nothing to do with the subject of the work, but the work itself: when the photo of the statue or coin was taken, or the date the painting was created- not the approximate date of the person depicted by the statue, the date the coin was cast, or the date of the battle scene depicted by the painting. To address this problem, how about something like: "subject matter date"? -J JMesserly (talk) 02:33, 12 February 2009 (UTC)

Error with the template

What's the purpose of the code that says "Do not remove the following code. It is included for machine readability"? Look at File:World homosexuality laws.svg. I guess it hits the size limit of the title attribute (34392 characters). --Slomox (talk) 16:59, 19 March 2009 (UTC)

With some googling I could not find any evidence for a attribute size limit for HTML or XML. Perhaps it's a browser issue. I'm using Firefox. --Slomox (talk) 17:04, 19 March 2009 (UTC)
It's not a browser issue. All browsers have the problem. And I now realized, that it's broken in the source. So perhaps it's a parser size limit? --Slomox (talk) 17:08, 19 March 2009 (UTC)
I tried to find the limit and it's at 33298 characters. That's weird, I would have assumed it's at 32768. Where does the difference of 530 come from? --Slomox (talk) 11:59, 20 March 2009 (UTC)
But the limit is not fixed. In another file it was 33305 characters... --Slomox (talk) 12:06, 20 March 2009 (UTC)
I removed the code. I asked here, I asked Bryan who added the code, and I asked at Wikitech-l and nobody came up with an actual example how this code is useful. --Slomox (talk) 14:09, 30 March 2009 (UTC)

Reusing this image → Reusing this file

In next time the template changed, I suggest replacing 'Reusing this image' → 'Reusing this file' as it's better if it's generalized. --OsamaK 08:01, 20 March 2009 (UTC)

I agree, and I suggest the same. --Purodha Blissenbach (talk) 21:27, 27 April 2009 (UTC)

Clarify date

{{editprotected}}

The Template Documentation has this table row under the Parameters section:

Date date, in ISO 8601 format ("YYYY-MM-DD", or "YYYY-MM", or "YYYY") or using

I wish to extend that description to include what the date should mean (copied from Commons:First steps/Quality and description):

"Date of creation (or date of release), preferably in ISO 8601 format, such as 2006-01-15 for 15 January 2006."

The reason is this might better help the reader and uploader know what "date" means (even if it is still ambiguous). I see some Information templates are filled in with Dates that sometimes mean date when the painting in the photograph was created, or when a photograph was uploaded to Flckr, or when a photograph was scanned, or even when a photograph was taken. Ideally, the Date parameter should have only one meaning, and I would like to next improve the main description.

But.

I cannot give precise instructions as to how to make this or any similar edit because the documentation template transcluding defeats my understanding. Template:Information transcludes Template:documentation which starts with "This documentation is transcluded from Template:Information/doc. (view | edit | history)" (I added the wikilink). Now, when one edits that, one sees "{{TemplateBox" followed by numbered and named template parameters. In turn Template:TemplateBox (which confusingly claims "The template takes no parameters") appears to contain template magic to produce a table of parameters. It seems I need usage instructions on how to use the template that creates the usage instructions of another template! Or maybe I need more coffee.

Can I leave this to a template-expert? 84user (talk) 10:55, 21 April 2009 (UTC)

which confusingly claims "The template takes no parameters" That text is not part of the documentation, but of the "empty" template. The documentation begins with the section with grey background. But you are right, that this can be confusing. I added a includeonly clause to that template.
I added "date of creation" and "such as 2006-01-15 for 15 January 2006" to the documentation. I left out "or date of release" cause it is my impression, that release dates should not be given in the date parameter. The date parameter should always be the date of creation. The date of release for most uploads is the upload date, which is already present on the page and doesn't need to be stored redundantly. If the first release date is different from the upload date, the first release date should better go in the source parameter (together with the place of the first release). --Slomox (talk) 12:02, 21 April 2009 (UTC)
Does anyone have objection to adding optional parameter Topic-date? This would make explicit the date that the subject matter of the painting or map corresponds to. EG: a painting of the storming of the Bastille would have the date of the storming of the bastille, not the date the painting was created, or the date the person took the picture in the museum, or the date the image was uploaded. The topic date is useful for passing via KML to applications like Google Earth that understand not just location but date. It is also useful for other metadata information like microformats. -J JMesserly (talk) 19:33, 21 April 2009 (UTC)
Yes, I have objections. That's just semantic junk (please forgive me the word junk, I don't know a better English word for unnecessary and borderline-useful stuff). We should keep the information template easy and clean. --Slomox (talk) 20:34, 21 April 2009 (UTC)
That belongs in the description field since it has to do with the subject of the image and not the image itself. If you think it would be beneficial to have a separate field for it so it can be used by software, maybe create a new template for it (like as done with geocoding). This also has very little relevance for the majority of images here. Rocket000 (talk) 23:03, 21 April 2009 (UTC)
Ok. That's fine. I shall create a "topic/ subject matter" declaration template that has a topic lat/longitutude, and a topic date. Example application: Say Commons has a painting of Wellington at Waterloo. The photo of the painting gives an EXIF timestamp and lat/longitude for the National Gallery of London where the painting hangs. In google earth or Live Search, we don't want the Commons icon for the painting showing up in London, with a date of 2008 when the photo was taken/uploaded. So, for an english KML layer, the pearl script scrapes the wikitext for the the en template description from the info template, the lat/lon and timestamp from this new "topic/ subject matter" declaration template. As a practical matter, the pearl script isn't parsing template nesting, and is just scanning for unique parameter names, so it doesn't really matter if these parameters aren't encapsulated in the same template. The idea is this topic template would be used if the date and or lat/longitude of from the information and location templates did not correspond to the content. Perhaps sometime later this could be engineered in a less ad hoc manner so that these fields aren't in separate non overlapping containers. As for now, if you guys don't see why the fields make sense to be in {{information}}, then hey- I won't argue with you. It actually makes things a lot simpler for me.
BTW- Google is expanding its tools to visualize time, eg its timelines application as well as google earth google earth historical imagery (to date not yet filtering kml overlays for time period- just the aerial map). The other virtual earths like live search will undoubtedly follow suit. There are quite a few historic images that will need proper topic dates associated with them if our content is to appear anything more than a nonsensical mess in these applications. -J JMesserly (talk) 06:37, 22 April 2009 (UTC)
The date connected with the National Gallery painting depends on the motif. If our image _only_ depicts the painting, our image description page should contain the template {{Painting}} with the creation date of the painting (the creation date of the image will only be present in the EXIF data or not present at all). The page should _only_ contain the template {{Information}} with the image creation date, if the motif of the image is more than the painting (e.g. a whole wall of the National Gallery).
Topic dates are information mud in my eyes. --Slomox (talk) 13:09, 22 April 2009 (UTC)
There's something I never used in this template (and am unsure of it's exact purpose): {{{other_fields|}}}. Could that possibly be utilized here? Rocket000 (talk) 17:00, 22 April 2009 (UTC)
Foundation wikis use Commons Media to illustrate topics. Being a good resource is the core mission of Commons. It is pertinent to know what time period the depicted artifact was carbon dated as, what time span a map depiction of the extent of an empire was valid for, and what location and date correspond to a depicted event in a painting, tapestry, frieze, or other work. But as I said, I'm not trying to convince anyone that it should be included in {{information}} and am completely content to code this date in an external template. Those interested in the Information template might focus on the reality of the date field they do support: that it can and is being used for so many different things that it is virtually useless, junk data. This was the problem the initiator of this thread pointed out, and it ought to be returned to. It was not my intention to hijack the thread. -J JMesserly (talk) 18:53, 22 April 2009 (UTC)

Question about "source"

Hello. I'm a little bit confused how to use "source" field when files have been transfered from other wikis. Is the source field supposed to indicate how to file entered Commons, i.e. should the source field say "Danish Wikipedia"? Or is it supposed to say how the file originated, i.e. from the CCD chip of someones camera (own photo) or scanner (scan of page xx in book y) or vector graphics editor (created with)? One more question: what exactly does {{Own}} mean: 1) that the author of the depicted artworks is the same person as the creator of the file? or 2) that the one who puts the template is the creator of the file? Nillerdk (talk) 07:18, 24 April 2009 (UTC)

2) wouldn't work, cause the person who puts the template isn't known to the reader of the page. I'm not sure about 1): Whom do you mean by author of the depicted artworks? If you take a picture of a copyrighted monument (in a country with FOP) you can still write {{Own}}. {{Own}} means the author mentioned in the parameter "author". And "author" means the person who has taken the photo (except for reproductions of two-dimensional works). The creator of the monument should be named in the "description" parameter.
Whether your camera has a CCD chip, another sort of chip or no chip at all, is not relevant for the source tag. If you have taken the picture, you write {{Own}}.
About the "moved from another wiki" issue I'm not sure myself. A correctly transferred image should contain a "original upload history" section. That section should also contain information about which wiki the file was originally from. So this information does not necessarily need to be in the "source" parameter. It is still often done. We still have no standardized way of handling "moved from local wiki" uploads. In the end it all depends on personal preferences. --Slomox (talk) 13:50, 24 April 2009 (UTC)

Question about "author" when multiple

Consider I take a photo of a copyrighted statue and get explicit permission from the artist to release that photo as cc-by-sa. There would clearly be two authors of the file: I would be one as the photographer and the artist would be one as the creator of the statue. What do I enter in the "author" field? This also applied in all the cases where 2d and 3d art in public domain (because of aging) is scanned or photographed because the original auther never looses his right to be properly attributed. Nillerdk (talk) 07:18, 24 April 2009 (UTC)

{{Information}} is made for photos. For reproductions of 2D art works {{Painting}} would be more accurate. For 3D works: If the country the art of work is situated in, knows freedom of panorama, it should be sufficient to name the creator in the "description" parameter. If the country doesn't know FOP, but the artist has made available the work under a free license, the license must be named too. I haven't come across this case until now, but I would write something like:
|author=
author of the depicted work: Mr. Artist
author of the photograph: Nillerdk
|permission=
license of the depicted work: cc-by-sa
license of the photograph: [your license]
--Slomox (talk) 14:05, 24 April 2009 (UTC)


Question about "date"

When moving files from other wikis, is it interesting to keep the "original upload date", if a "date of photograph" was given? Nillerdk (talk) 07:18, 24 April 2009 (UTC)

The original upload date should be present in the "original upload history" section and should _not_ be present in the "date" parameter. "date" is for the creation date, which is different from the original upload date in most cases. --Slomox (talk) 13:52, 24 April 2009 (UTC)
Thank you for your answers, it sounds all very reasonable. I'll add the missing points to the documentation page soon (if noone is faster ...) Nillerdk (talk) 21:17, 24 April 2009 (UTC)

Enlarge the arabic font

Please make the arabic description template have a bigger font. The writing is merely readable. Example:

العربية: منظر عام لمحطة أسوان

This is really hard to read.--Diaa abdelmoneim (talk) 13:44, 1 May 2009 (UTC)

I don't understand exactly. As far as I can see the template Information uses the standard font-size. If the text is hard to read it should be hard to read everywhere on Commons. If that's the case, we should change the font-size site-wide per CSS. If that's not the case, you have to explain in more detail what the problem is. --Slomox (talk) 14:35, 1 May 2009 (UTC)
And please specify what font-size is good. (I cannot jugde, Arabic is "hard to read" for me whatever the font-size may be...)
العربية: منظر عام لمحطة أسوان
العربية: منظر عام لمحطة أسوان
العربية: منظر عام لمحطة أسوان
العربية: منظر عام لمحطة أسوان
العربية: منظر عام لمحطة أسوان
العربية: منظر عام لمحطة أسوان
العربية: منظر عام لمحطة أسوان
العربية: منظر عام لمحطة أسوان
العربية: منظر عام لمحطة أسوان
--Slomox (talk) 14:40, 1 May 2009 (UTC)
I think the 130% would be adequate. It is also equivalent to the English font as far as I can see. The idea is that arabic letters are written wide more than tall and are connected to each other. Having them so small makes it really hard to read. Changing it to 130% would make reading it much easier. Thanks.--Diaa abdelmoneim (talk) 15:15, 1 May 2009 (UTC)
And do you have problems with all texts on Commons? The text in the sidebar etc. is too small too?
(And just to be sure [I want to avoid that tomorrow another user of Arabic complains about too big letters ;-)]: Do you have glasses or poor eyesight or is it really a general problem? [Please don't take this as an offense, I just want to be sure.]) --Slomox (talk) 15:40, 1 May 2009 (UTC)
I don't wear glasses and have no eyesight problems. Maybe 130% is a bit too far. 120% would be good as well. The English script is much easier to read. I'm using firefox, tried it on IE8 which was better but still not that good. You could send a request for comment to Arabic speaking users. Arabic speaking users are User:BomBom and others can be found at Category:User ar.
I just saw, that ar.wp has also a bigger font-size. Do you know, where the CSS statements are stored to set the font-size on ar.wp? Knowing them would make it much easier to change the settings here on Commons without risking awkward results. --Slomox (talk) 16:04, 1 May 2009 (UTC)
Do u mean this http://ar.wikipedia.org/skins-1.5/monobook/main.css?207xx ?--Diaa abdelmoneim (talk) 16:20, 1 May 2009 (UTC)
Okay, I now finally changed my preferences to Arabic interface. And the text is really ridiculous small. It almost looks as if it is set to an even smaller font-size than the already small standard font-size.
I tested it: With Arabic interface I have to increase the font-size to about 160% to see the text in the same size I saw the 130% Arabic text in when I still had my own language interface activated. So there must be some CSS code that only is active when your interface is set to Arabic. I will have a look into that. --Slomox (talk) 16:46, 1 May 2009 (UTC)
I know of this MediaWiki:Rtl.css which connects to the arabic language.--Diaa abdelmoneim (talk) 17:01, 1 May 2009 (UTC)
I cannot find any code that is responsible for the behaviour. But with some CSS it should be fixable.
The easiest solution is to add "#globalWrapper { font-size: xxx%; }" to MediaWiki:Monobook.css/ar.
With some additional lines of code it could be made look a little better (see my monobook.css. With that code the page looks much better to me. But the whole site layout depends on font-size. Any change can have irksome unanticipated consequences.)
The easiest way to go would be to just add "#globalWrapper { font-size: xxx%; }" to MediaWiki:Monobook.css/ar. Please have a test on User:Diaa abdelmoneim/monobook.css and tell me what value for "xxx" looks best to you (Just insert the code and use the preview [if you have activated QPreview, don't use that, use the normal preview], the CSS will automatically applied to the preview page). Does "#globalWrapper { font-size: 127%; }" look good for you? Or should it be even bigger, "#globalWrapper { font-size: 140%; }" or even "#globalWrapper { font-size: 150%; }"? --Slomox (talk) 18:14, 1 May 2009 (UTC)
I've copied to code on your monobook and it is certainly an improvement. However it only changes certain fonts like the button of the watchlist and buttons like edit and history. It doesn't change the general reading fonts found on the mainpage. Don't worry about wrecking anything, really few people use the arabic settings anyway because till now it didn't advance enough to be usable. I found something weird: When enlarging the font to 160% the navigation box goes below the main page. I don't know what's causing this so I wanted to report back to you.--Diaa abdelmoneim (talk) 18:32, 1 May 2009 (UTC)
The code should change all font-sizes. If you use the preview the code will be applied instantly. But if you save the code you have to empty your browser cache to apply the new code (the shortcuts for that are mentioned on your monobook.css page). The problem with the navigation box below the main page is one of the irksome unanticipated consequences I mentioned above. All the CSS settings for sizes depend on each other and if you change one of them, you often have to change many other too. But simply setting "#globalWrapper { font-size: 160%; }" should work without any problems (at least I hope so ;-) ). --Slomox (talk) 23:47, 1 May 2009 (UTC)
By the way, Two things I observed while using Arabic interface:
The numbers in the interface are written in Eastern Arabic numerals, while most numbers in the content are in Western Arabic numerals. Is there a preferred way or is the mixture of both okay?
It looks like indentations in discussions are done from both left and right. Is this intentional? --Slomox (talk) 18:29, 1 May 2009 (UTC)
The numbers should be Eastern Arabic numerals. The arabic language only knows this type of numbers (Eastern Arabic numerals). Please apply it to content too if possible. Headlines seem to be on the right which shouldn't be the case. They should be on the left. I posted this also on the Village pump.--Diaa abdelmoneim (talk) 18:38, 1 May 2009 (UTC)
The numbers should be Eastern Arabic numerals. Is that commonly agreed upon? All the numbers on the ar.wp Mainpage are Western.
The numbers on the ar.wp are the default numbers that come with the language settings. This is also the case when changing the language in Windows to arabic. You'll see that the numbers are still English (western arabic numbers). In official documents and in all arabic text books the numbers that are used are eastern arabic numbers. If ar.wp knew that it is possible to change this on Wikipedia they would have changed it. These are the numbers that are taught in school and if one doesn't learn a foreign language he wouldn't learn the western arabic numbers. The Western numbers have long been substituted in arabic world by the eastern arabic numbers. You can see the license plates of Saudi Arabia Egypt and Jordan for example have these numerals. I assure u this is the current arabic numbering system in most arabic speaking countries.--Diaa abdelmoneim (talk) 07:54, 2 May 2009 (UTC)
According to the English Wikipedia article on the topic, Western Arabic numbers are used in Morocco, Algeria, Tunisia and Libya. I don't know the internal situation in the Arab world, whether Northern Africans all know the Eastern numbers or whether the rest of the Arab world all know the Western numbers, so I will not touch the status quo. --Slomox (talk) 20:03, 2 May 2009 (UTC)
The headlines are changed.
The mainspace names haven't yet, although I'm not sure this should be done because most (all) mainspaces are English. Still the normal pages headlines like on talk pages haven't also changed.--Diaa abdelmoneim (talk) 07:54, 2 May 2009 (UTC) Woops didn't purge.--Diaa abdelmoneim (talk) 08:05, 2 May 2009 (UTC)
When I spoke about indentations, I meant the empty space that is created in discussions by adding one or several : at the start of the line. ltr languages have the space on the left side. But rtl languages have them on both sides, left and right. Is that intentional? --Slomox (talk) 23:33, 1 May 2009 (UTC)
I can't find what you mean. I compared the talk pages of the Mainpage in arabic and English language settings and I can't see a difference.
Have a look at File:Comp ar-en.png. At the bottom is this discussion with ltr interface, empty space only at the left side. At the top like it looks with Arabic interface. Empty space on both sides. The discussions looks like a flipped pyramid. --Slomox (talk) 12:50, 2 May 2009 (UTC)
Well this seems to be a bug that should be fixed. Please fix it. Thanks.--Diaa abdelmoneim (talk) 13:22, 2 May 2009 (UTC)
I proposed code on MediaWiki talk:Rtl.css. If nobody has objections I will apply it. --Slomox (talk) 19:56, 2 May 2009 (UTC)
Without reading the while thing above. I think the Arabic text is pretty good and well readable. Now, I'm using Firefox on a GNU/Linux, and -again- all is well. (if some users have any kind of problems, they can easily edited their own css or browser preferences.)--OsamaK 14:13, 2 May 2009 (UTC)

On the enwiki some users, including an admin, support the enlargment of the Font. You can see the discussion at http://en.wikipedia.org/wiki/User_talk:Al_Ameer_son#Arabic_text . Slomox could u please proceed with this change ? --Diaa abdelmoneim (talk) 21:02, 29 July 2009 (UTC)

English date

Hello, why the english date format is 28 April 2009 instead of 28th April 2009 ? Regards, Otourly (talk) 20:00, 1 May 2009 (UTC)

Well, 28 April 2009 is a valid date format, isn't it? And it can only be one of both. The best place to ask questions about the date is Template talk:Date, that's the template which formats the date. --Slomox (talk) 23:28, 1 May 2009 (UTC)

date revisited

A few weeks ago I requested a small clarification for the date field and Slomox did this Ok. I saw there was some discussion on what "date" means. The documentation now has "creation date". I suggest adding these extra clarifications to the documentation (if I've guessed correctly of course).

Creation date means when the original source (such as photograph of 3-D scene, digital file, or original 2-D artwork) was created.

I looked at File:Anders-Celsius-Head.jpg for guidance (painted 1701-1766, while image was on the web before 2003, and uploaded 2005).

Also, it seems the template should encourage use of {{Painting}} somehow, maybe right at the top with words like these:

If this is an image of pictural art (paintings, and by extension: frescoes, pencils, engravings, stained glass, etc.) then please consider replacing {{Information}} with {{Painting}}

I could do this edit myself, by adding new text above "{{TemplateBox..." , but comments from other users would be helpful, because I am never sure in this area! 84user (talk) 03:11, 13 May 2009 (UTC)

No lat/long?

There is no option for adding latitude/longitude for photos. There should be.--76.202.117.126 05:23, 25 May 2009 (UTC)

I see that there is {{Location dec}}, etc., but should it not be unified? Is it really too late?--76.202.117.126 05:29, 25 May 2009 (UTC)

Suggestions

I prefer to exchange the order of the fields "source" and "date". The order "description - date - source - author - permission -..." appears be better to me.

I suggest to integrate the {{Location}} template into {{Information}} as an optional field – preferably near the "description" field. --ŠJů (talk) 05:35, 10 June 2009 (UTC)

The integration is a nice idea. --Packa (talk) 05:46, 10 June 2009 (UTC)
As the description and date are information about the motive and should thus indeed appear next to each other, and as source and author are both sourcing information and should also appear next to each other, I was bold and implemented the change. It just makes sense and I don't know any reason (except "we always had it the other way round") not to change it.
I am also pro better integration of location, but this needs a bit more consensus, cause it was requested several times already and did not find general consensus until now. --Slomox (talk) 12:19, 10 June 2009 (UTC)
 Agree I think that {{Information}} should get location field for text description of the location (see {{Information2}}) and should be integrated with {{Location dec}} template. --Jarekt (talk) 17:14, 10 June 2009 (UTC)

Autocategorize per date

Hi. Is it possible and desirable to autocategorize images in categories like this Category:June 2009, using the data parameter (only when it is in YYYY-MM-DD format)? Emijrp (talk) 08:54, 22 June 2009 (UTC)

Perhaps, categories like Category:2009-06-22 would be nice for the bunch of images, and Category:2009-06 or Category:June 2009 only for the best and most representative images of that month. Emijrp (talk) 08:55, 22 June 2009 (UTC)
Technically it's possible. That's no big problem. Whether it's desirable, is another question. I'd say yes, but I guess some others will consider this form of categorization as spamming the date categories with junk. I think, some consensus should be gained at a prominent place like the Village pump before. --Slomox (talk) 12:28, 22 June 2009 (UTC)
Done. Emijrp (talk) 13:16, 22 June 2009 (UTC)

Wrong date format

Would it possible to categorize all images with not ISO date format in a category? (for maintenance purposes, as Slobot). Emijrp (talk) 16:02, 22 June 2009 (UTC)

Slobot at the moment operates on the full dump. The bot will be busy for several months with edits based on it. But after the obvious ones are all done, a category like that could be useful to Slobot to find more cases that can be changed automatically and are not yet covered by the bot or cases that cannot be changed automatically and need human review.
But at the moment I don't know how to do it. Categorizing all non-empty non-ISO dates is easy to do. But not all non-ISO dates need to be changed. For cases that are not covered by ISO, but still valid, I created {{Other date}}. It allows to specify things like "summer 1969", "ca. 1980" or "before 1900" in a localizable format. There's no easy way to exclude them. But it would be possible to add them to another category and then use CatScan to exclude those from the list. --Slomox (talk) 18:23, 22 June 2009 (UTC)
OK, and one for no date images? Like Category:Media lacking a description. emijrp (talk) 14:48, 28 June 2009 (UTC)
I don't think that's a good idea, cause you cannot distinguish files lacking a date from files where no meaningful date can be applied. --Slomox (talk) 17:11, 28 June 2009 (UTC)
Perhaps we need a template for "N/A" (not applicable) dates, filling the date field. emijrp (talk) 20:44, 29 June 2009 (UTC)
It would also be possible to define a special string as meaning "N/A" (like e.g. simple and short "-"), which would then be evaluated by {{Information}} directly. --Slomox (talk) 00:22, 30 June 2009 (UTC)

Credit Line field

{{Editprotected}} In the discussion Commons:Village_pump/Archive/2009Jun#Contributors_to_WC_can_forget_about_having_their_work_credited from June 29 2009 I proposed to add an optional field Credit line to information template where authors or bots can add text to be used by reusers of commons files. The discussion focused on how confusing it is for reusers to figure out what is the proper or required attribution line. The proposal received a very positive response. The final output of altered template is expected to look like this example. See also Commons:Credit Line page where users can discuss/decide on proper form of credit lines for different licenses. --Jarekt (talk) 03:39, 3 July 2009 (UTC)

I agree with the need for something like this, we need an attribution line as well as an author line. CC licenses allow rights holders to specify how they wish to be attributed, and the information template does not currently support this. I would prefer the field just be "Attribution" over "Credit Line" though, it's broader and can allow for more detailed instructions. - hahnchen 20:41, 28 July 2009 (UTC)
Attribution is fine with me. I think we could have a bot, may be user:CommonsDelinker may be something similar that could add attribution line to all the images of any user that requests it. If adding this field to {{Information}} template does not work it can be always added using other field parameter like here. However this option would not be as uniform and it would not be localized. --Jarekt (talk) 01:30, 29 July 2009 (UTC)
Hi,
I see a big discussion but no consensus, so I'm not fixing this template, this template is very very very high used and a edit without full consensus could bring problems. 09:18, 5 September 2009 (UTC)

Suggestion: Add new field

{{editprotected}}

I suggest to add a new field "comments", "notes" or "remarks" to add additional information which doesn't suit the image's description. Cf. Template Information on German Wikipedia where is a field "Anmerkungen". --Eva K. is evil 09:59, 9 July 2009 (UTC)

Could you give examples about what kind of information should go into the new parameter? --Slomox (talk) 15:53, 9 July 2009 (UTC)
The {{Painting}} template has such a field.
But the "notes" parameter in {{Painting}} is basically the equivalent of "description" in {{Information}}, cause there's no other parameter that can take free text in {{Painting}}. --Slomox (talk) 20:44, 9 July 2009 (UTC)
I'd like to give technical information about an image, e.q. the number of single images in a panoramic, data about images without meta data, or I'd like to add certain templates like "panoramic", "retouched", "freedom of panorama", "personal rights" etc. For me all that doesn't belong in the description field as there should only be a information of the image's content. There is already a field "other_fields" but it merges with "Permission" if it is filled. Perhaps it would be enough to fix that. --Eva K. is evil 01:40, 10 July 2009 (UTC)
The standard position for templates like that is after {{Information}} at the moment. For meta data there is {{PhotoInfo}} and {{Photo Information}} (I don't know, which of both is the one to go with, both are rarely used). These templates too are normally placed after {{Information}}.
If you want to use "other_fields", you have to create the new table row yourself in wiki syntax. Like that
|- ! style="background: #ccf; text-align: right; padding-right: 0.4em" | extra field | text of extra field
Description
This file has no description, and may be lacking other information.

Please provide a meaningful description of this file.

Source
This file is lacking source information.

Please edit this file's description and provide a source.

Author
This file is lacking author information.
I don't know, who had the idea to make it work that way (not very bright imho), but that's the way it works. --Slomox (talk) 02:23, 10 July 2009 (UTC)

I oppose adding this. To me it's redundant with Description. It's not just for describing the image's content but the image itself (which should be the focus on Commons, not the subject). Rocket000 (talk) 08:24, 10 July 2009 (UTC)

Where are "related images" included? That would be an appropriate new field to include. --EncycloPetey (talk) 03:48, 11 July 2009 (UTC)
related images usually go in "other_versions" field if image is part of a series, otherwise you can find them in the related categories or galleries. --Jarekt (talk) 04:12, 11 July 2009 (UTC)
That's a misleading field name then. I assumed that field was for altered versions of the same image, not for other photos of the same specimen from another angle, magnification, etc. There should be a way to clearly indicate that several photos are of the same specimen, especially when the subject is a living organism and therefore not always easily identified as such. --EncycloPetey (talk) 04:20, 11 July 2009 (UTC)
I've seen the other_versions field used that way a couple times and didn't think they were out of place there. It is slightly a misnomer but it's ok I think. I would like to make better use of the other_fields part, though. Maybe we can make it easy to add any extra field you want (without having to do all that formatting). Rocket000 (talk) 02:08, 12 July 2009 (UTC)

Alt Image

There is a procedure within WP for adding alternate text to all images to allow users and editors who are seeing pictures as text either because they have images turned off or because they use a device such as a screen reader (for people who cannot see or cannot see well) to see text vice an image, or hear the text description of the image verbally. My request is to modify this template to allow users to add the alt text to the image. This will allow consistency with what the image is and what the articles and images have as an alt text description of the image so we don't end up with 50 descriptions of the same image. This will also potentially allow a bot or script to automatically or semi automatically add alt text to the image. --Kumioko (talk) 00:27, 12 July 2009 (UTC)

This project is multilingual and exists for a lot more than Wikipedia articles. Rocket000 (talk) 02:13, 12 July 2009 (UTC)
I understand but I believe that this will come up for ither projects as well if it hasn't already. I don't think that the English WP is the only project that is concerned with users being able to interpret images who use screen readers or other devices and cannot see the actual image. --Kumioko (talk) 15:08, 13 July 2009 (UTC)

own work

Is the model {{Own}} always necessary, since the translation seems to be made on the fly? If it's not the case, that would be a good idea to remove it from the documentation, then to delete this model and to launch a bot to make the replacement towards own work. Okki (talk) 11:16, 12 July 2009 (UTC) ps: sorry for my really poor english.

Template {{Own}} is designed to show equivalent of own work in language that depends on your preference or on the wikipedia you came from. If you do not like some of the translations feel free to suggest better ones at Template talk:Own. --Jarekt (talk) 02:09, 13 July 2009 (UTC)


{{Editprotected}}

Add a field for the benefit of commons helper so that Source can be used for the ORIGINAL source information from the originating project, where as the Transfer details added by CommonsHelper and other tools can be seperate.

This would enable seperation of 'library/archive' notes from actual sourcing information.

Field could be called something like ( Transfer: / Moved: etc. ) Sfan00 IMG (talk) 15:43, 16 July 2009 (UTC)

 Not done information should stay simple. Multichill (talk) 10:17, 18 July 2009 (UTC)

Using proper fallback

Hello. I'd love to give this template a proper fallback with {{Fallback|Template:Information}}. Basically, it means that if the template for {{int:Lang}} doesn't exist, then it will check if there's another template that it could use. For example, this is necessary when you use the skin "de-formal", so that it fallbacks to "de" (the versions wouldn't be different, that's why we don't need Template:Information/de-formal). Is there someone against this; otherwise I'd love to inplement this. Let me know. Thank you. --The Evil IP address (talk) 16:49, 17 September 2009 (UTC)

Please do. Strangely this template seems to be the last one to be updated.--Jarekt (talk) 17:15, 17 September 2009 (UTC)
✓ Done --Slomox (talk) 18:04, 17 September 2009 (UTC)

Date field

At the moment the date field is always shown, even if it's not filled out.

Information with empty date field
Description
English: something
Source Own work
Author Some guy

In my opinion it would make more sense to remove it when no date is given, because it looks so empty when there's nothing. What do you think? --The Evil IP address (talk) 15:09, 22 November 2009 (UTC)

Unfortunately we cannot distinguish whether the date parameter is left empty on purpose or was just forgot. If there is a meaningful date applicable to the file and it just misses, there should be the empty field to remind people. But if the the field is left empty cause there is no meaningful date for the file (e.g. a smiley icon file, where we have no real date of original creation and where the creation date of the actual file is just a random date without a real relation to the content depicted) the field shouldn't be there. We cannot distinguish these cases and therefore I would prefer to always show the parameter even if it is empty. --Slomox (talk) 15:50, 22 November 2009 (UTC)
I agree with Slomox, images should have dates (even approximate dates). Empty field will help remind people. --Jarekt (talk) 21:37, 22 November 2009 (UTC)
How about having an option such as date=na, which will remove the date field only where it is specifically not applicable? Tivedshambo (talk) 22:49, 22 November 2009 (UTC)

Every work (file) was created at one specific date. An icon file too. An unknown date should be an unwelcome case. I can see other problem: derivate works should have more date indications: date of origin of the depicted work (sculpture, painting, document etc.), date of taken the photo, and date of last modification of the image. Many users and bots confuse these three indications; some even fill in the first upload date instead of taken or create date. The word "date" in the form should be equipped with an explanatory word ("date of ..." instead of pure "date"). --ŠJů (talk) 00:13, 23 November 2009 (UTC)

Every work (file) was created at one specific date. An icon file too. But it is not meaningful. What date would you insert at File:Smiley.svg? The date the smile-smiley was first invented? The date the author created this very SVG file? The date the author edited it for the last time (and changed its appearance)? The smiley invention date is unknown and the file creation date doesn't mean anything. Whether it's 1999 or 2009, there's no difference and the file is all the same. For an object existing in real life a date is relevant cause it documents its state at that time. Whether a photo of a building is from 1999 or 2009 matters cause buildings change over time. Smileys do not.
derivate works should have more date indications: date of origin of the depicted work (sculpture, painting, document etc.), date of taken the photo, and date of last modification of the image. It's indeed very bad that there is so much confusion, especially with the upload bots. But it actually isn't that complicated. Upload bots should place the original upload dates into the original upload history section (which each useful upload bot should create). date of last modification is also present in the upload history and doesn't need to be placed in the date section. date of origin of the depicted object isn't a property of the file, it's a property of the depicted object. The solution is easy: just mention the depicted object iin the file description, link it to its gallery page and tell the date of creation of the object on its gallery page (and additionally link the gallery to the Wikipedia articles). Then the information is available to anybody interested, in a way without any redundancy or inconsistency. Then the only remaining date that needs to be specified is date the photo is taken and that's indeed the only date that we need (at least in the date parameter). --Slomox (talk) 11:48, 23 November 2009 (UTC)

Internationalization

Bots such as Emijrpbot are busy i18n'ing my recent English-language uploads and replacing the headers as follows:

Summary → {{int:filedesc}}
[[Commons:Copyright tags|Licensing]] → {{int:license}}
etc.

These headers were originally generated by this {{Information}} template. Is it time to update the template so that it generates the i18n version directly?
Andy Dingley (talk) 11:26, 3 November 2009 (UTC)

They are not added by the template. They are added by the upload script of the software directly. This can only be fixed by changing the Mediawiki code. The problem is known to the developers, but nobody cared about fixing it since.
Personally btw I would opt for removing them completely. These headings have no meaningful purpose at all. --Slomox (talk) 11:59, 3 November 2009 (UTC)
Questions about this are so frequent I added them to FAQ page. --Jarekt (talk) 15:08, 3 November 2009 (UTC)

I think we can change this here. emijrp (talk) 19:38, 1 December 2009 (UTC)

Please check with author - User:Lupo. He was already working on fixing this problem. --Jarekt (talk) 20:18, 1 December 2009 (UTC)
No, I'm not fixing this problem. The real FAQ is not "why is the text of my new uploads corrected soon after upload?", but rather "why don't you fix it?". For the umpteenth time: these headers are not added by a template, and they are not added by the upload script. They are added by the servers. The core MediaWiki software running on the servers adds these headers if a user submits an upload and has chosen a license from the drop-down menu.
The MediaWiki software uses MediaWiki:Filedesc for the "Summary" heading and MediaWiki:License-header for the "License" heading. These messages are apparently translated into the uploader's interface language on upload and then saved.
To "correct" the problem, the MediaWiki software would need to generate the headers as {{int:filedesc}} and {{int:license-header}}. To get the software changed that way, somebody would need to make a request at bugzilla. But there's a catch: the {{int:}} feature itself is officially considered a bug! That's because it causes inconsistencies in link tables in the database.
Now, I at least am not going to ask the developers to "fix" one issue by making use of a "bug". And I'm not going to add hacks to the upload script to make even more use of this bug. As long as {{int:}} is considered a bug, you can't rely on it functioning in any particular way. It might stop "working" anytime. Lupo 22:16, 1 December 2009 (UTC)
these headers are not added by a template, and they are not added by the upload script. If I am addressed with this too: when I spoke about the upload script of the software I didn't mean the Javascript script, but the PHP script.
And {{int:}} of course is not considered a bug. It was indeed meant to work just like it works. It's meant to show localized MediaWiki messages and that is what it does. It was just unintended by the developers that users would combine it with parser logic and start using it as a localisation tool. But that's not a bug, just a hack. I'm 99% sure that the developers will not change anything about the way int: works. First: it isn't broken, so there's nothing to fix. And second: it would completely knock off Commons. If the developers want to get rid of the hack the only way for them to do so is implementing real support for multilingual content in MediaWiki (something that's overdue for long).
Oh, and one more remark: my favorised solution of getting rid of the headings would solve the "int: problem" too ;-) --Slomox (talk) 02:24, 2 December 2009 (UTC)
I am usually a fan of headings (not sure why - I guess I got used to them), but if a request to remove heading insertion by the upload code would be something less controversial than insertion of {{int:}} headings than I would gladly give them up. Another solution would be to wrap {{int:filedesc}} and {{int:license}} in {{FileDesc}} and {{Licence}} templates and automatically insert those. If we ever find a better way to Internationalize headers than all we have to do is to change those templates instead of all the files. --Jarekt (talk) 03:48, 2 December 2009 (UTC)
Is it possible to add {{int:license}} to MediaWiki:License-header? -- User:Docu at 16:05, 2 December 2009 (UTC)
Multichill tested this on October 23 and quickly deleted the changed message afterwards. I don't know what was the problem, but it seems it didn't work. --Slomox (talk) 16:58, 2 December 2009 (UTC)
It didn't work. Not sure why. Probably some looping problems. You should probably talk with User:Lupo, he knows all the ins and outs of the upload form. Multichill (talk) 18:23, 2 December 2009 (UTC)
And if it had worked, it would have messed up. The two messages, license-header and license, are different on purpose. Who said that the heading should have the same text as the label on the upload form (that's what MediaWiki:License is for).
I don't know why it didn't "work", though, but I've seen earlier reports that the {{int:}} feature didn't work right in MediaWiki-Namespace. Possibly some kind of looping/recursion problem, as you said; after all, MediaWiki messages are already auto-localized by the software. Lupo 09:01, 4 December 2009 (UTC)

It seems we need a bug report asking to modify MediaWiki software which "uses MediaWiki:Filedesc for the "Summary" heading and MediaWiki:License-header for the "License" heading" [after Lupo] to either:

  1. stop adding headers altogether
  2. use {{int:filedesc}} and {{int:license}}.
  3. use new {{FileDesc}} and {{Licence}} templates which at the moment would wrap around {{int:filedesc}} and {{int:license}}, but could be easily changed in the future.

The first option might not be popular with some Commons users, the second with MediaWiki software developers (see Lupo's comment above). --Jarekt (talk) 19:55, 2 December 2009 (UTC)

Stop adding headers altogether! :) Rocket000 (talk) 20:33, 3 December 2009 (UTC)

To do some tests for change to the form, I'm attempting to set up the form on the test wiki. If there is a developer that could enable commons as an import source there, it would help (the form has so many transcluded strings ..) -- User:Docu at 21:00, 3 December 2009 (UTC)

What about using Special:ExpandTemplates? Rocket000 (talk) 23:35, 3 December 2009 (UTC)
I'm not sure if that works for partial substitution. In any case, we would need to see that it works before implementing it here. I opened bugzilla:21755. -- User:Docu at 08:30, 4 December 2009 (UTC)

I would not invest too much time in this. The usability team is undertaking a complete redesign of the upload procedures anyway, and while it may be some time until we see any results from this, it sure looks as if the whole uploading stuff will change significantly anyway in the future. Lupo 09:01, 4 December 2009 (UTC)

It might not take too much time. As "the future" can easily be 12 months away, I think it's worth doing it. If you want to vote for the bug ;) -- User:Docu at 09:10, 4 December 2009 (UTC)
It was done. Transwiking now works with lightening speed (thanks to Roan).
I didn't get the upload form to work yet, either because it's need customization, I didn't import all parts or possibly due to errors from other things installed at the test wiki. -- User:Docu at 13:00, 8 December 2009 (UTC)

Maintenance cat

To do some maintenance work, could we add template based categories in the form "Category:Information template (yyyy-mm)" (yyyy being the year, e.g. 2009, mm the month, e.g. 12 for December)? I would make sure to add "HIDDENCAT" to these. These categories wouldn't be mixed and/or linked from the topical categories for years/months. -- User:Docu at 05:10, 13 December 2009 (UTC)

I like the idea but it will be a LOT of categories. I would propose to try it first on the smaller problem like "Category:Information template (yyyy)" for years prior to 1980 for example. See {{ISOyear}}.--Jarekt (talk) 17:28, 13 December 2009 (UTC)
Personally, I'd rather work on >2008. -- User:Docu at 17:54, 14 December 2009 (UTC)
That would be fine I was just suggesting first experimenting with subset of images, assuming others do not see any problems we did not foresee . --Jarekt (talk) 19:14, 14 December 2009 (UTC)
I don't like this idea. Playing around with our one of our most often used templates is a bad idea. What kind of maintenance work do you want to do exactly? Multichill (talk) 16:15, 9 January 2010 (UTC)
Don't worry, it's a hidden category, so it wont affect you, nor will we let people play with it. It will allow to select and improve categorization of recently taken images. -- User:Docu at 17:03, 9 January 2010 (UTC)
How exactly do you want to use it? Please describe it in detail. Multichill (talk) 17:05, 9 January 2010 (UTC)
In the usual way with catscan. Intersecting it with topical categories. -- User:Docu at 17:08, 9 January 2010 (UTC)
So this is just a way to sneak automatic categorization in. Bad plan. Multichill (talk) 17:26, 9 January 2010 (UTC)
I don't quite understand, but I hope you will get to like it. -- User:Docu at 17:30, 9 January 2010 (UTC)
Are there any specific concerns of yours you feel should be addressed (potential problems with BotMultichill/GeographBot/CategorizationBot)? -- User:Docu at 07:29, 10 January 2010 (UTC)

You still haven't said what you want to do with the cats. Apart from that it is a bad developement if the information template is misused for more and more purposes. It is primarily a template for the legal matters of a file. These should be kept separated from other things. --Cwbm (commons) (talk) 09:33, 12 January 2010 (UTC)

As stated in the section header, it's a maintenance category that allows to develop other categories and find recent images. Rather than adding additional categories to the file description page, it makes use of the existing data in the information template.
The information templates generally holds all information on a file. Its main problem is not that it's being misused, but that generally it isn't sufficiently put to use. BTW the one element that is frequently not included in the template is the licensing tag.
As mentioned before, the maintenance categories wont affect anybody that doesn't want to use them and will remain hidden. -- User:Docu at 09:40, 12 January 2010 (UTC)
Sorry but before making it even more complicated for our Commons cooperators that are already bombarded with all sorts of rules, templates, license problems, warnings and other bot manipulations, we must be able to clearly see what are the needs, uses, advantages and consequences of newly added templates (and subsequent bot activities). I know I have limited template know-how, but obviously, but few other people seem to understand the proposed template approach. --Foroa (talk) 20:40, 12 January 2010 (UTC)
You can test it yourself, see below (#Test code for maintenance category). It is really just a minor change. -- User:Docu at 04:33, 13 January 2010 (UTC)
If you just want to do maintenance you don't need a cat. --Cwbm (commons) (talk) 09:09, 13 January 2010 (UTC)

Code for maintenance category

The code that adds the maintenance category is available at Template:Information2. It works correctly. There are no recent images using Information2, but it can be tested by changing a date on one of the images and use "show preview".

Please review it and test it with some of the images using Information2. -- User:Docu at 04:33, 13 January 2010 (UTC)

string to add
{{#if: {{{Date|{{{date|}}}}}} | 
{{#ifeq:{{NAMESPACE}}|File|
{{#iferror: {{#time:Y|{{{Date|{{{date}}}}}}}}||
{{#ifexpr:{{#time:Y|{{{Date|{{{date}}}}}}}}>2008|
[[Category:Information template: {{#ifeq:{{{Date|{{{date}}}}}}|2009|2009|{{#ifeq:{{{Date|{{{date}}}}}}|2010|2010|{{#time:Y-m|{{{Date|{{{date}}} }}} }}}}}}]]
}}}}}}}}
I, Foroa & Cwbm (commons) don't seem to like this modification. You (Docu) and Jarekt do seem to like this modification. Maybe you should advertise this discussion at the village pump to get some more opinions? Multichill (talk) 21:17, 22 January 2010 (UTC)
In the meantime, Evil IP reviewed the code deemed it ok.
Personally, I don't really like it either, but this isn't really the question. If there was a MediaWiki based solution, I'd prefer that.
I'm not sure about Cwbm, he just says he thinks I don't need it. He might be right about this and it might not be needed any more, as you promised to help categorizing topics by year. I like to see you deliver on that. -- User:Docu at 07:59, 23 January 2010 (UTC)
You can pull a lot of information from the search engine. For example the images with the date in 2009 and 2010. Of course you can enter the name of a category to get images with a year in a certain category. Multichill (talk) 08:57, 23 January 2010 (UTC)
If it works for you, I think I will just watch you delivering on your promise. -- User:Docu at 09:01, 23 January 2010 (UTC)
What promise? Multichill (talk) 09:29, 23 January 2010 (UTC)
diff -- User:Docu at 18:16, 23 January 2010 (UTC)

Don't add this code, please. I don't like it either. Rocket000 (talk) 16:54, 23 January 2010 (UTC)

Why? -- User:Docu at 18:16, 23 January 2010 (UTC)
Mainly, because I don't see the point. Rocket000 (talk) 10:22, 24 January 2010 (UTC)
I see. Good point. Depending on how Multi's solution works out, it might not be needed anymore. -- User:Docu at 10:26, 24 January 2010 (UTC)
I fail to see what "maintenance" should be done with that. To me a "maintenance category" is one where images are put in when something needs to be fixed and when it is fixed it is removed from the category.
What problems should be fixed? Please give an example. How should it be fixed? Do we need to add an extra parameter on the template to remove category again when problem is fixed? --MGA73 (talk) 11:22, 24 January 2010 (UTC)
Sure, but let's see how Multi's approach works out (see diff above). -- User:Docu at 12:23, 24 January 2010 (UTC)

Using the translations of translatewiki

I modified the extension and imported all the current translations at translatewiki (more info at Commons talk:Template i18n#Next step in translations). Anyone object against enabling it for this template? Multichill (talk) 21:17, 22 January 2010 (UTC)

As the interface is being redesigned, I don't think it's worth doing this now. -- User:Docu at 07:59, 23 January 2010 (UTC)
Interface redesign? You're talking about the usability initiative? Doubt if this template is part of it. It's a small change and nothing changes for the users, but it will make translation a lot easier and will make this template available in a lot more languages soon. Multichill (talk) 08:46, 23 January 2010 (UTC)
At least it's in the proposal. Did you address the problems raised on the other template you converted? -- User:Docu at 09:01, 23 January 2010 (UTC)
Which one? Multichill (talk) 09:33, 23 January 2010 (UTC)
The cc one. -- User:Docu at 18:16, 23 January 2010 (UTC)
I converted over a hunderd Creative Commons license templates. Which one? Multichill (talk) 23:14, 23 January 2010 (UTC)
The one(s) announced at the VP. -- User:Docu at 08:26, 24 January 2010 (UTC)
Docu you are making it very hard for "new ones" to find out what you are talking about. It would be nice if you used links when you debate outside a usertalk page. Or even better if you gave a shout resume of the problem so we do not have to read a lot of other discussions to follow this debate.
If you have some worries about what would not work if the template is converted then please tell. --MGA73 (talk) 11:16, 24 January 2010 (UTC)
People's concerns with his prior attempts are mentioned at Commons:Village_pump/Archive/2010Jan#Improved_Creative_Commons_templates. Unfortunately, he hasn't responded there. So we don't know if he is working on the problem or if he just ignores peoples concerns. -- User:Docu at 12:23, 24 January 2010 (UTC)
I fail to see the connection between the two problems but you may want to take a look at this Commons_talk:Template_i18n#.7B.7BCc-by-sa-3.0.2C2.5.2C2.0.2C1.0.7D.7D. --MGA73 (talk) 08:20, 27 January 2010 (UTC)
The connection is that a significant change to the presentation of file description pages was made without consulting people before and when persons raised concerns with it these weren't addressed until we had this discussion here. The usual way would be to do a test and make sure it has no significant impact or, if it does, seek wider input. As the interface is being re-designed, there isn't really a point doing changes if there is no impact either. -- User:Docu at 09:08, 27 January 2010 (UTC)
I agree that major changes should only be made after a discussion. I do not know if Multichill has asked somewhere before he changed. But I do not think we should say no to changes just because (of if) changes was not discussed properly before they were made. Also if a mistake was made with one template that should not be an argument not to change other templates.
I see three main questions. 1) Will there be a significant change to the presentation of file description pages (and how)? 2) How much work will be needed to implement the changes (who should make that)? 3) Will the work be "wasted" if/when the interface is being re-designed?
If new layout looks good and the time spend is not "wasted" then I see no problems. --MGA73 (talk) 10:57, 27 January 2010 (UTC)
(reset indent) Without consulting, without testing? {{Cc-by-sa-3.0-example}} exists for months. I posted a message at Commons_talk:Template_i18n#Next_step_in_translations. I advertised this at Commons:Village pump/Archive/2009Dec#Next step in translations and got response from several people. If problems arise this doesn't mean they will be discussed and solved instantly, that takes time, just like it took time to implement the whole thing. 1. No, 2. Translations are already imported 3. No, the current translations were imported. Multichill (talk) 18:49, 27 January 2010 (UTC)
Apparently the sample you created wasn't significant. It didn't cover all use cases and you didn't even follow up on problems raised in the forum. Please make a sample and test cases before doing edits to Template:Information. -- User:Docu at 10:00, 30 January 2010 (UTC)

 Question Will there still be the link to Commons:Reusing content outside Wikimedia? --The Evil IP address (talk) 17:03, 23 January 2010 (UTC)

Yes, the template won't change for the user. Multichill (talk) 23:14, 23 January 2010 (UTC)
See Template:Information/new for the new implementation. Multichill (talk) 16:52, 27 February 2010 (UTC)
It doesn't work. I think it's preferable to wait for the interface redesign. This just invalidates a lot of pages in cache for no benefit. -- User:Docu at 18:08, 27 February 2010 (UTC)
What doesn't work exactly? Multichill (talk) 18:47, 27 February 2010 (UTC)
I tried new template on few images and it looks fine. I think we should swap them. --Jarekt (talk) 19:14, 27 February 2010 (UTC)
✓ Done. Multichill (talk) 12:16, 6 March 2010 (UTC)
Any benefits with this change? -- User:Docu at 12:41, 6 March 2010 (UTC)
None at all, I just like breaking things ;-). Of course there are benefits! See Commons talk:Template i18n#Next step in translations. Multichill (talk) 13:56, 6 March 2010 (UTC)
"Reusing this file" is now unlocalized for 'nds'. --Slomox (talk) 12:50, 6 March 2010 (UTC)
I guess I missed that one. I added it now, it's probably visible tomorrow. We could use your help here Slomox. Multichill (talk) 13:56, 6 March 2010 (UTC)
My interest in doing that would increase immensely if the messages would be one message with country and version number being parameters. Translating the same message 170 times triggers my refusal switch. --Slomox (talk) 01:02, 7 March 2010 (UTC)
These kind of lego sentences might work in Plattdüütsch or Nederlands, but probably don't work in all languages. Multichill (talk) 10:30, 7 March 2010 (UTC)

25 languages lost

Following a problem at another template, a review showed that the most recent change made us loose about 25 language version (of about 63 versions). Reverting the last change will increase internationalization of this core template for Commons. -- User:Docu at 12:41, 14 March 2010 (UTC)

Did you bother reading #Using the translations of translatewiki before you started shouting here? Read the first sentence. Multichill (talk) 14:47, 14 March 2010 (UTC)
Why do I count 63 subpages for languages here and not as many versions at translate wiki? According to you, "the template won't change for the user". If there are 25 missing, it did change. -- User:Docu at 15:36, 14 March 2010 (UTC)
If the top 40 languages are translated that should cover most of the users of Commons. If any of the missing translations are relevant why move them to translate wiki? --MGA73 (talk) 15:51, 14 March 2010 (UTC)
Are they missing or not? If yes, can you restore the working version? -- User:Docu at 15:53, 14 March 2010 (UTC)
Information has about 70 translations at translatewiki. I say about, because it's split up into multiple messages and the number of translations per message differer a bit. Multichill (talk) 16:13, 14 March 2010 (UTC)
It looks like a few strings are missing, but not that many. -- User:Docu at 16:47, 14 March 2010 (UTC)

a lot formatting

I noticed there's a lot formatting in there. What about using some CSS instead? Since this is on like every file page, it'll probably be more efficient and save some bytes. Rocket000 (talk) 22:59, 6 March 2010 (UTC)

That's nothing new, I didn't touch it. I hope you don't mind that I moved this to a new topic. {{Information/new}} is open for css experiments now ;-) Multichill (talk) 23:48, 6 March 2010 (UTC)
One question: why is the class "toccolours vevent"? I can't find "vevent" defined anywhere, is it for customization or something? I'm not a CSS expert so if anyone would like to help with implementing this... Rocket000 (talk) 01:37, 7 March 2010 (UTC)
„vevent“ is a hCalendar microformat attribute, see Template talk:Information/Archive 2#Adding hCalendar microformat. --Mormegil (talk) 18:23, 7 March 2010 (UTC)
Ah, I see. I guess that has nothing to do with style then. Thanks. Rocket000 (talk) 01:30, 8 March 2010 (UTC)

Nevermind, I forgot that MediaWiki:Common.css applies only to Commons. Thus, we couldn't guarantee consistent formatting across all projects. Rocket000 (talk) 15:05, 15 March 2010 (UTC)

Translations available at Translate-WIki

16:47, 14 March 2010 (UTC)

Messageen-gbneocpt-brqqqextpdcbarigyifurdsbfyhsbiskaslsqsrszltabssieusvtethzh-twmtrogazh-hanthykmkoarcafibghrellthennplskbrfaukzh-hansnomlpmsbe-taraskeoialbetcsndsafgltrvecvidamkhugswitesnljadeptrufrenGrand Total
Wm-license-information-date1111111111111111111111111111111111111111111111111111111111111111111111171
Wm-license-information-author1111111111111111111111111111111111111111111111111111111111111111111111171
Wm-license-information-source11111111111111111111111111111111111111111111111111111111111111111111169
Wm-license-information-permission11111111111111111111111111111111111111111111111111111111111111111111169
Wm-license-information-permission-see-below1111111111111111111111111111111111111111111111111111111111111111111168
Wm-license-information-description1111111111111111111111111111111111111111111111111111111111111111111168
Wm-license-information-other-versions1111111111111111111111111111111111111111111111111111111111111111111168
Wm-license-information-author-missing11111111111111111111111111111111111111111111111111111111157
Wm-license-information-description-missing11111111111111111111111111111111111111111111111111111154
Wm-license-information-description-missing-request1111111111111111111111111111111111111111111111111111153
Wm-license-information-source-missing11111111111111111111111111111111111111111111145
Wm-license-information-source-missing-request1111111111111111111111111111111111111111111144
Wm-license-information-table-summary111111111111111111111111111111111111111111143
Wm-license-information-permission-reusing-text1111111111111111111111111111111111111138
Wm-license-information-permission-reusing-link111111111111113
Grand Total111112234457777777777899101010101111111112121212121212121213131313131313131314141414141414141414141414141414141414151515151515151515831

Docu at 16:47, 14 March 2010 (UTC)

Well I just checked "da" for this one "Wm-license-information-permission-reusing-link". It is not only at translate wiki it is missing. It is also missing at Commons? --MGA73 (talk) 18:05, 14 March 2010 (UTC)

It's missing as Commons:Reusing content outside Wikimedia doesn't have a da version. If you click on the language code, it will display the version at Commons. Check, e.g. "ta". -- User:Docu at 18:10, 14 March 2010 (UTC)
Yep. But table might get someone to think that all the blank cells were things we had on Commons but was missing on translate wiki. --MGA73 (talk) 18:13, 14 March 2010 (UTC)
You could add an "x" on things we don't have here either? -- User:Docu at 18:14, 14 March 2010 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:Information/Archive_2&oldid=842735008"