Template talk:Attrib

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

User parameters[edit]

I'm very wondering, there are now 3 different parameter to handle this one subject, but none of this does the common way in giving simply the text as it is (raw). It means it tries always to find a Commons user to link (auto-linking). But it is not uncommon that the author does not exist as a Commons user (wth we should always expect that?). As this user subject is already overworked, we should remove the auto-linking thing from one of the secondary user parameters.
Maybe add the parameter "a/author" as the u/user is not the same (we also don't need the uploaders). But in fact the u/user should display the raw parameter, but it doesn't!? -- User: Perhelion 08:41, 29 September 2019 (UTC)[reply]

Yes, it had been designed that

  • parameter 2 (by=) links, after the check for existence,
  • parameter 6 (U=) links, without check for existence,
  • parameter 5 (u=) does not link (and of course does not check)

5 and 6 had ben added to avoid the obgligate linking, or to link without obgligate existence check. No I see that something went wrong in templates development history, and even parameter 5 links. I will repair that immediately. Ok ? -- sarang사랑 09:18, 29 September 2019 (UTC)[reply]


And: The old (and in the meantime deprecated) templates AttribSVG (from 2007) and AttribFile (from 2011) areis still used, and should be replaced by the simple Attrib (from 2012/2015); that could be done by a bot run – but the replacement seems not so necessary? -- sarang사랑 09:18, 29 September 2019 (UTC)[reply]

Hey Sarang, thanks for the fast response. Yes the error seems in the /layout. @Replace: I can update my /cleanup.js for this (I removed the autorun with Igen autoinsert as it crashed if the Wiki text is only a bit more. Will fix this too soon). -- User: Perhelion 09:27, 29 September 2019 (UTC)[reply]
PS: The error is {{by}}. -- User: Perhelion 09:33, 29 September 2019 (UTC)[reply]

Thank you for telling me about the error, I completely overlooked it. Yes, I corrected the layout, and handled parameter 5 outside the {{By}}. Now it works fine and as it should do. -- sarang사랑 09:37, 29 September 2019 (UTC)[reply]

Why not simply use template:I18n/by for this? -- User: Perhelion 13:20, 29 September 2019 (UTC)[reply]

May be that it was not such a good idea to usurp {{By}} i.e. to expand it that it also displays a user name when the parameter is specified; but many other templates contain as well translation and template coding. {{By}} and {{I18n/by}} support different functions! But there is also some similarity. -- sarang사랑 13:37, 29 September 2019 (UTC)[reply]

Improvement[edit]

@Kaldari and Sarang: Would be nice if this template can take creator of the derived file itself. Eg, then I dont have to manually copy this ([[1]]) to get rid of Category:Maint:Attr-user not existing--Estopedist1 (talk) 14:59, 28 January 2020 (UTC)[reply]

Hi @Estopedist1: I had corrected Alberta Highway 901.svg that it will show both authors. Of course it might be possible to handle the specification of many authors — but I cannot see much use to specify more than one author. It is common usage to mention only and just the very first user, i.e. the uploader, even when his work was poor, and to say nothing about all the others, what worthy work they ever might have done; more information a visitor of a file can get when he follows the link to the file, there he will find the whole file history. If you like more to mention another author or co_author, you can do it - it depends on you and on your estimation. But too many users will soon exceed the size of the line and cause unpleasant automatic line breaks. So let it be an exception that this Attrib links to two users! -- sarang사랑 16:36, 28 January 2020 (UTC)[reply]
thanks. Now I understand this template logics. Category:Maint:Attr-user not existing is maintained. Luck!--Estopedist1 (talk) 17:05, 28 January 2020 (UTC)[reply]
Hi @Estopedist1: I made some format changes at Alberta Highway 901.svg:
  • the rule for permission tells: when the license-header is used, this field should not get any value. So I moved the trademark text and template down to the license block, and removed the permission.
  • An hour specified at the date does not really disturb, but is redundant; when somebody really wants to know the upload time, it's below in the history.
  • The Attrib can get a "topic", in this case the "to"-topic is a sign, and the "from"-topics are a textlogo and another sign.
  • When there is more than one Attrib, all of them can be collected with the Template:Attribs, reducing a bit the effort.
  • Because the attribs belong somehow to the source, I moved them up there, changing it to Own using.
  • With named parameters it does not matter, but I like it more when the sequence in the decription is the same as in the display:
  1. description
  2. date
  3. source
  4. author
  5. other fields
Nothing of that is necessary — but may be you get some ideas you like? Good luck to you in the New Chinese Year -- sarang사랑 13:35, 29 January 2020 (UTC)[reply]
@Sarang: whizz kid :) I did little improvements there: [2]. Also categories like Category:Valid SVG created with Adobe Illustrator: Alberta Hwy (with unnecessary space) should be fixed but it is unfortunately manual work. Luck!--Estopedist1 (talk) 14:36, 29 January 2020 (UTC)[reply]

no problem, I can fix that category -- sarang사랑 16:24, 29 January 2020 (UTC)[reply]

What part is used[edit]

@Sarang: Hello!

Lokal_Profil requested this and I have myself also seen the need for this, namely a parameter which specifies what part is taken from what file. For example part=crown or perhaps part=lion. If you have more than one file used in {{Attrib}}, then I think {part1}, {part2}, {part3} etc. has to be used. Do you think you can impliment such a parameter?Jonteemil (talk) 11:54, 6 April 2020 (UTC)[reply]

@Jonteemil: Like for the other parameters, I would suggest "p=" (no numeric alias) in {{Attrib}}, and "p1=" to "pn=" for {{Attribs}}; that will not be a problem, neither there nor in the LUA part.
But you can see that it is served by 22 languages. I can do some, as e.g. de, en, es, fr, pt but I am not fit enough to implement it into the other languages. And at the moment I do not have an idea how that information should be expressed textually in any language. In addition, when you mention a part of the drawing, it should also be translated - and I have neither an idea how to manage that! We will need a list of words, from where you have to select your part, and every word from that list needs an I18n-template with all the translations. Only words from that list can be used, and when you need a new part, the list has to be expanded and all the translations (currently 22 languages) for that new item have to be created.
The template will have to check that (1) only items of the list are used, that (2) the I18n-template for that item exists, and create an error message and use a maintenence category if not.
To make such a list of items, and all the other needs seem not to be a problem - just work. The problem is where and how to insert the new information into the text that the template produces!
The problems seem to heavy, and the advantage to specify which part is attributed seems not to justify the effort: if one looks a bit carefully he can see himself which part from another drawing is used, without being told explicitly!
More useful would be if you create a Swedish translation for that template, currently it is missing  :-) -- sarang사랑 15:00, 6 April 2020 (UTC)[reply]
@Sarang: Wow, I never anticipated it would be that complex. I'm just thinking, there are a lot of parameters in many templates that aren't translated. For example {\+r}, {\-r} and {\\r} in {{Igen}}. There are probably more as well. I agree with you that the ideal solution is that everything is translated into every language, but until we have reached that point can't you just have a parameter similar to {\r+}? I will create the Swedish translation right away! Jonteemil (talk) 17:38, 6 April 2020 (UTC)[reply]
@Jonteemil: just for fun I tried to implement partially this expansion.
I allow the parameter "part"; it is honored only by the english version, and can be e.g. "a crown" or "an emblem" (always with an article 'the', 'a'/'an', when it's not plural), but when it replaces the text elements then it may cause an error in the grammar because the continuation is for plural "have" instead of "has" for singular.
Another possibility is to specify p=1 which means that not elements but just one element is taken; in that case the continuing text includes "has" instead of "have". Currently that parameter is honored also by the German and Spanish version (others may follow) - except from that, all language versions ignore the "part" parameter.
 
This image includes an element that have been taken or adapted from this file:
Hematopoiesis (human) diagram en.svg (by RexxS).
A rather cheap expansion may be just to expand the text by adding the untranslated "part" in brackets; but that solution won't help anything... -- sarang사랑 10:09, 17 April 2020 (UTC)[reply]
But too many expanding may cause that one line is not enough - it happens sometimes with long file names and long user names, and it looks ugly. And with different "from"-topics, or some odd sizes of the from-picture it doesn't look good when more attribs are not in column-like style ! — Preceding unsigned comment added by Sarang (talk • contribs) 11:23, 17 April 2020 (UTC)[reply]

Template stacking[edit]

I just noticed that the AttribSVG template is now considered depricated in favour of this one, due to a visual change that I find a bit unpleasant. Previously when multiple attributions were used in a file infobox (ex: File:Finland road sign 567 + 880.svg) they would stack one on top of the other. However now they appear side-by-side (infobox width allowing). Would it be possible to alter the template so that attributions stack one of top of the other, regardless of their length and width of the infobox? Fry1989 eh? 19:05, 30 September 2020 (UTC)[reply]

Implementation of by-parameter[edit]

This template seems to implement the by parameter differently from e.g. {{F}} or {{Derived from}} in that it does not respect underscores in names. Compare the following

Where {{Attrib}} is the only one which drops the underscore in Lokal_Profil.

I'm sure I'm one of the very few users which are affected (i.e. considers the underscore to be part of the username) but it would be nice if they all implemented the call to {{U}} in the same way. Lokal_Profil 20:58, 31 July 2022 (UTC)[reply]