Template talk:Information/Archive 3

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Template:Information/multi

There is a subpage at Template:Information/multi. There is a bot request to add more of it at Commons:Bots/Requests/BrooklynMuseumBot.

Otherwise it seems to be rarely used and personally I would replace it with {{Information}}. -- User:Docu at 15:42, 13 April 2010 (UTC)

Support, replace and nuke. No rush though. Multichill (talk) 18:16, 13 April 2010 (UTC)

Support I agree with replace and nuke. The only complication would be that sometimes {{Painting}} would work better than {{Information}}. --Jarekt (talk) 19:16, 13 April 2010 (UTC)

Order

To follow more standard citation practices, I think the order of the summary information should be re-arranged to the following:

Author
Date
Source
Description
Permission
Other versions

[tk] XANDERLIPTAK 23:09, 1 May 2010 (UTC)

Description is the most important part so that's at the top. Multichill (talk) 23:27, 1 May 2010 (UTC)

Combination with Template:Festival Japan Matsuri 2010 (and Festival Template)

A recent batch upload used the first template (which is based on the second) in combination with {{Information}}. While the first template has some advantages (indicating details about the festival in a consistent way), the additional author fields of both templates don't seem to make them compatible with {{Information}}.

I think these templates should be used either as standalone templates or depreciated in favor of the exclusive use of {{Information}}. -- User:Docu at 16:15, 24 May 2010 (UTC)

The author field is not the same as the one from the information template. The author field as I intented it is usually the person being photographied here. It's not the person who took the photograph. I should just rename it to 'extra information' or something like that. This was primarily intented for events having several known authors being photographied on the same event. The next one will be at the end of the week by the way (Comédie du Livre 2010). Esby (talk) 18:27, 24 May 2010 (UTC)

It's just confusing if you name it author. The Bundesarchiv batch has some "Persons depicted" fields. Maybe you want to use something similar for your next batch upload.

It would be much easier if you would just use {{Fr}} and {{En}} for descriptions. An additional problem of these templates is that they use the template to assign topical categories.

Please create a page at Commons:Batch uploading for your next upload. This will allow to better coordinate this. -- User:Docu at 20:52, 24 May 2010 (UTC)

The advantage of 'author' is that the translation is standardized, while the the german version of 'depicted person' is not. You might also notice that when this parameter is not set (or blank) the template just ignores the correspond line. So there is no possible confusion.

I also don't want to mess with the translation inside this kind of template, Basically there are two types of information here:

static ones: the title label, the basic description label, the extra description label and possibly the other static information label that won't change within any image of the 'batch'. I don't like the 'batch' word, because the template could be used to provide basic description for pictures not taken by myself in the event. If existing templates can be called to fit those fields, I'd be happy so there is nothing to translate inside the template.
dynamic ones: Any content that can be changed depending the subject of the photograph; Who was photographied? Extra information? For that, the template should not handle the translation, and just takes what is entered: if an mld template is used, all the translation can stay inside the image description level. I'd prefer using the mld template over {{En}} because this allows to hide unwanted language while allowing to check for translation / modifications of logical parts. For the multiple selector issue, try loading this in your favorite *.js related script the following script importScript("MediaWiki:Multilingual description.js")

For now, I consider the mother festival template imperfect, since logically speaking, the author field should be renamed to something less ambiguous, there is also some work needed in adding an extra info rmation field or something like that too, so the basic description gets displayed when adding extra information and not replaced. I managed to fix the mw tool to get rid of the bugs I encountered. So I can take charge of modifying all the templates and files using them that I created. See Category:Festival_Templates, please note that not all use the mother template for now.

Esby (talk) 22:36, 24 May 2010 (UTC)

The translations wont help if "author" isn't the author. If you want to build on {{Information}}, it might be preferable to define an "event"-field for "Other_fields". -- User:Docu at 23:46, 24 May 2010 (UTC)

I have created {{Depicted person}} to replace the label of {{Author}}. I'll replace the usage of the parameter {{{author}}} by its logical counterpart: {{{depicted person}}} Esby (talk) 21:14, 31 May 2010 (UTC)

To avoid increasing the complexity levels of descriptions, would you place {{Depicted person}} directly on {{Information}}? -- User:Docu at 15:57, 4 June 2010 (UTC)

I hope you clearly realizes what this involves and which purpose {{Information}} serves.

To answer shortly, I'd say no. Not all photographs concerns one identified person. Having an identified person (usually a portrait) is a special case.
Now, does this information should get a special field in Information and why? I don't think so. Information is mainly used to feed needed data. Special data can be fed in and outside of it: Geolocation data can be in the description and outside of it. Licence information and or usage restriction (eg {{Personality rights}} can also be in or outside of it. Categories will usually be outside. Image notes will be outside of it. What's the purpose of this? sorting or organize the data? there might be better way to do that with category or with javascript and html tags being reorganised on the client side. Also creating a parameter for a given type of information would mean this information can't be fed from an already existing parameter.

I think you are exagerating a bit the difficulty to edit such template construction. it's the same as using {{En}} template or something like, once you understand that a template can have parameters, most of the difficulty will be gone. I am not saying those people should edit the template of course, but they can at least edit and understand the template parameter calling syntax.Maybe some improvement can be done in separating description prone to be localized from the 'template coding', but it involves following more pages for counter vandalism... Most people think that templates = infoboxes, which is untrue. A template means avoiding retyping some information at least twice. It can have a visual effect or not. Maintenance template that involves categorisation might not have any visual effect for the end user for example.

Esby (talk) 17:03, 4 June 2010 (UTC)

Automatic date categorization

Hi,

This edit got me thinking. Since the Information template uses a way to extract the creation date from the "Date" parameter if in pure YYYY-MM-DD format, wouldn't it be possible to make it categorize into the appropiate Month by year, and Day by month categories automatically? Sometimes the Date-parameter contains a date that is not the creation of the file, (like a non-checked bot move contains the {{Date}}-template with "(original uplaod date") appended, but those aren't matched by the YYYY-MM-DD format thing so that won't/shouldn't be categorised. Greetz, –Krinkle^talk 11:08, 23 June 2010 (UTC)

Please no. We already had this discussion, please check the archives. Multichill (talk) 11:56, 23 June 2010 (UTC)

Sounds like a good idea. In some related discussion, Multichill promised us to do it by bot. As we haven't seen it yet, I suppose we need to find another solution. -- User:Docu at 12:07, 23 June 2010 (UTC)

I think we have to first establish if this corresponds to a need and what we will obtain.

I checked several dates, and the dates in the information field range from the date the object has been created (erection of a building, creation date of very old paintings), over the date that the picture has been taken to the date that the picture has been uploaded. So not a very reliable source of information.
Given the numbers of images on commons and the download speed, we should end up with 20000 pictures per day of the year categories and 100000 images per month/year category, so those categories will become next to unusable.
What can we do to exploit such dates: I don't have a clue
Adding extra categories that serve no clear purpose (some images have already 20 to 30 categories, which becomes a hell to manage) adds only confusion and extra work b(and of course, some people will insert them manually)
What we will need in the long term is additional search switches that allow for a date range selection. So in the long term we will need a mix of our category system and a tag system (dates, type of media, ...). I believe that those dates should be implemented as some sort of tag.
Because adding those categories would have a major impact on all images, there must be a clear definition and a broad support before implementing such a massive change. --Foroa (talk) 16:53, 24 June 2010 (UTC)
- Can you formulate an alternate proposal that could be implemented in one way or the other? -- User:Docu at 18:03, 24 June 2010 (UTC)

Back to the basics:

what dates (object creation, picture creation, upload date) do you want to exploit ?
How can we check we have the intended dates ?
what do you want to achieve with those dates ? --Foroa (talk) 20:58, 24 June 2010 (UTC)

If you look at various ways people add date categories, you will notice that they want to be able to browse images by date, date being generally the one inserted in the information date. A solution suggested earlier, i.e. "use Special:Search/date=" works to some extent, but it doesn't have all the benefits of categories (browse, intersect, related changes, export, find images uncategorized otherwise etc.). -- User:Docu at 08:39, 25 June 2010 (UTC)

summary attribute

I think we should remove this. In HTML 5, it's going to be removed, an I also have never seen the point in using it. --The Evil IP address (talk) 11:47, 25 August 2010 (UTC)

I do not know who (if anybody) uses it. If nobody than I agree.--Jarekt (talk) 12:17, 25 August 2010 (UTC)

Template "eats" other templates.

Why does the information template "absorb" the location template if the location template is placed right after it? For an example, see the first and second versions of File:Parque Quebrada de Macul Santiago Chile 14 Nov 2010.jpg. The first shows it "absorbed" and the second shows it separate. Jason Quinn (talk) 19:33, 15 November 2010 (UTC)

I always thought that was a very nice new feature of this template. Much nicer than the separated version.--Jarekt (talk) 19:57, 15 November 2010 (UTC)

Because there was one line feed added between the two template in the second version. Esby (talk) 20:11, 15 November 2010 (UTC)

Jarekt, I don't know if that's a feature so much as it is unexpected behavior that you happen to like. Having templates interact with other elements of the source is atypical of Wiki-markup and is not behavior that should be encouraged. Templates are logically separate entities. If a user wants the location box to go inside of the information template, they should put it there (or the information template should have parameters for location). It seems very clear to me that this is a high-priority bug with the information template. Jason Quinn (talk) 16:21, 17 November 2010 (UTC)

It's definitely not an high-priority bug: it's only cosmetic and has no real impact on anything and can be fixed by adding a line feed supposed this is really needed. Esby (talk) 20:40, 17 November 2010 (UTC)

Esby, it is not cosmetic because it has a impact on the logical structure of the page. Adding a new line is merely a work-around of which I am already aware. Barring some giant point I am missing, this is clearly undesired behavior (in the grand scope) and should be fixed. [The problem is that the template acts non-locally and causes unexpected behavior. Every and all programmers know this is a terrible, terrible thing.] I'm still curious to know why this is occurring and if the Information template was designed to do this. If need be, I'll eventually decipher the template source myself but I'd rather not spend a few hours doing it if somebody already knows the details. Jason Quinn (talk) 21:34, 17 November 2010 (UTC)

This is merely visual and intented, it looks good! If you look in the source you'll see that the logical structure is correct (table closed, new table). I would say WONTFIX. Multichill (talk) 21:56, 17 November 2010 (UTC)

It is not "merely visual". I wish people would quit saying that. Not only can any rendering bug be called "merely visual", this behavior affects the grouping of information. That is the logical structure of the page. By saying it is merely visual, it's like the semantic content of markup (i.e., the very purpose of markup) is being ignored. Jason Quinn (talk) 23:20, 17 November 2010 (UTC)

(edit conflict) Adding a line-break is useless and is not a workaround. This is the intended behavour. The {{Information}} template has a parameter other_fields which enables adding extra rows (such as for Flickr reviewer and Credit/Attribution). However since some templates are easier maintained seperate it was built in such a way that {{Location}} doesn't have to be passed as a parameter to {{Information}} (which would mean making a loot of edits; and removes the flexibility if we would ever want to seperate them again), so it was done with CSS: When two data-templates (such as Location, Information etc.) are next to eachother they merge into a single box as an extra row. –Krinkle^talk 21:58, 17 November 2010 (UTC)

Adding a line break performs a function: it causes the page to render differently. It is wrong to say that the line break is "useless". Without a guideline saying that the two templates must be next to each other, some editors may prefer the other look. So, if one style is preferred over the other, the current behavior necessitates a new layout rule regarding the Information and location templates. (Where are the layout guidelines for Commons anyway?) If it is true that the behavior was coded into CSS, can you point me to a discussion of that? I cannot think of any other templates that act this way. It seems like a horrible decision. It is another case of making whitespace mean something. In general, whitespace only plays a limited role in the rendering of a page in wiki markup. It also seems to be a decision without regards to the purpose of the logical structure of a document vs its presentation. (I'm assuming the boxes shown are div elements. I'll have to look closer.) Jason Quinn (talk) 23:35, 17 November 2010 (UTC)

For quite a while now Commons community rejected addition of any new fields to Information template. However if any new field is needed it is usually added at the end. That was usually done through cumbersome other_fields mechanism. Adding this new capability of adding fields by having two templates next to each other is a very elegant solution to the old problem and can be very helpful in new template development. Jason, in all this discussion you did not produced any convincing arguments why you think "this is a terrible, terrible thing" that "every and all programmers know" about. It is just more seamless, more elegant visualization. I see no harm and no need to fix anything. --Jarekt (talk) 03:10, 18 November 2010 (UTC)

This behavior clearly violates the Principle of Least Astonishment and the valuable notion of encapsulation. Regarding astonishment, the user has no reason to expect (or even be aware) that the template functions this way. The behavior does not even appear to be properly documented by the template itself. Regarding encapsulation, having the template affect elements other than itself puts more burden on the user to understand the global structure of the page, i.e., it complicates usage. It also makes it more or less impossible to know how the template actually behaves because allowing its behavior to depend on other templates via juxtaposition offers an infinite number of possibilities. Are any of you programmers? Are you familiar with the importance of encapsulation? Do you know the difference between the logical semantic content and presentation in markup? I feel a bit frustrated because it seems like my arguments are not being understood or just missed. I have explained why it's a bad idea, so please don't dismiss me by just saying that "I have not produced any convincing arguments". That feels more like an unwillingness to acknowledge my points and attempt refute them.

There seems to be no guidelines for layout on Commons as far as I can tell. Please correct me if I am wrong. Users can place the location and information templates wherever they choose without guidelines, which, of course, leads to inconsistent pages, which is why guidelines are needed. A layout guideline could in theory solve this problem (well, "sweep it under the rug" is a better description) by requiring the location template (and possibly others) to come directly after the Information template. So, if such a guideline exists for Commons, please present me a link that suggests ordering for the headings and templates. If no such guideline exists, then one of the consequences of rejecting my point of view is accepting inconsistency in the Commons pages. Jason Quinn (talk) 15:18, 18 November 2010 (UTC)

Sorry, but differents syntax lead to different results: there is no inconsistency here. What you advocate as an inconsistency is rather constant: all pages that do not have a line feed between the location and information template will behave the same way, all pages with a line feed will act the same way. Inconsistency here is only introducted by the user choice, not by the template. Commons is not a database in itself, it's a wiki built with template. There are also alternatives existing to the information template. Commons is also multi-lingual, with american and european users (and users from others communities, of course), who don't necessary share the same conception. We don't all necessary agree in the level of regulation needed. Sorry, I can't agree with you: the issue, as already stated, it is only visual. The information is contained into tables, which are perfectly fine as logical structures. Please note that those are also not structured in div elements (th/tr/td are not divs). Technically speaking, there is nothing wrong in the templates: if you don't like what the css are outputting, feel free to create your own css. Esby (talk) 15:57, 18 November 2010 (UTC)

I've looked into it in detail now. As Krinkle stated, is boils down to a CSS thing. It is not semantic as I suspected at first. In particular, when the templates are juxtaposed, .toccolours.vevent selector has an border-top:0 none;margin-top:-8px;padding-top:0; and when they are separated by a line break it has border:1px solid #AAAAAA;;padding-top:5px;. The CSS is being applied in a goofy, hacky way here. (I still haven't discovered how the CSS gets changed if two templates are next to each other or not. There's an insertion of <p><br /></p> associated with the line break but that is all.) Jason Quinn (talk) 17:19, 18 November 2010 (UTC)

Regardless of my complaint about the CSS, the question still remains, where is the guideline for layout on Commons? I cannot find it and am starting to suspect there isn't one. Unless there is a guideline, there is no reason to support the location template being directly after the Information template. Jason Quinn (talk) 17:18, 18 November 2010 (UTC)

Jason, this is a project run by volunteers and since people rarely volunteer to write guidelines and documentations - it often lack them. If you believe more documentation is needed than please volunteer to write it; otherwise do not complain about lack of it. Also I would propose to end this discussion since it does not seem to be going anywhere. --Jarekt (talk) 17:31, 18 November 2010 (UTC)

Guys, it really does help once in a while to directly respond to a person's question. I was asking if such a guideline exists. A good response would be one of the following: A) yes, and here is the link, B) no, it doesn't to my knowledge, or C) I don't know. Bad responses would be snarky comments about how Wiki's work in general and unfair accusations of complaining. The Wikipedia despite being run by volunteers, has more documentation than probably is needed. Commons is apparently far behind the curve. A layout guideline would be a very influential thing that would affect every single page on Commons. This is no easy task. One should have been written very early after the creation of Commons. If one doesn't exist, this is a big thing that really ought to be fixed. This whole discussion can be viewed as a result of a lack of such a guideline. Jason Quinn (talk) 20:17, 18 November 2010 (UTC)

Seriously, could you spare us what you think being a good or bad answer, shortly speaking, bad questions usually result in bad answers.

Here's you are talking of a (possible) policy about the layout of all of the media pages. Frankly the layout is not something that should ever affect how the data are stored. You are also making the assumption that there is only one Wikipedia, which is quite wrong, as the Wikipedias are independant and not necessarily organized like the english Wikipedia. Some people seem to think that Commons only exist to serve Wikipedia, which is quite untrue, since it was also created to be a free media repositery. There are also other wikimedia projets that uses Commons.

We are not talking of a database of files we are going to structure here, we are talking of files described via a serie of template, the principal of these being this template. It is quite obvious that the usage of such template forces the fields it contains to be filled. It quite obvious that the other existing alternative templates also force their fields to be filled. We also have legal information we wants to put, such as the licence information, we usually see at least two practices: wanting to put the licence information in the Information template, wanting to put it separately in a localized licence section. The same is true for the geo-localisation thing, except the geo policies are saying that the geo-templates should not be proxied. It's a recommandation, not an obligation.

Basically, the way the data are shown does not affect their possible automatic extraction, geo localisation tools do not use the strict layout you would want here, but they directly use the presence of geo-links in the db tables. There is also another way of implementing geo-location: giving coordinate to points in the image, resulting in the geo-localisation possibly part of the image annotation process. Similary to the image annotation module, we could have javascripts or page post-processor that would reorganize the content position and layout them for the user to have it always at the same place. We are not going for now to format every image description for now in a python syntax style just to fit a supposed optimal user usage.

Esby (talk) 23:01, 18 November 2010 (UTC)

Esby, I don't know what part of my position I haven't been able to properly explain (or perhaps which part I am misunderstanding myself); but nearly every one of your replies has seemed like it's talking about something else because many of the sentences don't even seem to follow from my comments. For example, in the above, you state, "frankly the layout is not something that should ever affect how the data are stored.". When have I suggested the storage of the data should be changed? As far as I can tell, I haven't. Then you again mention how Commons serves multiple projects as if I don't know that, and as if it matters regarding what I am suggesting. As far as I can tell, it shouldn't. Next you talk about layout (which is what I've been discussing) but quickly move to a paragraph and a half talking about data extraction, which again seems unrelated. I don't know what else to say except we do not understand each other. Jason Quinn (talk) 12:39, 19 November 2010 (UTC)

Several small changes

I've performed them on a copy over here in two edits. See the edit summaries. What do you think ? –Krinkle^talk 01:03, 6 November 2010 (UTC)

This is the diff with the current template. Some points:

Don't like the source/author contstruct. We want explicit information, this makes it implicit (and room for doubt)
Why the lc: and Other_versions? Seems to me you only have to have "other versions" and "other_versions".
Don't care about the td/th as long as nothing breaks and it's correct ;-)

Multichill (talk) 10:03, 6 November 2010 (UTC)

What room for doubt exactly ? I'm not following. This would cause |source=[[User:JohnDoe]]|author=[[User:JohnDoe]] to render like |source={{own}}|author=[[User:JohnDoe]]
Look again, the lc is only for the switch case, not the actual value. It means that both NO, No, no, nO, none, None, etc. are matched in the switch case. No need to add both capitalizations.
I added another edit (diff to my previous version diff to current template) adding a switch case for Permission which was previously hard coded to "See below" by various upload tools thus replacing it with the localized version. (Like is done in Parse source for Own work, and in the switch case for Other_versions to replace "-" and "none" with nothing. –Krinkle^talk 03:23, 7 November 2010 (UTC)

I went ahead and made the following changes:

The switch filter for other_versions is now lowercase to match "NONE" or "None" etc. as well, and added "no" to the list of to-ignore values as it is fairly common for people to treat the upload form as a question ("source ? yes, author ? me, permission ? yes, other versions ? no...)
Changed the "Other versions"-label inside the HTML-coded <tr>-tablerow from <td> to <th>. Reason being that <td> is simply incorrect. TD are cels and TH are headings. The labels generated in the other rows with the exclamation marks generate a TH, so the html-coded version should do the same (and by the way, the reason for the HTML-coding here was to avoid working with {{!}} becuase this is inside a parser function.
Added a switch case for Permission, like is for Other_versions to filter out common null-values and show the internationalized 'See below'-fallback more often instead of "Yes", "No" or "See below" (hardcoded English) etc.

–Krinkle^talk 01:40, 20 November 2010 (UTC)

File:Vie, deteils et peintures de l'eglise de Sion (A).jpg

Can sombody explain what happend her. When the permission line contains the words PD-Art it gives speedy deletion template. Geagea (talk) 02:12, 20 November 2010 (UTC)

Fixed now. Geagea (talk) 02:27, 20 November 2010 (UTC)

Permission Parameter

Could someone please modify the "|permission=" parameter of the template so that the input "see below" outputs "see below"? At the moment, when "see below" is inputted, nothing is outputted (see File:Ducks3800ppx.jpg). -FASTILY ^(TALK) 20:50, 25 November 2010 (UTC)

Done --Mormegil (talk) 11:11, 26 November 2010 (UTC)

Location

Years ago there was many times proposed that location coordinates should be integrated directly into this {{Information}} template (see this discussion as an example]. The current form that the output of {{Location}} template is visually stuck at the bottom of {{Information}} but not really integrated is not a real and definitive solution but only a cosmetical masking.

Camera location (and object location) coordinates means WHAT and WHERE was photographed. This information has a close relation to the "Description" parameter which means also WHAT and WHERE was photographed. The verbal description and the location coordinates shape together one integral entity.

Several users prefer a rational grouping of information and insert the {{Location}} template into the "Description" field (see this edit by user:Pigsonthewing, this request from February 2009 or files uploaded by myself) even thought this template isn't graphically fully adjusted for this place. Some other users prefer the place at the bottom of Information template because it "looks better". I think, the informative purpose of templates is primary and their graphic form should by adjusted to it.

Can we achieve some better solution which will satisfy both aesthetic and logical pretension? And what should be Commons policy now? Should we respect both possibilities? Should be one of them preferred, considering future? What a stand should be taken toward edit wars about it? --ŠJů (talk) 23:37, 1 December 2010 (UTC)

I really think this is a good idea. Merging all the related templates at {{Location}} is also possible with a little more work. Rehman 01:00, 2 December 2010 (UTC)

Sounds sensible to me. — Cheers, JackLee ^–talk– 10:47, 2 December 2010 (UTC)

There are not few ways we can do this:

Add extra fields to the Information templates, like Location for TEXT description of the photograph location, something to show coordinates which would look like {{Location}} template, etc.. This idea was quite unpopular in the past, many people proposed it over the years and it was always rejected.
Write and use other templates with those fields. We can write for example a {{Photograph}} which would be identical to {{Information}} exept it would have some extra fields.
One possible solution, inspired by Template "eats" other templates discussion above. would be to split {{Information}} into 2 sub templates {{Information/Description}} and {{Information/Meta}}. The code of {{Information}} would become to call first one and then the other subtemplate. That would allow us to write other templates by putting some other fields in between those 2 subtemplates. We could use this technique to rewrite {{Infobox aircraft image}}, {{Bus-Information}}, {{Information2}} and other similar templates.

--Jarekt (talk) 15:08, 2 December 2010 (UTC)

Personally, I don't think there is a benefit in adding an extra field in the information template for the coordinates. {{Location}} already isn't easy, having

{{Information
|coordinates={{location|1|31|23|13}}
}}

just complicates things. Docu at 04:41, 3 December 2010 (UTC)

RTL

Today I checked something with this image in Hebrew and was surprised that all templates switched nicely to RTL with excecption of the information template. Any idea how to fix this? Raymond 16:43, 13 December 2010 (UTC)

Should be fixed now. It broke here because the parameter "lang" is undefined in the newly introduced design of the template. It would have been necessary to replace it with "{{int:Lang}}". --Slomox (talk) 23:30, 13 December 2010 (UTC)

Thanks a lot for the quick fix. Raymond 10:07, 14 December 2010 (UTC)

Opps, {{Creator}} and {{Book}}, which were lately changed to use translatewiki, needed the same edits. --Jarekt (talk) 12:48, 15 December 2010 (UTC)

Few small changes

...needs to be made. Please see this discussion. Could someone do it? Please reply there for any objections. Thanks! Rehman 10:46, 2 December 2010 (UTC)

What exactly do you want to change in this template? Please make an example in a sandbox and provide a diff. Multichill (talk) 11:05, 2 December 2010 (UTC)

Seems like more to do with the doc page actually. To change the content to copy to look exactly like:

{{Information
|Description    = 
|Date           = 
|Source         = 
|Author         = 
|Permission     = 
|Other_versions = 
}}

A small change compared to the content being discussed at the link provided. Rehman 11:28, 2 December 2010 (UTC)

I see three changes in this proposal.

I prefer the current version, i. te. the succession: "description – date - source - author - permission - other_versions", not return to the succession "desription - source - date - author - permission - other version".
I support unifying of capitalization. i. e. all letters lower - or all first letters capital.
I prefer the constricted version (without spaces), but the aligned version can be also used and tolerated.

--ŠJů (talk) 22:16, 12 December 2010 (UTC)

As the output is "description – date - source - author - permission - other_versions", the preferred version of the input should be the same. -- Docu at 06:42, 13 December 2010 (UTC)

Yes, I agree, that is by mistake. I have changed it accordingly. Kind regards. Reh man 12:05, 18 December 2010 (UTC)

Hiding information more than 2 or 3 lines

There is a serious issue with this template at present where information over 3-5 lines in Description and more than 2 lines in Sources disappears. You can see that the information is still there when you go to the edit tab but it actually doesn't appear on the file pages. Please fix this! To see the issue in action look at this file and compare what you see on the file page with the information actually there that is hidden by going to the edit tab. Please fix this because it is hindering the ability for many Wikis to use files they could be using resulting in people uploading duplicates without meaning to because they don't know the file already exists but is hidden in their language. Maps & Lucy (talk) 02:08, 17 December 2010 (UTC)

Lang not corresponding to the language selector (behind the image) are not displayed, it's a feature to reduce the babel effect. Esby (talk) 13:00, 17 December 2010 (UTC)

What you have just posted makes utterly no sense! Could you refraze it please? (By the way I fixed the language issue so now all five languages are showing and doing so properly on both images I was working on but the source section is still screwing up and you didn't say anything about that.) Maps & Lucy (talk) 15:37, 17 December 2010 (UTC)

I think this problem is related to this discussion and to Meta:Language_select. It is messing up a lot of pages where some text is and some is not labeled with what language used. To fix it add "ls_enable = false;" to your vector.js file. However more permanent fix would be better. --Jarekt (talk) 15:42, 17 December 2010 (UTC)

I fixed some time ago the bug you are referring to Jarekt. I also don't see anything wrong in the source section. The 'ls_enable' parameter has no impact for now. I'll try to fix that so people can deactive the script if they want to. Esby (talk) 16:43, 17 December 2010 (UTC)

Thanks --Jarekt (talk) 19:40, 17 December 2010 (UTC)

Hi again guys, I don't know whether any of you did anything with the template or not but I got the sources where I wanted them and was able to make all the translations appear! It's all good now!

Done

other_fields does not work correctly when other_versions is present

Hi,

File:Szczyrk.1.jpg and File:7 Warszawa 293.jpg use the same "Credit Line" other_fields value; however in the second file this field does not show properly. After some testing I figured out that the difference is presence of {{Derivative versions}} in other_versions field. Somehow that template in that field messes up other_fields mechanism. Does anybody know how to fix it? --Jarekt (talk) 19:14, 3 January 2011 (UTC)

Option to make "description" optional. ?

It seems that everybody agrees at template talk:artwork that it could useful to combine an {{Information}} with an {{Artwork}}. The result would be something like File:Sèvres Jeune fille trayant une vache.jpg. However, in many cases (like the one mentioned), the description parameter of information is not useful, as the description is already given in the artwork template. Would it be possible to make the "description" parameter optional for people who consciously elect not to use it ? Making the description parameter option by default does not seem a good idea, but it could be useful if users had th option to turn off the parameter. {{Artwork}} does this through a "strict" parameter, could something similar be done here ?--Zolo (talk) 10:05, 28 December 2010 (UTC)

Just like "infoboxes", this template could actually be merged with everything else; using just the fields needed for each file. Don't know why this is not the case at Commons... Reh man 12:00, 28 December 2010 (UTC)

I thought {{Artwork}} had a photographer field would make {{Information}} unneeded. -- Docu at 12:24, 28 December 2010 (UTC)

Yes there is a photographer parameter, but for long descriptions, it looks clearer to separate artwork from photo infos. Beside, photo only has "source/photographer" while information has both "source" + "author". In many cases artwork only needs source -so actually author should be made optional too- but in other cases, I tend to think it would be better to include an information part in artwork, which would harmonize things.

And yes I agree something similar could be done for minerals, ships and many other things.--Zolo (talk) 13:42, 28 December 2010 (UTC)

In addition, wasn't one of the reasons why {{Artwork}} was renamed that it could fit sculptures too? -- Docu at 19:16, 28 December 2010 (UTC)

Support may be something like "strict" parameter in {{Artwork}} which is on by default ("strict=1") but can be turned off by "strict=".--Jarekt (talk) 21:22, 28 December 2010 (UTC)

{{Edit request}} There seems to be consensus on this point, can anyone edit the template ?--Zolo (talk) 08:05, 5 January 2011 (UTC)

I don't agree, we shouldn't mix templates like this. If you use information you should always add a description. Information is now a straightforward templates without bells and whistles, we should keep it that way. Multichill (talk) 10:55, 5 January 2011 (UTC)

Why shouldn't we mix templates like this ? I have used {{Artwork}} quite a lot and I can tell you that it would often be better to use {{Art Photo}} and in this case, "description" is often unneeded. Certainly when {{Information}} is used alone, description is needed, but since it would still be required by default I don"t see any downside in the "strict" parameter.--Zolo (talk) 08:50, 6 January 2011 (UTC)

@Multichill: Is it an absolute opposition ? Quite a few people think {{Art Photo}} would be convenient, and the obligation to provide a description in {{Information}} seems to be the obstacle to its use. --Zolo (talk) 09:55, 13 January 2011 (UTC)

Empty Permission field shouldn't be displayed

{{Edit protected}} According to the answer from Raimond Spekking in Bugzilla: License tags for Commons should be located to the Information box defaultly, the "Permission" field should not contain license templates but OTRS ticket or similar. Therefore it is illogical, senseless and very unsightly to display also the empty field with the default content "See below", what regards a license template below. The field should behave in the same way like "other_versions": it should not be visible so far as no content is present. --Petrus Adamus (talk) 21:19, 1 January 2011 (UTC)

I do not know who "Raimond Spekking" is and why would he be an authority on how to use Permission field. Here at Commons many people like to use this field for licenses and I do not see any problems with this. --Jarekt (talk) 21:28, 1 January 2011 (UTC)

Yes, I would personally also prefer to place the license templates there. Because I had considered useless and unsightly to place the templates under the {{Information}} infobox and indicate there "See below", in [1] I suggested to modificate the automatic upload script (Special:Upload) so as it placed the template to the infobox. Nevertheless, nothing was really executed. I don't think multiple license templates in {{Information}} look ugly, nevertheless linking by "See below" in the contrary.

Because I received the answer in Bugzilla and so seems to me, probably never would the templates be automatically placed to the infobox (the best solution), I consider removing of the empty fields the second best solution. --Petrus Adamus (talk) 22:11, 1 January 2011 (UTC)

Not done for now. Please discus this first. Get consensus, etc etc and than come back here with an edit protected request.

Raimond Spekking is User:Raymond btw. Multichill (talk) 22:32, 1 January 2011 (UTC)

@Jarekt: It's me. I have no authority to say how to use the permission field. If anyone wants to use this field for the license, he should do. I personally prefer to add the license in a separate section and it is the default by MediaWiki and the extensions (UploadWizard, AddMediaWizard). The bug in Bugzilla cannot be solved because {{Information}} is not MediaWiki standard but Wikimedia Commons (and other Wikipedia) specific. In my understanding the permission field shall be used to OTRS templates and similar. IMO the permission field can be hidden in case no OTRS template and no license was added in this field. The default text "see below" seems uselss for me. Raymond 22:48, 1 January 2011 (UTC)

To me having the license inside "permission" is clearer than having it in another section. Having an OTRS ticket at permission and the license elsewhere can be confusing - especially now that the field is displayed as "Permission (Reusing this file)". I don't like long license tags inside the info box but it could be fixed through cosmetic changes to license tags and/or to {{Information}}.

I have mixed feeling about removing the "see below". It is not always very clear (we have to look for the "below"). But on the other hand, it reminds users that they should pay attention to copyright issues.--Zolo (talk) 09:56, 2 January 2011 (UTC)

Well, in that case, what about setting the automatic upload script (Special:Upload) for locating the license templates to the infobox (field Permission), which looks much better, as suggested also at the Village pump in January 2009? Who can eventually do such a change to the script and who should approve it? --Petrus Adamus (talk) 10:06, 2 January 2011 (UTC)

For a consistent usage in future MediaWiki core and some extensions have to be changed, reviewed and deployed by Wikimedia staff. And I assume this will not be done w/o a broad consensous of the Commons community.

Personally I do not like it because it looks very overburden, especially in case of multi licenses (cc-by-sa-3.0 and GFDL). Raymond 10:42, 2 January 2011 (UTC)

Also the Description can be very long: is it a good reason to place the description out of the infobox and write for instance see above to to the field? In my opinion, if we have some special field, let's use it. If we do not want to use it, let's not to display it empty, with a reference to a template outside. --Petrus Adamus (talk) 10:58, 2 January 2011 (UTC)

Fair argument. I can live with both variants. I like consistency and an issue I wants to avoid: MediaWiki core and extensions upload file with the current behaviour and the next bot shifts the license template. This a bit of counterproductive. Raymond 11:05, 2 January 2011 (UTC)

I have always thought that "Permission" meant license and I have used the template that way for years and advocated that use too. And I know that many other Commons users did it the same way. Today after reading this discussion and Raymond's argument I checked the history. The template was created on April 6 2005 by Arnomane. The first edit that ever used the template was [2]. It shows that the template was not meant to be used that way. The parameter was indeed meant to be permission only. However, today there are tens of thousands or even hundreds of thousands of files that have license information in the permission parameter. It's only logical to have that information in a parameter when we have all the other file information in parameters.

Perhaps we should create an additional parameter "license" if we want to keep it separate from "permission"? If we put the license information in a separate parameter we could even keep the current layout with the license under a new header below the table. The header would then be served from within the template depending on the content of the "license" parameter. We would gain the additional freedom of changing the layout in the future with a single edit instead of 7 million edits. --Slomox (talk) 17:15, 2 January 2011 (UTC)

I do not think we should have "Permission" and "License" for me they are interchangeable. When we had dozen of book templates some of the used "Permission" and some "License" so after the merger {{Book}} uses both to mean the same. As for not showing empty "Permission" field, I guess I would be fine with that: "See below" is kind of silly. --Jarekt (talk) 04:06, 3 January 2011 (UTC)

I can see three different suggestions in the discussion:

Automatically locate the licence templates to the Permission field.
Create an apart Licence field and automatically place the licence templates there.
Put the licence templates bellow the {{Information}} infobox, but not to display an unfilled Permission field with the notice see bellow in such a case.

How can we decide which of these solutions should be implemented? By a voting? And who is eventually capable and competent to execute the change in the upload script? --Petrus Adamus (talk) 19:42, 3 January 2011 (UTC)

You forget one: Keep the current situation. It's just fine. Multichill (talk) 10:57, 5 January 2011 (UTC)

It does not seem to me from the discussion that most users think it's fine. --Petrus Adamus (talk) 14:28, 5 January 2011 (UTC)

I don't think it's all that bad -- if templates are not present inside the Permission section, then they need to be somewhere lower on the page, and if not the text is an indication that they are missing. I would not support adding a new field; if templates are going to go inside the Information template, the Permission field is fine (though some images have a bunch of them piled up, which is why I do sometimes put them outside the Information template myself). Also, there are many existing pages which may have assumed that the text would show up, so I would not like to change assumptions on them. I could see adding an explicit parameter value to hide the permission field though, so that it could be done if desired -- sounds like there are some situations where it is superfluous. Carl Lindberg (talk) 15:38, 5 January 2011 (UTC)

Well, could somebody better oriented in Commons organise a general discussion to can gain the broad consensus of the Commons community that Raymond requires to do any change? I do not now where it should occur. Thanks, --Petrus Adamus (talk) 10:54, 22 January 2011 (UTC)

To iniciate a wider discussion, I added the topic to the Village pump. --Petrus Adamus (talk) 22:37, 22 January 2011 (UTC)

Could an administrator at least set the template not to display an unfilled Permission field with the notice "see bellow"? It's apparently senseless. --Petrus Adamus (talk) 08:09, 26 January 2011 (UTC)

It seems to me that everyone neglects the problem, even including the administrators, that require a wide discussion to execute any change (duly justified) but do not participate in the discussion at the Village pump themselves. Perhaps in several years the situation will improve. --Petrus Adamus (talk) 13:46, 7 February 2011 (UTC)

Template does not "eat" other templates anymore

The mechanism of "merging" Information template with some templates following it discussed to death above does not seem to work anymore, see for example File:Vindicat atque Polit.JPG. Is it intentional? --Jarekt (talk) 19:19, 3 January 2011 (UTC)

I guess someone just broke it. Multichill (talk) 10:55, 5 January 2011 (UTC)

I remember seeing this a few days ago. Not sure how (it was late..) but I fixed it. –Krinkle^talk 14:01, 13 January 2011 (UTC)

Yey :) --Jarekt (talk) 20:02, 13 January 2011 (UTC)

Source field

What should stay in the Source field, if the file is created by a friend and that gave it to me? Should his name be embedded in the Information infobox twice (author and source)? --Petrus Adamus (talk) 08:42, 8 May 2011 (UTC)

Yes and you need to store the permission in OTRS. Multichill (talk) 09:05, 8 May 2011 (UTC)

No aliases

My last edit to this template added a "desc" short version for the description parameter, but was reverted by User:Multichill with the comment "no aliases please." I did search this discussion page and its archives before doing the edit, and found no discussion about this. So, could you explain what the problem is? My intention was to make it easier to manually indent the code for readability (I do that a lot as a secondary change when I'm editing an image page, and many templates and scripts do that as well), so that instead of having

 {{Information
   |Description    = 
   |Source         =
   |Author         = 
   |Permission     =
   |Other versions =
 }}

We could instead have

 {{Information
   |Desc   = 
   |Source =
   |Author = 
 }}

(With the other parameters having the default values, see below and nothing, respectively). This makes it much easier to clean the code, and has no drawbacks since the current behavior is preserved.

In fact, we already do have an alias for Other_versions (without the underscore) and all of the parameters have upper and lowercase versions. So I really don't understand the rationale behind the revert and would like a more detailed explanation, please. Waldir ^talk 12:43, 3 July 2011 (UTC)

A lot of tools and bots parse informations out of this template, you would knock-out a lot of them whit this unnecessary change.--Luxo 20:18, 6 July 2011 (UTC)

These tools and bots (which, btw?) certainly already have code to support aliases for the variants that already exist in this template, so adding support for an extra one would be trivial. I don't think this is such a deal-breaker. --Waldir ^talk 17:36, 8 July 2011 (UTC)

Well I have some tools ([3], [4], [5]) which parse informations from this template, but there are others too. Of corse it's not a big thing to change that, but the effort is much bigger than the benefit. And if you use all fields it's there is no difference.

{{Information
   |Desc           = 
   |Source         = 
   |Author         = 
   |Permission     = 
   |Other versions = 
}}

For me there is no difference for the readability, after this change you still have to indent the code.--Luxo 14:30, 9 July 2011 (UTC)

Precisely: as you said, there isn't much difference if you use all fields. But most of the time other versions isn't needed, and permission can keep its default value, "see below", with the licensing info in the "Licensing" section. So the two longest parameters are optional more than 50% of the time (at least from my experience), which makes this change worthwhile, imo. --Waldir ^talk 19:18, 9 July 2011 (UTC)

Well I can't see the benefit. You don't have less work (You still have to indent the code), It does not imporve the readability, it just make more work if you add the "other versions" parameter you have to indent the code more.--Luxo 13:30, 10 July 2011 (UTC)

The less aliases the better. Some of the templates with a lot of aliases are much harder to read. --Jarekt (talk) 22:00, 6 July 2011 (UTC)

Sure, but this is not a proposal to add an alias just for the sake of doing it. There was a reason behind the change, which I explained above. If reasons don't count, then no aliases should exist whatsoever. If they do (which I naturally assume to be your position), then please let me know why you disagree with this particular one. --Waldir ^talk 17:36, 8 July 2011 (UTC)

Yep, in a perfect solution no aliases should exist at all. We do support some for historical reasons, but there is certainly no reason to introduce new ones. If you have to use it a lot and want to save the extra work to type it out every time, then create a script for it. --Slomox (talk) 18:58, 10 July 2011 (UTC)

Agree. copy-and-paste works fine too. -- Docu at 19:00, 10 July 2011 (UTC)

Nested Information template

Is this template correctly used in File:Polenabzeichen.jpg ? If no, are there other cases where any template is correctly used nested into itself ? -- Juergen 91.52.147.106 19:59, 19 September 2011 (UTC)

Nope, that's just a sloppy transfer. Multichill (talk) 21:28, 19 September 2011 (UTC)

Thank you. -- Juergen 91.52.145.217 07:39, 20 September 2011 (UTC)

Poblems with lists

When with "*" a list is startet in either |Permission=* or in |other_versions=* the template generates a break of the frame and becomes somehow asynchronous.

"*" in other_versions throws other_fields out of the frame:

outthrown

DescriptionInformation/Archive 3	English: test Deutsch: Test
Date	2011-10-15
Source	Own work
Author	any
Permission (Reusing this file)	self
Other versions	test

"*" in Permission generates a new frame entry, and concatenates then all the following:

fields

DescriptionInformation/Archive 3	English: test Deutsch: Test
Date	2011-10-15
Source	Own work
Author	any
Permission (Reusing this file)	permission
Other versions	versions

It differs when other_versions contains no "*" and finds no end anymore:

fields

DescriptionInformation/Archive 3	English: test Deutsch: Test
Date	2011-10-15
Source	Own work
Author	-- sarang사랑 10:07, 15 October 2011 (UTC)
Permission (Reusing this file)	permission
Other versions	versions

next line

-- sarang사랑 10:07, 15 October 2011 (UTC)

We have the same issues with other templates. Bullets as template parameters often give bizarre results that do not seem to follow logic. Some of the issues were explored in Template:Artwork/testcases; however I think there were less problems with those when I looked at that page last time. I wonder is some of those issues are due to new software version. --Jarekt (talk) 02:39, 16 October 2011 (UTC)

LTR div

{{editprotected}} Please change "| #default = {{{permission|{{{Permission|}}}}}}" to "| #default = <div dir="ltr">{{{permission|{{{Permission|}}}}}}</div>" to make it display nicer for RTL interface, because it's mostly in English or other LTR languages. It would also be good to get rid of direction: {{Dir|{{int:Lang}}}};" (first line) and use a CSS class through MediaWiki:Common.css instead. Template:Dir should not be needed. Thanks, SPQRobin (talk) 21:46, 11 October 2011 (UTC)

I added your proposed change to {{Information/sandbox}}. Can you create a couple examples in {{Information/testcases}} to show the difference between current and proposed behavior? Also can you (or someone else that know how) change the code to replace {{Dir}} with CSS class. I am not sure how to do that. --Jarekt (talk) 02:16, 12 October 2011 (UTC)

Ok, I added some examples to that page: when it uses the default text, it follows user language direction, otherwise it is most likely LTR. As for replacing {{Dir}} with CSS, never mind that, because I realised that the CSS needs to work on external wikis as well, which are mostly running a pre-1.18 version. In the long term this should be changed however. SPQRobin (talk) 12:59, 12 October 2011 (UTC)

Looks good. I will wait a day or two and change it. --Jarekt (talk) 14:47, 12 October 2011 (UTC)

Done --Jarekt (talk) 12:34, 14 October 2011 (UTC)

Change reverted due to problems with templates. See {{Information/testcases}}. --Jarekt (talk) 13:11, 14 October 2011 (UTC)

This is a very strange problem... I can't find the cause. Well I suppose we have to leave it as it is then. SPQRobin (talk) 00:56, 17 October 2011 (UTC)

Other_field_1

I would like to propose to add a new parameter Other_field_1 similar to Other_field and the same as {{Artwork}}'s Other_field_1. The purpose of it would be to allow adding other fields below Description field rather than the bottom of the template. See the code in {{Information/sandbox}} and test in Template:Information/testcases#Test_Other_field_1. This would allow us to rewrite {{Infobox aircraft image}}, {{Bus-Information}}, {{Rolling Stock-Information}} and possibly many others to use {{Information}} as their basis and simplify maintenance of those templates. It would also allow users to add additional description fields in more logical location. See for example File:Kyushu Electric tram 3.jpg with additional "location" field located on the bottom. The change will not affect any files currently using the template. --Jarekt (talk) 14:47, 12 October 2011 (UTC)

Done --Jarekt (talk) 12:34, 14 October 2011 (UTC)

Change reverted due to problems with above change. --Jarekt (talk) 13:15, 14 October 2011 (UTC)

Ok, I wonder if something changed in he mediawiki software. See the message below and I thing there are more issues with {{Artwork/testcases}} than I remember last time I have seen it.--Jarekt (talk) 01:07, 17 October 2011 (UTC)

Adaption of "Urheber / Rechteinhaber" at "author"

As it is at de:Template:Information, the field "author" is given as "Urheber bzw. "Nutzungsrechtinhaber" (translation: "author or copyright-owner") it should be here, too (instead of "Urheber" alone). Even if it is not a huge numbers of files, but there are some times, not the author should be credited but the copyright-owner. Change should be for german version. --Quedel (talk) 20:45, 8 November 2011 (UTC)

Shouldn't the author always be credited, per moral rights? Secondly, the term of copyright is often based on the life of the author, regardless if the copyright was transferred to other entities. Carl Lindberg (talk) 20:48, 8 November 2011 (UTC)

The standard Information template is never a perfect fit for everybody, but rather a golden middle. In case when copyright-owner is known and should be listed than one can add "Copyright-owner: John Doe" to the author field. I also do not know if we are interested in the name of the copyright owner so much as to list it at all. --Jarekt (talk) 01:24, 9 November 2011 (UTC)

New version of the template

I rolled out the new version of the template as agreed on in Commons:Village_pump/Archive/2012/02#Request_for_comments_about_some_changes_in_template:Information discussion, and as discussed above. It has:

change from mix of wiki-tables and html-tables to just html-tables
additional other_field_1 parameter similar to same parameters in {{Artwork}}
permission field will not be shown if it is unused

--Jarekt (talk) 14:27, 13 February 2012 (UTC)

File:Troglodytes musculus Esteros del Iberá 3.jpg — revert Krinkles revert at MediaWiki:Filepage.css? -- RE rillke questions? 14:43, 13 February 2012 (UTC)

Makes sense to me but I do not know much about MediaWiki:Filepage.css --Jarekt (talk) 14:51, 13 February 2012 (UTC)

Now we have the Commons:Reuse link only available via JavaScript. I noted in the VP discussion "Maybe the Commons:Reuse link can be shown in the "author" field if permission is empty?" What do you think? Or where else can we display it? Or is the page irrelevant anyway? --Saibo (Δ) 18:36, 13 February 2012 (UTC)

Edit request (permission space duplication)

To resolve the permission space duplication, please substitute:

{{ #if: {{{author|{{{Author|}}}}}} | {{{author|{{{Author|}}}}}} | {{Author missing}} }}
|- valign="top"
! style="background: #ccf; text-align: right; padding-right: 0.4em" id="fileinfotpl_perm" | {{int:wm-license-information-permission}}<br /><small>([[{{int:wm-license-information-permission-reusing-link}}|{{int:wm-license-information-permission-reusing-text}}]])</small>
|
{{ #if: {{{permission|{{{Permission|}}}}}} | {{#switch: {{lc:{{{permission|{{{Permission|}}}}}}}}
 |  
 | yes
 | see below
 | see below. = {{int:wm-license-information-permission-see-below}}
 | #default = {{{permission|{{{Permission|}}}}}}
 }} | {{int:wm-license-information-permission-see-below}} }}{{#switch: {{lc:{{{other_versions|{{{Other_versions|{{{other versions|{{{Other versions|}}}}}}}}}}}}}}
|   =
| - =
| no = 
| none =
| #default = <tr valign="top"><th style="background: #ccf; text-align: right; padding-right: 0.4em" id="fileinfotpl_ver">{{int:wm-license-information-other-versions}}</th><td>
{{{other_versions|{{{Other_versions|{{{other versions|{{{Other versions|}}}}}}}}}}}}</td></tr>}}

by

{{ #if: {{{author|{{{Author|}}}}}} | {{{author|{{{Author|}}}}}} | {{Author missing}} }}{{#switch: {{lc:{{{permission|{{{Permission|}}}}}}}}
| =
| #default = <tr valign="top"><th style="background: #ccf; text-align: right; padding-right: 0.4em" id="fileinfotpl_ver">{{int:wm-license-information-permission}}<br /><small>([[{{int:wm-license-information-permission-reusing-link}}|{{int:wm-license-information-permission-reusing-text}}]])</small></th><td>
{{{permission|{{{Permission|}}}}}}</td></tr>}}{{#switch: {{lc:{{{other_versions|{{{Other_versions|{{{other versions|{{{Other versions|}}}}}}}}}}}}}}
|   =
| - =
| no = 
| none =
| #default = <tr valign="top"><th style="background: #ccf; text-align: right; padding-right: 0.4em" id="fileinfotpl_ver">{{int:wm-license-information-other-versions}}</th><td>
{{{other_versions|{{{Other_versions|{{{other versions|{{{Other versions|}}}}}}}}}}}}</td></tr>}}

Thanks, --Petrus Adamus (talk) 17:05, 20 January 2012 (UTC)

Can you explaing what is the problem you would like to fix by this change? Also, before we change a template used on so many pages can you implement it in {{Information/sandbox}} first and provide some examples in template:Information/testcases. That would be a great help.--Jarekt (talk) 18:14, 20 January 2012 (UTC)

The problem is that the Permission field is displayed even if the item hasn't been filled out and a licence template is placed below, with the text see below, which is barely useful, rather senseless and unsightly. The field should behave in the same way like other versions: it should not be visible so far as no content is present. See the sandbox and discussion. --Petrus Adamus (talk) 20:04, 20 January 2012 (UTC)

Looks good to me. I would propose to wait a day or two to make sure everybody sees it before implementing. --Jarekt (talk) 20:38, 20 January 2012 (UTC)

Sound good to me too. Since it is not advised to change this template too often, maybe we could take advantage of this edit to switch from wikitable to the plain html of Template:Information/draft--Zolo (talk) 21:16, 20 January 2012 (UTC)

What would be the reason for switching to plain HTML? --Leyo 22:59, 20 January 2012 (UTC)

Template:Information template is the least updated template, and as other similar templates like {{Artwork}} and {{Book}} are being improved from time to time this one goes through much fewer improvements. As a result Template:Information uses a strange mix of wikitables and HTML tables while all other major templates use HTML style tables. Also since Template:Information is written in a different style than most other templates, the {{Information field}} template has to have two flavors one for insertion into Template:Information and one for insertion to all other templates. For those reasons, I support Zolo proposal, but would like to hear some more opinions. --Jarekt (talk) 04:21, 21 January 2012 (UTC)

I support it, the mix is a bit labyrinthine. --Petrus Adamus (talk) 10:25, 21 January 2012 (UTC)

Let's improve the version at {{Information/sandbox}}. For eventual HTML version, the template {{Information field}} and maybe some other ones require adjustment. --Petrus Adamus (talk) 20:37, 21 January 2012 (UTC)

Not done right now. Please sandbox first. Multichill (talk) 21:23, 21 January 2012 (UTC)

Petrus Adamus, I moved {{Information/draft}} to {{Information/sandbox}} and definitely will do some testing before roll-out. One way of testing can be to change a few Category:Infobox templates: based on Information template to use {{Information/sandbox}} instead of {{Information}} and go trouogh many files using given template. I tried it for example with {{Information2}} --Jarekt (talk) 05:02, 22 January 2012 (UTC)

Please, unify the vertical alignment of the left and right column of the template. --Petrus Adamus (talk) 06:54, 22 January 2012 (UTC)

There is an problem with text content versus templates: for box templates, the parameter (ex. {{{permission|{{{Permission|}}} }}} requires an own line. Nevertheless to obey the vertical alignment definition, it has to be immediatelly between the tags <td></td>. I do not know how to sort it out. --Petrus Adamus (talk) 15:45, 22 January 2012 (UTC)

I was just trying to fix the case when text uses * bullets and in case of permission and other versions. For those the parameter (ex. {{{permission|{{{Permission|}}} }}} requires an own line. Petrus, can you add a test case when this is a problem?--Jarekt (talk) 19:18, 22 January 2012 (UTC)

At Permission field, it could be maybe "solved" by omitting text information there and using licence templates (althoug always some contributors will ignore it), but the other fields should definitely work with text properly – and unfortunatelly with templates too. Also bullets are aligned too low, but it is not such a big problem as for text, the visual impression isn't so bad. --Petrus Adamus (talk) 20:21, 22 January 2012 (UTC)

I temporarily redirected {{Flickr}} to use {{Information/sandbox}}, in order to test proposed changes using ~30k images. I also protected {{Information/sandbox}} for a week, so someone does not accidentally brake it while 30k images use it. Can others also look at files using {{Flickr}} (and {{Information/sandbox}}) and let me know if the proposed changes cause any issues? I will do the same. --Jarekt (talk) 12:32, 24 January 2012 (UTC)

It is strange there are no problems with templates based on a wiki-table more, even in well aligned fields (description, date, source, author): see Template:Information/testcases#Possible_problems. Have you modified anything regarding that? --Petrus Adamus (talk) 16:27, 24 January 2012 (UTC)

Petrus, sorry that last message was not clear. Are you saying that you were expecting more issues with templates in fields of {{Information/sandbox}}? --Jarekt (talk) 03:42, 25 January 2012 (UTC)

No, I am wondering why the one-line code <td>{{{parameter|}}}</td> (which enables nice alignment) works correctly (even with templates based on wiki-tables) in the fields description, date, source, author but not in the fields permission and other versions. --Petrus Adamus (talk) 13:35, 25 January 2012 (UTC)

I do not know that. In {{Artwork}} and {{Book}} all tags are in their own line. I looked through a lot of images transcluding {{Flickr}}, which temporarily uses {{Information/sandbox}} and all the images look fine. I think I am ready to deploy this version, soon. --Jarekt (talk) 20:03, 26 January 2012 (UTC)

Done --Jarekt (talk) 13:31, 27 January 2012 (UTC)

Location as separate table now

Comment directly relating to the above tweak: Dropping the permissions field when not used is sensible. However, one drawback is the interaction of {{Information}} and {{Location}}. The previous arrangement merged the two templates - so the location details appeared as an extra parameter, with it all neatly flowing in one table (even though it was two templates). Now, they are appearing as two seperate tables, with an unappealing seperation of the location from the rest. Presonally, I'd prefer to have the location data integrated rather than more consistent coding (you can see the first, you can't the second!).--Nilfanion (talk) 13:58, 27 January 2012 (UTC)

Indeed (example). --Leyo 14:04, 27 January 2012 (UTC)

I dont think this is related to the permission field: the permission field is above other versions, so it should not be related. It may be related to the syntactc changes (dropping the wikitable). But I am not sure about what has really changed. When I try to use {{Location}} with the previous version of {{Information}}, I get the same layout as now.--Zolo (talk) 14:18, 27 January 2012 (UTC)

I agree that visual merging of {{Information}} and {{Location}} is desirable and we should try to restore it. That effect was achieved not by changing the template but by some display settings. Maybe someone more familiar with those can help. --Jarekt (talk) 14:52, 27 January 2012 (UTC)

It seems to me that User:Krinkle was the most familiar with it in last 2 discussions here and here. I will ask him. --Jarekt (talk) 14:57, 27 January 2012 (UTC)

From what I can see this is fixed now. The issue was unrelated to the {{Information}} update. Caused by a bug in the software (MediaWiki:Filepage.css wasn't loaded). –Krinkle^talk 18:49, 27 January 2012 (UTC)

Thanks --Jarekt (talk) 18:56, 27 January 2012 (UTC)

Then, please rollback this edit. Thank you. -- RE rillke questions? 20:25, 27 January 2012 (UTC)

Are now all {{Information}}-like templates (artwork, ...) using an outer <div class="hproduct"> ? -- RE rillke questions? 16:35, 27 January 2012 (UTC)

Yes, {{Information}}, {{Artwork}} and {{Book}} do (for more on <div class="hproduct"> see [6]). Other templates like {{Institution}} and {{Creator}} use <div class="vcard">. See Template_talk:Artwork#Problem_with_microformats_in_artwork_template for a discussion about microformats. --Jarekt (talk) 16:57, 27 January 2012 (UTC)

Loss of "Reusing this image" link on many files

The last change resulted in a loss of the formerly automated display of "Reusing this image" below "Permission" (see MediaWiki:Wm-license-information-permission-reusing-link and MediaWiki:wm-license-information-permission-reusing-text) on many file descriptions, because the Permission field is now displayed only if not blank. This seems a bit counterproductive to me. Commons:Reusing content outside Wikimedia is, in principle, a very useful page for all re-users of files, even if it still may need some improvements.

Are there any ideas how to bring back this link to all files that use the information template, not only to the ones that actually make use of the Permission field? --:bdk: 15:44, 27 January 2012 (UTC)

All the files already have link to Commons:Reusing content outside Wikimedia added by MediaWiki talk:Gadget-Stockphoto.js, see "Information about reusing icon" in File:IE8 PNG transparency bug.png. --Jarekt (talk) 16:07, 27 January 2012 (UTC)

That stockphoto is JS only and much less visible. That's not a good change. --Saibo (Δ) 16:31, 27 January 2012 (UTC)

ack, JS only isn't an acceptable option. --:bdk: 16:46, 27 January 2012 (UTC)

If we are going to have second link, I think it should be somewhere closer to the license itself. May be a small separate template in the license section, or in {{Self}}? --Jarekt (talk) 17:03, 27 January 2012 (UTC)

If we really need the link, I agree that the license template itself or the license header would sound like better places to have it. But do we really need it ? When all you want to do is use a single file, the license tag is a lot clearer and more relevant than the "reusing content" page. The "reusing content" page explains various things such as the licenses that are accepted on Commons and what settings you should have on your website to use instant Commons. All that is not directly related to the "permission" associated with a particular file. So I think it makes more sense to have the link to "reusing content" in a part about how to use the file outside Wikimedia rather than in a "permission" field. This is just what stockphoto does and stockphoto is very visible for non-logged-in users (okay, not those with Java Script disabled, but well that is not such a large group) --Zolo (talk) 21:59, 27 January 2012 (UTC)

Change Reverted

Reverted the change. This is one of our most important template. Please gather community consensus before making such major changes in functionality. Like:

The addition of other_fields_1
The removal of {{Parse source}} was removed (internationalization?)
The missing Permission field.

Multichill (talk) 14:40, 28 January 2012 (UTC)

I agree the stockphoto is very visible (much better than the link in the infobox). If desirable, we could rename its field Information to Reusing. Also the title Licensing could be changed to Reusing this file with a link to Commons:Reusing content outside Wikimedia, which would be much better visible than now. The licence template contents the important info about reusing; I have serious doubts, whether many users will read the long and complicated page Commons:Reusing content outside Wikimedia. Anyway, the empty field with the link see below looks stupid – in such a case, we could have similar ones for File history, EXIF data, etc. --Petrus Adamus (talk) 15:09, 28 January 2012 (UTC)

done--Zolo (talk) 11:39, 30 January 2012 (UTC)

We were talking about those changes for a while and it seems like removing the "see below" message ("missing Permission field") was the majority view for people that voiced their opinion. Usually in any template discussions there is very little participation, but that should not be the reason for never improving them. Also proposed changes were announced and were being tested for almost a week prior to the change. It would have been more productive if we knew about the objections then, instead of wasting our time for a week. I think may be it is mistake to try to combine multiple changes into one big one. It might be more manageable to propose and if there is enough consensus, execute a series of smaller changes. I also see that Zolo moved this discussion to Commons:Village_pump#Request_for_comments_about_some_changes_in_template:Information. --Jarekt (talk) 03:36, 31 January 2012 (UTC)

Yes there has already been discussion about "see below" and "other fields". I think this time the consensus is about the clearest we can hope to get. So if we are sure that we have no alignment problem I guess we can re-add the new version. --Zolo (talk) 09:21, 6 February 2012 (UTC)

We have an alignment problem in the fields Permission and Other versions, when a text is embedded as their content (instead of a box template), but probably no good solution, as there is a combination of conditional parser functions and HTML-table tags. So the re-edit should be introduced. --Petrus Adamus (talk) 16:21, 6 February 2012 (UTC)

Parse source

Oh yes I see. The {{Parse source}} question remains too. From what I can see in new uploads, alternate forms of "own" are no are not actively used anymore, but since remooving it may break older files, we should probably at least wait until current files are fixed.

I think {{Parse source}} isn't a big problem – even without the function, the text is illegible and a replacement can be performed by a bot afterwards. --Petrus Adamus (talk) 18:25, 6 February 2012 (UTC)

I added {{Parse source}} to {{Information/sandbox}}. I agree with Zolo that we have clear community consensus on this. --Jarekt (talk) 03:01, 7 February 2012 (UTC)

Does that mean parse source is removed from the Information template (as proposed at VP)? --Saibo (Δ) 03:46, 7 February 2012 (UTC)

I restored it in the {{Information/sandbox}} back to the same form {{Information}} uses, but I see I was the only one voting for it. So let me propose this, lets keep it for now and I will alter {{Parse source}} so it tracks images that rely on it to show {{Own}} and run a bot to replace the text. That way we can retire {{Parse source}} at some future date without messing up any files that rely on it. --Jarekt (talk) 02:35, 8 February 2012 (UTC)

Hmm, please mention which texts the bot will replace before you run it. --Saibo (Δ) 03:31, 8 February 2012 (UTC)

In cases when {{Parse source}} identifies a string which is equivalent to "own work" in some language, a {{Parse source tag}} is added. {{Parse source tag}} does not do anything and is invisible but it can be traced by Special:WhatLinksHere/Template:Parse_source_tag. That way files like for example File:Sörg - Kapelle.jpg, which uses "Source=Eigenes Werk (own work)" can be identified and source set to {{Own}}. We can also permanently replace source with "Source={{own}}". --Jarekt (talk) 13:39, 8 February 2012 (UTC)

I think the best solution is to let {{Parse source}} now and do changes concerning that afterwords (prior bot replacement and subsequent removing of the template from the source code of {{Information}}). First of all, please implement the other improvements discussed. --Petrus Adamus (talk) 21:13, 9 February 2012 (UTC)

If we should change the template only once for performance reaon, we can wait a few more weeks until current files have been fixed. Anyway a bot could be useful, not only for texts supported by parse source, but also for things like "myself" or "my camera" that appear to be at least as common. --Zolo (talk) 11:07, 10 February 2012 (UTC)

I think we should change it now and follow up with other changes at the latter date. Combining many changes into one has a side-effect that there is higher chance that something does not work and than all the changes are reverted, So I think I would prefer more medium size changes than few very big ones. Unless someone else volunteers I will try the change again, after the consensus we got on Village Pump. It is just not going to happen this weekend, since I would like to be around to monitor this page and VP after the roll-out for potential issues. --Jarekt (talk) 18:38, 10 February 2012 (UTC)

I do not like to see "my camera" being "converted" to "Own work". Please don't - that is destroying useful information. --Saibo (Δ) 21:46, 10 February 2012 (UTC)

What is the point of it ? True, this means that you did not borrow your boyfriend's camera, but frankly who cares ? More relevantly perhaps, "own" may mean that someone else took the photo with your camera, and thus you may not own the copyright, but it sounds rather far fetched.--Zolo (talk) 21:55, 10 February 2012 (UTC)

Besides, several hundreds of millions of people not speaking English will understand your information after the replacement. --Petrus Adamus (talk) 22:02, 10 February 2012 (UTC)

I am planning on replacing source field of files in this list with {{Own}}. That will not change any text currently displayed in file descriptions, since in all those files the output of the field is translated by {{Parse source}}. I am open to the idea of replacing other strings like "myself" or "my camera" with something translatable to other languages like {{Own}} or {{Self-photographed}}, but not at this time and not without wider discussion. --Jarekt (talk) 14:05, 13 February 2012 (UTC)

The point is that my camera does not necessarily mean that the uploader is the photographer. We can convert my camera to Uploader wrote: “my camera” ≈/circa Self-photographed or similar. --Saibo (Δ) 18:32, 13 February 2012 (UTC)

You are right. I will leave my camera alone. That is why I do not like those non-precise phrases. In case of CC licenses it should be either {{Own}} or not. In the second case the uploader should provide OTRS letter. --Jarekt (talk) 03:32, 14 February 2012 (UTC)

If you see it this way, it means that we should review all files with "source=my camera." A very basic search seems to give about 4000 results. --Zolo (talk) 07:21, 14 February 2012 (UTC)

@Jarekt: In fact I like {{Self-photographed}} most - then it is clear how took the photo and that if there is any work shown it is not claimed to be the uploader's work (like it may be the case with {{Own}}). Maybe we could wrap original sources like "my camera" in a template ({{uploader provided source|my camera}}) and output it like proposed above - then we are more flexible via changing the new template. Although more templates means more complicated stuff.
In most cases "my camera" will in fact mean "Self-photographed" - but that is not necessarily the meaning. @Zolo: However, I wouldn't say that those files need to be reviewed in a specific review action - there are many many many other files with more unclear or doubtful sources / indicators to check... --Saibo (Δ) 18:29, 14 February 2012 (UTC)

The template we currently use for standardizing user provided sources is {{Parse source}} and we can add "my camera" there, although I am not sure what we would replace it with. In some cases it might not mean "{{Self-photographed}}" and I do not want to encourage people to use it by supporting it through translation by {{LangSwitch}}. --Jarekt (talk) 14:04, 15 February 2012 (UTC)

Merge "license" section into this template

Because of the large size of many license templates (and often there are multiple licenses), the "permission" field of this template tends to be underused, and we typically have a separate subsection with the license template, plus a "see below" remark. Why not simplify this by having this template display the license below the main Information box, adding the "license" subsection header? I think this should work fine (it should be sandbox-tested first!) and it would reduce duplication and confusion.

Potentially it would also make it easier to improve display of attribution requirements. Currently, this is partially in this template and partially in the license template. If we do this merge, it'll be neater to improve this, because we can pass parameters to the license template "don't display standard attribution", and that will be very close to non-standard attribution parameter in this template. PS I do understand there'd be a lot of cleanup to do, but I think a bot should be able to do it, by removing the "license" section and moving whatever license templates it finds into this Information template. Rd232 (talk) 01:56, 10 January 2012 (UTC)

The issue has been discussed several, for instance here, without any consensus. Some users feel that "license" and permission (eg OTRS) should be in two clearly distinct fields. Personnally, I agree with you, I cannot see any reason why the OTRS ticket should be inside the infobox and not the license. If anything, the permission should be less obtrusive, because it is way less relevant to the end user than the license. Beside if the license was really not part of the permission, the "see below" message would not make any sense.

By the way, if we want to streamline file description pages, I'd really like to see something done about quality/featured images banners too. They currently often appear under the license header -and some users consistently move them above the infobox where the crowd out everything.) By now, the project should be mature enough to use a more standardized and more discreet style (most Wikipedia just have a small star in the top right corner)--Zolo (talk) 07:45, 10 January 2012 (UTC)

I am such a user. IMO only OTRS templates and similar should be inside the information template. Everything else (large and often multiple license templates, user templates) should be outside. We could also have a bot run for this. :-) --Leyo 08:32, 10 January 2012 (UTC)

I don't know if we made any progress in the last year, but I think the issue stems from disagreement about where the license should go. Personally, I would like for the license to go directly below the information template (the header is pointless but maybe machines like them, I don't know) and remove the permission field completely if it's empty or contains only useless stuff like "see below". I think putting the license in the permission field is neater for smaller licenses but if it's one way or another for all licenses, then outside it should go (cause some are huge). With 12 million files, it would be quite a lot of work, even for a bot (or several). Rocket000 (talk) 08:40, 10 January 2012 (UTC)

Apparently headers (like 'file description') are here for people not machine (though I for one would not mourn them). At least dont see what machines machines can do with them given that a fair number of licenses are currently inside the infobox.

@Leyo: I know that some license templates are long and I agree that they look better outside of the infobox, but this does not mean that they should not be in the template (I dont know if it would have any real benefit though) But I really dont find it coherent to have the OTRS and the license at two different places. If the license is out of the template, cant we have the OTRS ticket outside as well ?--Zolo (talk) 10:17, 10 January 2012 (UTC)

Ideally, we will someday create a new file page template (possibly even with some new MediaWiki extension functionality) that will organize and structure the whole page. It wouldn't be one giant purple & grey box, but a framework for the various boxes we already have. For example, we could do away with using all license templates (and others) directly. Simply fill in the parameter, e.g. |license=cc-by-3.0, to generate the correct license.. |feature=yes gives you a star in the corner, etc. Ok, so the amount of work makes it somewhat unrealistic but we should think of the bigger picture and start moving in that direction a little by little. Rocket000 (talk) 10:58, 10 January 2012 (UTC)

Some licenses can be huge, see for example here and they do not fit well inside {{Information}} template, although I still like to place them there is they are small enough. On one hand it would be fine with me to display license always on the outside of the {{Information}} template. However I am concerned about any drastic changes, since this template is used so much and users often use it in "innovative" ways, which might no longer work after the change. --Jarekt (talk) 13:07, 10 January 2012 (UTC)

The uploading algorithm could easily place the licence templates to the infobox (it doesn't allow using a lot of them together).

Besides, probably it should enable using a custom licence or offer also localised CC versions – ex. I cannot applicate cc-by-sa-3.0-cz, as it doesn't exist among the options offered, thus I have to use the basic upload form (a casual user doesn't know that it's possible) or release the work under cc-by-sa-3.0 (which I don't want) and change it subsequently. --Petrus Adamus (talk) 12:49, 27 February 2012 (UTC)

Template talk:Information/Archive 3

Contents

Template:Information/multi

Order

Combination with Template:Festival Japan Matsuri 2010 (and Festival Template)

Automatic date categorization

summary attribute

Template "eats" other templates.

Several small changes

File:Vie, deteils et peintures de l'eglise de Sion (A).jpg

Permission Parameter

Location

RTL

Few small changes

Hiding information more than 2 or 3 lines

other_fields does not work correctly when other_versions is present

Option to make "description" optional. ?

Empty Permission field shouldn't be displayed

Template does not "eat" other templates anymore

Source field

No aliases

Nested Information template

Poblems with lists

LTR div

Other_field_1

Adaption of "Urheber / Rechteinhaber" at "author"

New version of the template

Edit request (permission space duplication)

Location as separate table now

Loss of "Reusing this image" link on many files

Change Reverted

Parse source

Merge "license" section into this template

Navigation menu

Template talk:Information/Archive 3

Template:Information/multi

Order

Combination with Template:Festival Japan Matsuri 2010 (and Festival Template)

Automatic date categorization

summary attribute

Template "eats" other templates.

Several small changes

File:Vie, deteils et peintures de l'eglise de Sion (A).jpg

Permission Parameter

Location

RTL

Few small changes

Hiding information more than 2 or 3 lines

other_fields does not work correctly when other_versions is present

Option to make "description" optional. ?

Empty Permission field shouldn't be displayed

Template does not "eat" other templates anymore

Source field

No aliases

Nested Information template

Poblems with lists

LTR div

Other_field_1

Adaption of "Urheber / Rechteinhaber" at "author"

New version of the template

Edit request (permission space duplication)

Location as separate table now

Loss of "Reusing this image" link on many files

Change Reverted

Parse source

Merge "license" section into this template

Navigation menu

Search