Open main menu

Wikimedia Commons β

Template talk:Creator/Archive 2

< Template talk:Creator

in which the second row is titled "Date of birth" even though it also has death-date info (the "1901" in the separate cell has no context). DMacks (talk) 14:12, 30 April 2013 (UTC)

That is because we do not use deathyear much. It is only if death date uses some templates. But it still should be fixed. --Jarekt (talk) 14:36, 30 April 2013 (UTC)
Pictogram voting keep.svg Fixed See
Fortuné Méaulle  (1844–1901) Link back to Creator infobox template wikidata:Q3078590
Fortuné Méaulle
Alternative names Fortuné Louis Méaulle, Fortuné-Louis Méaulle
Description French engraver
Date of birth/death
Location of birth Angers
Authority control
--Jarekt (talk) 14:39, 30 April 2013 (UTC)
Thanks for the prompt solution! DMacks (talk) 15:13, 30 April 2013 (UTC)

Wikidata

What is the relationship of Template:Creator and Wikidata? Can the Creator templates be created automatically using Wikidata? --Robert.Allen (talk) 08:10, 14 June 2013 (UTC)

At the moment, there is no relationship because Wikimedia Commons is not able to draw information from Wikidata like the Wikipedias are. This could be done at some point in the future − and once it is I do believe Creator templates would be one of the first Commons feature to use it. See d:Wikidata:Wikimedia Commons for more information on the current status. Jean-Fred (talk) 08:50, 14 June 2013 (UTC)

Collapsible class

As file page content is available on all projects, then you might want to use classes that are available on all projects, e.g. mw-collapsible instead of collapsible. It's design is probably less flexible, but at least it would work everywhere. 90.190.114.172 20:10, 4 October 2013 (UTC)

  Agree however I do not know much about different collapsable classes. Can someone more familiar with it try to create one in the sandbox? --Jarekt (talk) 18:23, 30 October 2013 (UTC)

User name parameter

Can we add a |user name= parameter, for cases where the creator is also active on Commons, or on a sister project? Andy Mabbett (talk) 16:06, 30 October 2013 (UTC)

I think that would be such a rare case that it would be more easily handled by adding username to description field. Some users created their own Creator templates but it is mostly discouraged unless they meet Wikipedia notability criteria (see Commons:Creator) and very few of us do. --Jarekt (talk) 18:21, 30 October 2013 (UTC)

parameter and workshop is broken

e.g.File:Titian and workshop - The Vendramin Family, venerating a Relic of the True Cross - Google Art Project.jpg--Oursana (talk) 11:39, 8 June 2014 (UTC)

Oursana, It seems fine to me. Is it still broken for you? --Jarekt (talk) 03:40, 9 June 2014 (UTC)
Hi Jarekt, this and other files are broken for about 10 days: Template:2} und Werkstatt (1490–1576) ; I have vector and it looks the same in Safari or Firefox.--Oursana (talk) 21:25, 9 June 2014 (UTC)
I see the German version was broken. I   Fixed it now, see here--Jarekt (talk) 04:14, 10 June 2014 (UTC)
Jarekt, I apologize, I caused it myself. I didn't remember I had been busy there and forgot the way back. Many thanks--Oursana (talk) 11:08, 10 June 2014 (UTC)
Not a big problem (to non-German speakers), but I thought it was a little funny how it worked out. --Jarekt (talk) 11:32, 10 June 2014 (UTC)

Translation

I want to make a little fix to the galician translation of this template but I can't find where, could anybody tell me where is the galician translation? Thanks!, --Elisardojm (talk) 22:00, 30 July 2014 (UTC)

It is on Translatewiki. Go to https://translatewiki.net/wiki/User:Jarekt and look for messages starting with "wm-license-creator-". --Jarekt (talk) 17:49, 31 July 2014 (UTC)
I can't find it there... I want to fix the text of the "Authority" parameter..., I want to change from "Controle de autoridade" to "Control de autoridades"... Thanks, --Elisardojm (talk) 18:51, 31 July 2014 (UTC)
Oh that one was done by {{Authority control tag}} the old version was defaulting to Spanish.--Jarekt (talk) 19:12, 31 July 2014 (UTC)
Thanks!, --Elisardojm (talk) 20:46, 31 July 2014 (UTC)

Edit request

{{edit request}} {{#if:{{NAMESPACE}}|File|[[Category:Bad use of creator template - option]]}}

should read

{{#if:{{{{NAMESPACE}}|File|[[Category:Bad use of creator template - option]]}}}}

Jheald (talk) 18:51, 14 August 2014 (UTC)

  Done I used different fix but I think Category:Bad use of creator template - option should work now. --Jarekt (talk) 00:10, 15 August 2014 (UTC)


Steps towards making Creator draw directly from Wikidata

Some current efforts to get Creator templates to draw directly from Wikidata can be seen at d:Template:Creator/wrapper/test -- still with quite a lot of weirdness still to be fixed at the moment, some of which is identified at d:Template talk:Creator/wrapper/test, plus some that probably isn't.

This has to be hosted on Wikidata at the moment, because it requires "access to arbitrary items" -- the ability for template code called from one page to access information about a Wikidata item sitelinked to a different page. (Also called Wikidata Phase 3).

Such arbitrary access won't generally be possible until some quite heavy technical work has been done first, to enable MediaWiki to be able to work out whether (and which) pages need to be regenerated if an item on Wikidata changes. So it's not expected to be generally available on wikis including Commons until some time in 2015. But it is now possible, for development work without page regeneration, on Wikidata itself.

So that is why the development pages above are on Wikidata, rather than here.

See also d:Wikidata:WikiProject Structured Data for Commons/Template workshop, d:Template talk:Creator, d:Template talk:Creator/statictest and d:Template:Creator/statictest for more information on the development.

The last of those pages, at d:Template:Creator/statictest#Template_wikitext_generation attempts to show what's going on 'under the bonnet' and passed to the existing template, in a form that will be possible to cut-and-paste to make new Creator:xyz templates here. (Once some more of the bugs are sorted out).

All thoughts and comments gratefully received, Jheald (talk) 22:20, 19 September 2014 (UTC)

d:Property:P1472 now added to 13,528 Wikidata items, identified by entries in the wikidata = field of the template. Lots more remaining, of course, that don't have Wikidata links. Jheald (talk) 17:27, 27 September 2014 (UTC)
Thanks for the update and great work on this technical challenge. I wonder if there is a way to create a text box using mw:Extension:InputBox where one can type in wikidata Q-code and which would provide link to wikidata with the proposed text of the template. We could add it to Template:Editnotices/Namespace/Creator and combine it with Template:Creator/preload. By the way, I am not certain what the purpose of d:Property:P1472 is. I guess if Commons has a link to wikidata than it might be nice to know about creator pages when in wikidata, but I can not think about the uses. --Jarekt (talk) 16:05, 29 September 2014 (UTC)
@Jarekt: What seemed useful to me, regarding P1472, is that one can now query Wikidata using WDQ, to see what the property-values on Wikidata look like, for items that have Creator templates. This I think can be sometimes useful as a quick check, but also for more detailed data extraction and comparison with the values on Commons. (Something I intend to try to do more of this week).
I have made a proposal at d:Wikidata:Property_proposal/Organization#Commons_Institution_template for a similar property for the Institution template, but not had any comments yet.
Note that there are still some issues to fix with the Creator template wrapper -- for example it's not yet pulling out Wikisource links; BCE dates need fixing; there are issues with ancient and sub-national nationalities (Scottish, Welsh, Catalan, etc); and I don't know why my attempt to remove the newlines in the wikitext generated for the Authority Control section is failing. I'll try to work through these, but appreciate if you could look at the last, and tell me why what I've tried to do doesn't work, and if there's a fix that would do it. Thanks. Jheald (talk) 16:19, 29 September 2014 (UTC)

Another parameter to categorize?

I don't know much about this template, but it seems that it could do with an extra parameter instructing it to categorize files using this creator template in a chosen category. For example, I'd like Creator:Sam Hood to put any picture using it into Category:Photographs by Sam Hood. I know we don't let templates do subject-matter categorization (so that they can be subcatted), but I don't see why templates like this can't do creator-based categorization. What am I missing? --99of9 (talk) 04:25, 20 November 2014 (UTC)

You are missing the history of this template. Originally many people creating Creator pages for specific artists would add a category which was than passed to the files using the creator template. That was great until you had enough files that you wanted to create subcategories, and than you discover that the files categorized that way does not behave like other files in categories and can not be easily removed from the category. As a result, many people started removing creator templates. At some point we went through the process of cleaning few thousand templates, and re-categorizing the content. It was such a huge undertaking we would like to avoid it in the future. --Jarekt (talk) 13:20, 20 November 2014 (UTC)
Ok, fair enough. I would have thought that blanking the parameter value would be a reasonably quick way to uncategorize the files so they can be subcatted? But anyway, if creator-subcatting is common, that's a good reason to let the categories work like normal. --99of9 (talk) 06:08, 28 November 2014 (UTC)

Collapsible option

I would like to request that the collapsible option be added to this template. Here is an example of why: Category:Fontaine Médicis.

The documentation might read:

To manage this template's visibility when it first appears, add the parameter ...

|state=collapsed .......... to show the template in its collapsed state, i.e. hidden apart from its titlebar;
|state=expanded ............ to show the template in its expanded state, i.e. fully visible;
|state=autocollapse .... to show the template in its collapsed state but only if it is on a File page

Unless set otherwise (see the state parameter in the template's code), the template's default state is autocollapse.

--Robert.Allen (talk) 04:58, 28 November 2014 (UTC)

That parameter would have to be added to all Category:Creator templates, which is not really possible. That category page should link to creator pages using [[]] brackets or it should link to wikipedia articles. --Jarekt (talk) 03:12, 6 December 2014 (UTC)
I'm requesting an optional parameter, not a required one. It would only be added when an editor felt it was desirable. If it is not added, the behavior of the template would be exactly as it is now, which is what I meant to describe in the example documentation. By that I mean, the default behavior (without the addition of the state parameter) would be equivalent to adding "state=autocollapse". My intention was to avoid having to add the parameter to all the Category:Creator templates. But maybe I am misunderstanding something. --Robert.Allen (talk) 04:17, 9 December 2014 (UTC)

Duplicates

Hello, ~25 duplicate templates were detected during data export to Wikidata: d:Wikidata:Database reports/Constraint violations/P1472#Single value. Maybe somebody is interest to fix these. Thanks in advance. Ivan A. Krestinin (talk) 20:56, 5 December 2014 (UTC)

Thanks that is great work detecting those. The duplicate creators and categories will need to merged and redirected, which is easy but time consuming. I will start, but help of others would be appreciated. --Jarekt (talk) 03:15, 6 December 2014 (UTC)
@Ivan A. Krestinin, Jarekt: The constraint violations page only updates every 24 or 48 hours, and also gets auto rewritten in a slightly laggy way, so here's a local copy, that people can remove entries from as they're done. (Remember to merge the categories and change the Wikidata entries!) Jheald (talk) 12:55, 6 December 2014 (UTC)
All issues are fixed. Thank you Jarekt, Jheald and others. Great job! Ivan A. Krestinin (talk) 21:39, 8 December 2014 (UTC)

LUA and Wikidata

This template should be rebuild as LUA module at Module:Creator and have the option to fallback to Wikidata, see phab:T89597 (part of Commons:Structured data). Multichill (talk) 14:13, 15 February 2015 (UTC)

Arbitrary access for commons to fetch Wikidata values is coming (soon) after Wikimania. Andy Mabbett (talk) 20:55, 22 June 2015 (UTC)
AFAIK, We are still totally unprepared for it. I will be at Wikimania and I put my name on a "Looking for a Hackatron buddy" list where I proposed to work on this problem, in case someone is interested and will attend Wikimania. --Jarekt (talk) 23:29, 22 June 2015 (UTC)
@Jarekt, Multichill, Pigsonthewing, Lydia Pintscher (WMDE): Did WM2015 bring any joy to getting this converted? What is it that we see as the hold-up for this to move forward? Is it a Commons issue? Procedural? Hacking? Bot requirement? I know that I saw mock-ups undertaken at WD at a previous time. With my enWS hat on, I know that with adding more data at WD, that having to do it at Commons for the same data is problematic, and I am just as likely to link to the creator: ns and not get to the template. <Bad Billinghurst!>  — billinghurst sDrewth 01:17, 2 August 2015 (UTC)
I worked on other tasks at the Wikimania, and from what I heard Arbitrary access is still work in progress. Rebuilding this and other similar templates as LUA modules is still on my to do list (unless someone beats me to it). I heard that there were plans to create some "official" LUA libraries for accessing wikidata, but I do not remember who might be working on it. --Jarekt (talk) 04:22, 2 August 2015 (UTC)
It can't be far off, judging from d:Wikidata:Arbitrary access, where you an always find the latest news. Andy Mabbett (talk) 19:26, 3 August 2015 (UTC)
Andy if you look at d:Wikidata:Arbitrary access there is not expected date for Commons. So I would not hold my breath. --Jarekt (talk) 20:31, 3 August 2015 (UTC)
The dates for most of the 12 & all of the 18 August roll-outs were only added yesterday. Andy Mabbett (talk) 13:33, 4 August 2015 (UTC)
Arbitrary access is here! I started working on the feature on Beta Commons, but there's still a lot to do that I don't have time for. If anyone else wants to pick up from there, see [9]. BMacZero (talk) 20:27, 27 April 2016 (UTC)

interwiki and sister links

As the arbitrary access is now available, maybe we can look at addition of certain elements, maybe as sub-modules. The sister links are required to be manually added at this time and it would be great if those could be added, they are already there and part of the ready data that can be pulled, and separate from other components.  — billinghurst sDrewth 00:43, 21 May 2016 (UTC)

Collapse in Template:Category definition: Objects?

Currently the template contains a <table class="toccolours collapsible {{ifimage|collapsed}}"> element. Is there a way to collapse the template also in Template:Category definition: Objects? It should be a fine visual improvement. --Marsupium (talk) 15:10, 12 June 2015 (UTC)

I can not think of a simple way to do it. --Jarekt (talk) 15:29, 12 June 2015 (UTC)
For 21667 transclusions even a very simple parameter could be appropriate. Don't you think? --Marsupium (talk) 16:23, 12 June 2015 (UTC)
The problem is that one would have to add a parameter to all 20k Creator templates which would be passed to {{Creator}} and then use some complicated syntax in 5822 transclusions of {{Category definition: Object}} in category namespace. I assume that within next few years Template:Category definition: Object will the totally rewritten or retired after all that info is on wikidata (same with creator and institution templates). --Jarekt (talk) 11:58, 15 June 2015 (UTC)
My inventory of the Père-Lachaise Cemetery is a big user of this template (3812 transclusions in category namespace). I will move to Wikidata my structured data when Wikidata will have the basic functionalities. Pyb (talk) 14:45, 15 June 2015 (UTC)
A lot of moving of data to wikidata should happen automatically by bots, so hopefully there will be no need for manual transfer. --Jarekt (talk) 16:46, 15 June 2015 (UTC)
If the collapsible state was an optional parameter, then it would not have to be added to all 20k creator templates. The optional parameter passthru code to collapse the template (e.g., on a Category page) would only need to be added to those creator templates where it is desired to override the default behavior. Adding this line could be covered in the documentation, so that almost any editor could add it to specific creator templates. For example, something similar for changing the Opera navbox image on specific pages from the default image. --Robert.Allen (talk) 23:22, 12 May 2016 (UTC)
@Jarekt: A parameter is already passed to the template with the line:
 | Option = {{{1|}}} <!-- Do not modify -->
. With a little ingenuity, this could be used to pass more than one parameter, e.g., if a separator is used that the Wikimedia software will not parse (perhaps a comma?). The template code could determine if a separator is present and parse the parameters from the string, and if one of the parameters is "collapsed", then the it could collapse the template on specific category pages. Robert.Allen (talk) 08:09, 14 May 2016 (UTC)

Moving of data to Wikidata

A bit off topic, however: @Jarekt: Since you talked about moving data to Wikidata automatically, do you know any approaches to convert data like from {{Other date}}? Since I work on a semi-automatical way to move data from file descriptions here – and hopefully from {{Artwork}} soon – to Wikidata I'd really appreciate any groundwork! --Marsupium (talk) 11:56, 14 May 2016 (UTC)

{{Other date}} and {{Complex date}} have their own syntax and Wikidata have its own syntax. {{Other date}} and {{Complex date}} are interfaces to Module:Complex date which I wrote while keeping an eye on Wikidata format. Any {{Other date}} can be converted to {{Complex date}}-like parameters and those should be easier to map to Wikidata format. Other way to tackle it would be to start with all {{other date|circa|...}} and other single date options and move them than pick some other type and move them one type at a time. --Jarekt (talk) 14:48, 14 May 2016 (UTC)
OK, thanks! Ah, so we will have to start with a mapping! With earliest date (P1319), latest date (P1326) and d:sourcing circumstances (P1480) there are yet some fine possibilities. Then d:Help:Modelling/general/time has to be updated. --Marsupium (talk) 21:00, 14 May 2016 (UTC)

For general issues, Commons talk:Wikidata is available. Andy Mabbett (talk) 13:14, 16 May 2016 (UTC)

Category:Creator templates without Wikidata link

Perhaps the best way to deal with them would be through https://tools.wmflabs.org/mix-n-match/? in case any one feels like importing the data. --Zolo (talk) 09:46, 18 May 2016 (UTC)

That sounds like a good suggestion. However we should probably try to follow wikilinks first. For example if name has a link to wikipedia article and wikipedia article is linked with wikidata than we can grab that link that way. It is just matter of writing some Python code to do it. Once we are done with this option than we can ask volunteers to match them by hand. --Jarekt (talk) 18:11, 19 May 2016 (UTC)
I think user:multichill and user:poulpy have already done this sort of thing ? Zolo (talk) 18:41, 19 May 2016 (UTC)
Most Creator templates were matched with wikidata, but those that did not still have wikilinks. For example Creator:Auguste de Creuse -> en:Auguste de Creuse -> d:Q2871477. Maybe the issue is that since that code run, commons, wikipedias and wikidata were changing, so the connections that were not possible then might be possible now. May be it would be possible to rerun those codes. --Jarekt (talk) 20:08, 19 May 2016 (UTC)
Another interesting way of linking would be through VIAF numbers for example  Creator:Antonio González Ruiz has VIAF value = 86950878, same with d:Q8201255. I wonder if there is an easy way (from LUA maybe?) to look up what item has VIAF=86950878. --Jarekt (talk) 20:16, 19 May 2016 (UTC)
This sounds like the sort of thing User:Magnus Manske often does. Andy Mabbett (talk) 20:23, 16 July 2016 (UTC)
I actually figured out a way to use User:Magnus Manske's multibeacon tool to do the job. When combined with this trick one can use AWB (or even visual file editor) to edit large batches of images. --Jarekt (talk) 23:46, 17 July 2016 (UTC)

Near

I have no idea what {{near}} template means, when used as creator option, as in File:Olpe athletes Louvre G242.jpg, where {{Creator:Kleophrades Painter|near}} gives

attributed to an artist close to Kleophrades Painter      
Description Greek red-figure vase painter
Date of birth/death 6th century BC 5th century BC
Work period between circa 505 and circa 475 BC
Work location Attica
Authority control

. It might mean something in other languages but it is meaningless in English. And we need to fix it or remove it as one of the Creator options. The phrase makes sense when used as in Creator:Walenty Wańkowicz, where Kaluzyca {{lcfirst:{{near}}}} {{Minsk}} gives "Kaluzyca near Minsk". I hope it makes sense in other languages. --Jarekt (talk) 03:34, 21 July 2016 (UTC)

Also "namepiece" option oes not make sense in English as in {{Creator:Master of the Brandon Portrait|namepiece}} that gives
Category:Master of the Brandon Portrait  (fl. circa 1510–1540)    
Alternative names Master of the Brandon Portraits, Master of Queen Mary Tudor
Description Flemish painter and draughtsman
Work period circa 1510-1540
Work location Southern Netherlands, England
Authority control

. Maybe french version makes sense: "objet eponyme", but both phrases do not show up in wiktionary.--Jarekt (talk) 03:54, 21 July 2016 (UTC)

Près (literally "near") indeed shows up in the Louvre's entry [10] but I had never seen that, and I am not quite sure of the meaning. @Jastrow: ?
"Objet éponyme" means that after which the artist was named like Brandon portrait -> Master of the Brandon Portrait. The English spelling seems to be "" [11]. Not sure this really belongs here though: it is usually self-evident, and might get confusing if the artist has different names in different languages. --Zolo (talk) 09:00, 21 July 2016 (UTC)

About {{near}}, please refer to Template talk:Creator/Archive 2#Determiner. "Namepiece", "name piece" and "name-piece" are different spellings used in the literature, the latter being more frequent. A search on JSTOR, for instance, will attest their academic use. Just because you don't know what a word means doesn't mean it's meaningless. Jastrow (Λέγετε) 11:03, 21 July 2016 (UTC)

Ok I guess both of those make sense now, and I found "namepiece" used in some wikipedia articles. I wrote wiktionary:namepiece definition and probably should write short article about the term and link it from the term when used. "Near" is a farther streach, maybe it means something to art experts, but we should link to some explanation of the term, when we use it. Alternativly we can use "Manner of " which is more clear. --Jarekt (talk) 18:00, 21 July 2016 (UTC)

Strange behaviuour

File:Rytec Ludvik Arnost Buquoy ; kreslir Antonin Pucherna 1776-12.6.1852 - Serie pohledu na pozoruhodna mista v Praze a okoli Sarka Eine Partie aus der Scharka.jpg Creator:Antonín Pucherna with the paramater "after" does not give "after ..." but "formerly attributed to..." What is wrong here (and where? in that Creator page or in the Template:Creator itself?) --AndreasPraefcke (talk) 18:56, 9 August 2016 (UTC)

Found it myself eventually. It was in the Template:After. I reverted that change that must have been a mistake. --AndreasPraefcke (talk) 19:01, 9 August 2016 (UTC)

Name from Wikidata

The template will need a major rewrite, probably in Lua to make full use of Wikidata, but maybe we can already use Wikidata for name retrieval, so that we do not need to maintain all those {{langSwitch|en=blabla|ru=bloblbo|ar=bliblibli}}. I think that simply requires transforming all {{{Name|}}} into {{{Name| {{label|{{{Wikidata|}}} }} }}. --Zolo (talk) 08:59, 15 May 2016 (UTC)

This would be a major improvement. --Robert.Allen (talk) 08:32, 16 May 2016 (UTC)
  • I came here to post the same thing. Kind of silly to maintain this manually when Wikidata is already organizing the translations. czar 07:58, 13 July 2016 (UTC)
So user:Jarekt, would you implement this version ? Not a nice code for sure, but it should work until we get the Lua version. --Zolo (talk) 13:44, 16 July 2016 (UTC)
That is an ugly code but I agree that it would work. However once we pull name from the wikidata than I am afraid we will get request to pull dates or locations, or wikisource links. All of them would be great but it would overcomplicate the already messy template. Another solution would be to keep current template as "core" and write outer layer to deal with wikidata. I was experimenting with that in April, here, but in the end decided that it would be better to just rewrite it in Lua. I have started to work on Lua version and hope to finish it this summer. --Jarekt (talk) 02:49, 18 July 2016 (UTC)
I have a better (hopefully) idea: as part of rewriting Creator template in LUA, I wiss start with {{name}} template and write it to handle more cases, that will simplify template:Creator code and make it easier to add wikidata based name. --Jarekt (talk) 12:04, 18 July 2016 (UTC)
  Done For example Creator:Peter Paul Rubens is missing "name" field and it is pulling it from the wikidata. --Jarekt (talk) 17:25, 12 August 2016 (UTC)
Thanks for your work, Jarekt. But I am not sure if the code works right. With https://commons.wikimedia.org/wiki/Creator:Peter_Paul_Rubens?uselang=ar I expect to see the name in Arabic but it is written in Latin script. Or do I misunderstand the functionaliy? btw: the link goes to arwiki. Raymond 18:35, 12 August 2016 (UTC)
Raymond, That is due to phabricator:T140792 bug; If you switch your native language to ar the Creator:Peter_Paul_Rubens page will have correct translations. --Jarekt (talk) 18:53, 12 August 2016 (UTC)
Jarekt, thank you for pointing me to this bug. Raymond 19:02, 12 August 2016 (UTC)
@Zolo:, maybe the issue is with module:Wikidata. I can imagine that if "lang" is provided but not used in all parts of the code we would have that issue. For example if some parts of the code relied on "lang" provided by the template and some on {{int:lang}} we could have issues described in that phabricator ticket. Could you check? --Jarekt (talk) 19:07, 12 August 2016 (UTC)
It is actually related to the behavior of mw.wikibase.label() that is not compatible with ?uselang. I have disabled it here and it fixes the issue, with potentially large large cost on memory usage that will need to be addressed in a more technical place. --Zolo (talk) 20:03, 12 August 2016 (UTC)

dealing with duplicate templates

This query lists all the wikidata items linked to 2 Creator templates. Many of those are duplicates ( 2 templates for the same person) or templates with wrong wikidata codes. If someone needs a interesting puzzle please help me cleaning them up, which involves either combining 2 templates or removing link from one of the commons creator templates and removing one of the Commons Creator page (P1472) links. --Jarekt (talk) 02:21, 30 August 2016 (UTC)

Category:Creator templates with Wikidata link: item mismatching P373

Category:Creator templates with Wikidata link: item mismatching P373 is a category which detects mismatch between Wikidata's P373 (Commons category (P373) and Commons Creator, Homecat category. In most cases it is due either to old category name still kept on Wikidata or due to multiple categories related to the same person on Commons. If someone like puzzles, I invite to help me fix them. --Jarekt (talk) 18:03, 2 September 2016 (UTC)

Lua version of the code

We have very preliminary version of the LUA code that mimics the current display part of the {{Creator}} template at Module:Creator. See for example:

Eugeniusz Lokajski  (1908–1944)    
 
Alternative names "Brok"
Description Polish photographer and athlete
Date of birth/death 14 December 1908 25 September 1944
Location of birth/death Warsaw Warsaw
Work period 1944
Work location Warsaw Uprising mostly in Śródmieście district.
Authority control

I will be adding more capabilities to look up info from wikidata and will work on large section that creates maintenance categories. But I hope to have something ready for testing soon. --Jarekt (talk) 14:35, 15 September 2016 (UTC)

Protected edit request

{{edit protected}} This template's documentation is displaying on pages in the Creator namespace that use the template. I believe it's because of the following line under "automatic categorization of pages in Creator: namespace".

{{documentation|Template:Creator/documentation}}

The template already includes its documentation within noinclude tags at the bottom of the template. Could someone remove the line shown above? Thanks. --Auntof6 (talk) 18:24, 8 October 2016 (UTC)

  Not done Auntof6 I am lost why do you want to remove that documentation, for example in Creator:Sorin_Adam, or any other. Documentation within noinclude tags at the bottom of the template adds documentation to the template. --Jarekt (talk) 04:13, 11 October 2016 (UTC)
@Jarekt: I don't understand why the creator pages need documentation on how to use the template. Doesn't template documentation need to be displayed on the template page, and not on the pages that use the template? There are two places in the template that include the documentation page: the one at the bottom that displays the doc on the template page, and the one I suggest removing that displays it on creator pages. There are other types of pages that use this template, and the doc doesn't display on those. Am I missing something? --Auntof6 (talk) 04:19, 11 October 2016 (UTC)
Auntof6, All templates including Creator or Institution templates should include documentation. Creator templates are more or less the same and do not need individual documentation, so a single documentation page is added to 20- something thousands creator pages with the command you are proposing to remove. --Jarekt (talk) 04:33, 11 October 2016 (UTC)
@Jarekt: I'm still not sure I understand. Are you saying that the creator pages are templates? --Auntof6 (talk) 04:35, 11 October 2016 (UTC)
Auntof6, they are pages used like templates, (transcluded to other pages,) but which are in a specialized namespace. --Jarekt (talk) 05:03, 11 October 2016 (UTC)
Ah! I didn't know that. Now it makes sense. Thanks for the explanation. --Auntof6 (talk) 05:08, 11 October 2016 (UTC)

Bugfix in this template

There are two tests using this code:

{{#ifeq: {{localurl:{{PAGENAME}}}} | {{localurl:{{{Homecat}}}}} || ... }}

It does not work at all, there's no such "localurl:" parserfunction. This causes a tracking category to be overpopulated.

I think that the purpose of this test was to compare the current page name (as returned by {{PAGENAME}}, where it may be HTML-encoded for some ASCII punctuation characters allowed by MediaWiki such as the apostrophe ', with the value of a plain-text parameter ({{{Homecat}}}) which may include non significant whitespaces or different lettercase in the first letter, and which is generally not URL-encoded). The work around is to use this simple code (passing the specified parameter to the PAGENAME parser function to normalize it the same way as for the current pagename returned by default):

{{#ifeq: {{PAGENAME}} | {{PAGENAME|{{{Homecat}}}}} || ... }}

Another equivalent solution uses #titleparts (reverse conversion from the HTML-encoded characters to plain UTF-8 characters), but still with the equivalent canonicalisation of pagenames (leading/trailing whitespaces removed, whitespaces compacted, canonicalisation for the namespace or for the leading character of the page title, resolution of relative URLs...).

Please unprotect this template to make this necessary change (two occurences). verdy_p (talk) 03:21, 10 October 2016 (UTC) {{editprotected}}

Note: the Template:Creator/sandbox version fixes that (it also fixes various dangling newlines at end of the table, adds scope="col/row" in header cells and eliminates unnecessary HTML elements (notably the outer div to contain the table; it also fixes the layout of descriptions containing bulleted or numbered lists or multiple paragraphs). verdy_p (talk) 06:25, 10 October 2016 (UTC)
verdy_p, localurl magic word is explained here and it seems to me that it is working fine. Category:Creator templates with non-matching home categories holds creator pages whose name does not match the category name. It is not a problem by itself but since most creator template names match the home category names, if someone needs a list of creator pages and their home pages, one can often use a shortcut and guess the name of the home category based on creator page name. However creator pages in Category:Creator templates with non-matching home categories need to be treated differently. You are saying that "category [is] overpopulated". Can you give any examples? --Jarekt (talk) 17:37, 10 October 2016 (UTC)
It is one of the tracking categories tested using "localurl:"; all these page are cetegorized due to missing links to pages named with a "localurl:", edit one of these pages, you'll see at the bottom a red link for missing included "templates"... verdy_p (talk) 20:56, 10 October 2016 (UTC)
Note: localurl does not work correctly to compare pagenames as they are returned by the internal PAGENAME parser function (and similar), because they are HTML-encoded (this is a problem for all pages containined as ASCII apostrophe for example in their name becaues tests with "#ifeq:" will not match them. We need a name canonicalisation (and unfortunately localurl does not work coherently when there are optional namespaces). To have coherent results, "#titleparts:" works much better (it has been tested since lon in French wikis where there are many page titles with apostrophes, and even here on Commons.
For some resons the proposal to change the way PAGENAME returns HTML-encoded names has not been accepted (because PAGENAME is frequently used within attributes where quotes cause problems.
The alternate proposal to fix #ifeq: so that it will HTML-decode its parameters was also rejected. And anyway we need a way to canonicalize pagenames with their correct namespace name (replacing aliases) and a single capitalization form for namespaces, and a correct capitalization for pagenames outside the namespace. verdy_p (talk) 21:03, 10 October 2016 (UTC)
verdy_p I edited one of the pages and I see no red links for any missing pages. The purpose of localurl is to grab 2 strings that could be in many alternative formats and create a 2 strings in unified format (whatever that might be) so they can be compared. Can you point out a specific page where something is not working right? --Jarekt (talk) 04:06, 11 October 2016 (UTC)

Attributed to

why is attributed to not working?--Oursana (talk) 02:08, 24 January 2017 (UTC)

@Oursana: Links to where it is not working are always valuable. Making others do all the work is not helpful, nor often a good way to get assistance. FWIW it works for me edit.  — billinghurst sDrewth 02:56, 24 January 2017 (UTC)
Sorry, I thought it might be a known problem with so many files. I mean the additions within the {{artwork}} Revision of File:15-07-05-Schloß-Caputh-RalfR-N3S 1712.jpg--Oursana (talk) 03:12, 24 January 2017 (UTC)
  Done @Oursana: The Option parameter was empty, as in it was missing Option = {{{1|}}} <!-- Do not modify -->. @Jarekt: Do you have a ready means to check for empty Option parameter?  — billinghurst sDrewth 04:42, 24 January 2017 (UTC)
Thank you--Oursana (talk) 05:13, 24 January 2017 (UTC)
The only way to check for empty Option parameter is to crawl through all the pages and verify that it is there. I do not remember the last time I have done it so I will run it again. --Jarekt (talk) 13:19, 24 January 2017 (UTC)
I added ~260 Option parameters. As of now all creator templates should have them. --Jarekt (talk) 16:43, 24 January 2017 (UTC)
perfect, thank you--Oursana (talk) 15:46, 5 March 2017 (UTC)

problems in ast

https://ast.wikipedia.org/w/index.php?title=Ficheru:Durer-self-portrait-at-the-age-of-thirteen.jpg&veaction=edit#filelinks --Oursana (talk) 15:46, 5 March 2017 (UTC)

Also for this see the first comment on your question in the last section! {{CountryAdjective|DE|lang=ast}} is not supported and gives Template:CountryAdjective/ast. The result is visible on https://commons.wikimedia.org/w/index.php?title=Creator:Albrecht_D%C3%BCrer&uselang=ast and thus on ast:Ficheru:Durer-self-portrait-at-the-age-of-thirteen.jpg. Template:CountryAdjective/ast should be created, but that should better be discussed on Template talk:CountryAdjective! --Marsupium (talk) 09:40, 22 March 2017 (UTC)
The problem with "ast" language (Asturian language ?) is deeper, as it is not in Module:Fallbacklist list. It is recognized by Wikimedia {{#time:l|now|ast}} returns "martes" but I do not know what does it fall back to. Should it fallback to Spanish and than English? --Jarekt (talk) 12:55, 22 March 2017 (UTC)

What to do with redundant fields?

If Wikidata is present and after we migrate all the data from Creator templates to Wikidata we should remove redundant data from Commons, after verifying that all the data was moved to Wikidata. For example "Name" field is not used if wikidata field is present and has labels. We could be deleting name fields in all verified templates. Same with dates or places. --Jarekt (talk) 05:00, 23 April 2017 (UTC)

Definitely! Many of these are quite out of date, I have noticed. Jane023 (talk) 06:53, 23 April 2017 (UTC)

Lua version is now live

I just switched {{Creator}} template to new code written in Lua: Module:Creator. Please report any problems here or at Module talk:Creator.

The code is mostly a copy of the old template, which is preserved at {{Creator/old}}, but there are changes:

  1. template relies heavily on data pulled from Wikidata, for example local "Name" parameter is not used if there are labels on Wikidata
  2. there is more wikidata maintenance categories like subcategories of Category:Creator templates with Wikidata link
  3. I removed support for Category:Creator templates with Wikidata link while keeping Category:Creator templates without Wikidata link.
  4. I also removed Category:Creator templates with authority control data while keeping Category:Creator templates with Wikidata link: local authority control

--Jarekt (talk) 15:03, 21 April 2017 (UTC)

Nice! The next step is to have creator templates auto-added to the creator categories. Jane023 (talk) 10:24, 22 April 2017 (UTC
Jane023 I actually do not know what you mean by that. Can you elaborate?--Jarekt (talk) 03:15, 23 April 2017 (UTC)
What I mean is this: often when a creator template is first created, it is placed in the "homecat" but not added to the homecat category file. I navigate to painter categories quite often and will add the creator template when I see it (and will often create it & then add it if not there at all). It would help if the category would just show the content of the creator template by default. Jane023 (talk) 06:51, 23 April 2017 (UTC)
Excellent Jarek! I added some more constraints on Wikidata to improve quality. I wonder how many constraints on d:Wikidata:Database reports/Constraint violations/P1472 we can clear based on Commons. Multichill (talk) 12:45, 22 April 2017 (UTC)
One issue with Wikidata constraints is that they assume creator templates are for people, so records associated with them have gender, date of birth and death, etc. However many records are for porcelain manufacturers, photography shops, etc. and they do not have gender, etc. I deleted some "anonymous" creator templates, and we probably should delete some other odd-ball templates. Something that still should be done is transfer of as much info from creator templates to wikidata. I created many new creator template maintenance categories and would like to use them to find what to move. I will also try to add more automatic ways to copy content to Wikidata, maybe with help of Quick Statements or some other means. Once we move all the data to Wikidata we probably should remove it from Commons to simplify maintenance. --Jarekt (talk) 03:14, 23 April 2017 (UTC)
On Wikidata we have 25586 humans with Commons Creator page (P1472) and 85 without (0,33%). That's an edge case. For other properties I just add these to the exceptions so they don't clutter the constraint report. Multichill (talk) 15:42, 23 April 2017 (UTC)
Thanks ! There is a problem on this page though File:Christolf et Cie - Amphitrite - Walters 71450 (2).jpg. -Zolo (talk) 16:02, 26 April 2017 (UTC)
It seems fine now. Hopefully something I already fixed. --Jarekt (talk) 17:46, 26 April 2017 (UTC)
Yes, it works fine now. --Zolo (talk) 12:48, 2 May 2017 (UTC)

The ID entered is unknown to the system. Please use a valid entity ID.

 please check your last edit twice, see Creator:Yakov Perelman, Creator:Victor Brauner, Creator:Toni Schneider-Manzell, Creator:Tomás Povedano and so on. Use of the previous version makes them fine. Sealle (talk) 12:47, 23 April 2017 (UTC)
Sealle, I wrote at en:Wikipedia_talk:Lua#How_to_debug_.22The_ID_entered_is_unknown_to_the_system._Please_use_a_valid_entity_ID..22_errors asking about those errors. They make little sense to me as the error message suggests that q-code is incorrect, which is wrong. I think it might be some wikidata software error and I will try phabricator, if nobody has any idea at Wikipedia. What is weird is that some of the affected pages are OK now, without any changes to the creator template or Wikidata. We can just use {{Creator/old}} for time being at the affected pages. --Jarekt (talk) 17:00, 24 April 2017 (UTC)
Jarekt, apparently all of those are OK now, but it looks like a heisenbug: pls see now Creator:Alfons Mucha and Creator:Wilhelm Groß. Sealle (talk) 17:24, 24 April 2017 (UTC)
  Fixed Creator:Yakov Perelman, Creator:Victor Brauner, Creator:Toni Schneider-Manzell, Creator:Tomás Povedano and others by using {{Creator/old}} instead of {{Creator}}. --Jarekt (talk) 17:31, 24 April 2017 (UTC)
OK, I see now. Sealle (talk) 17:35, 24 April 2017 (UTC)
In phabricator:T163815 User:Matěj Suchánek figure out the issue. So I hope to fix it in code soon. --Jarekt (talk) 17:50, 26 April 2017 (UTC)

Minor spacing-bug

Namaste. There is a bug involving value-spacing when (at least) Nationality and Occupation are munged into beginning of Description field. An example can be found in Creator:Edward Snowden where it renders without space as: "American activistComputer professional who leaked..." instead of expected rendering with space: "...activist. Computer..." or the like. Separator can be semicolon or comma in lieu of full-stop/period -- that's an editorial decision. --dsprc (talk) 06:22, 28 April 2017 (UTC)

I will fix it, although I will wait until a few of those accumulate before releasing next version. Thanks for reporting. --Jarekt (talk) 11:50, 28 April 2017 (UTC)

Dates on the Julian style

Hello. Incorrectly indicates dates for the Julian style. Example: Creator:Konstantin Pervukhin

I think I fixed Creator:Konstantin Pervukhin. If others are wrong please fix them. --Jarekt (talk) 19:51, 9 May 2017 (UTC)

Shows dates in the Julian style as Gregorian, if the wikidata date is in the Julian style. Example: Creator:Mikhail Kudryavtsev

References

The old template only used to show the "References" information if the current namespace was Creator (i.e. they were hidden from all other uses). This is no longer completely the case, it seems -- see Creator:Emma Kissling. The base data in that field is not displayed, but it contained regular wiki references itself, and that part *is* being displayed in transfusions. More minor, but it does not appear that the first bullet in the list in that section is being respected. Carl Lindberg (talk) 12:52, 14 May 2017 (UTC)

Carl, I just figured out what you are saying and that is strange. I just tested it and the old template did not show any wiki-references on the page. I have no idea why they are doing it, since if the text is not shown on the page than the references should not show either. But I will try to fix it. --Jarekt (talk) 22:41, 14 May 2017 (UTC)

Mistake in template

 
mistake in template creator

I think there is a mistake in template creator. Nationality and occupation and the content of the field "description" there shown in the same line without any blank (see pic). Can somebody fix this? Greetz! Bukk (talk) 11:28, 18 May 2017 (UTC)

Sorry, I didn't noticed the bug mentioned above ("Minor spacing-bug"). Greetz! Bukk (talk) 11:38, 18 May 2017 (UTC)

Recommendations for new templates

Due to new changes in the template the recommended format of the new templates will be to add all the info to Wikidata and create new Creator template only with:

{{Creator
 | Option    = {{{1|}}} <!-- Do not modify -->
 | Wikidata  = Q12022773
}}

There are several fields which are not presently handled at 100%, like: alternative names, complex dates not in ISO format, work places with list of places and dates, but I hope to better support them in the future. I will need to began task of updating the documentation. At the moment tools like [ https://tools.wmflabs.org/wikidata-todo/creator_from_wikidata.php creator_from_wikidata] should not be used. --Jarekt (talk) 15:33, 27 April 2017 (UTC)

We could also consider to allow the use of direct transclusions of Template:Creator instead of the creating of new creator template pages, e.g. {{Creator|Wikidata=Q29473318}} instead of a newly created Creator:Master of the Virgin of Benediktbeuern. (However, the linkback symbol should not be rendered then.) On the one hand the source code is probably less clear then. On the other hand this source code is anyway spare when the creator information for the artwork can be fetched from Wikidata through the item ID in hopefully near future.
At least Template:Creator possible or its rendering can now be transformed into that of Template:Creator if the Wikidata parameter is set and perhaps even without when the page is sitelinked to the creator's Wikidata item. --Marsupium (talk) 06:10, 10 May 2017 (UTC)
  Agree, use of {{Creator|Wikidata=Q29473318}} instead of creation of Creator:Master of the Virgin of Benediktbeuern is fine. --Jarekt (talk) 11:43, 10 May 2017 (UTC)
Would it possible to use Wikidata to allow use of the creator template with simply providing any authority control identifier? That is, could {{creator|viaf=61625857}} be used to pull back Ansel Adams by somehow looking up the Wikidata item where the property for VIAF identifier is 61625857? Dominic (talk) 18:56, 10 May 2017 (UTC)
Not at the moment. There is a phabricator proposal to allow look up of q-code based on value of a property, but at the moment that functionality does not exist. However if you have a list of VIAF numbers you can look up the q-codes and use those. You can also create a lookup template which when given a viaf number returns a q-code. if you than substitute this template ({{creator|Wikidata={{subst:viaf2qcode|viaf=61625857}}}}} you can end up with {{creator|Wikidata=Q....}}. I can set it up for you if you are interested. --Jarekt (talk) 20:43, 10 May 2017 (UTC)
The problem with the above recommendation that the new creator template not include all the authority controls as before (for example NLI is missing) also the Alternative names disappear. See this and this. And also, this tool. instead of saying not recommended anymore! why not to adjust to the new format? -- Geagea (talk) 21:34, 15 May 2017 (UTC)
The Authority control part did not change in last year or two and I do not recall supporting anything called NLI in the past. However if there is a good case for having it we can add it to Module:Authority control. As for {{creator|Wikidata=Q....}} being equivalent to hand crafted Creator template, That is more of an aspiration than reality at this point. Current template does not add alternative names, and I have a long list of things to fix. As for, creator_from_wikidata tool, current code has 90% of its functionality. creator_from_wikidata tool never handled alternative names properly and if those are needed they should be filled by hand. --Jarekt (talk) 02:14, 16 May 2017 (UTC)
NLI=National Library of Israel and you have already add it in the past - Template talk:Authority control/2016#National Library of Israel identifier. It was ok with the old format but it's missing in the new creator template format. -- Geagea (talk) 01:07, 17 May 2017 (UTC)

I looked more closely at NLI and we do support it. See for example

Authority control

. --Jarekt (talk) 03:23, 17 May 2017 (UTC)

NLI: 000093130 it's there...-- Geagea (talk) 03:25, 17 May 2017 (UTC)

On the Creator page for a new person, it still recommends using the old tool: "Use Commons from Wikidata Tool if you know wikidata q-code." The Haz talk 14:30, 22 May 2017 (UTC)

@Hazmat2: I have modified the editnotice template, removed lines and added a simple search facility for Wikidata.  — billinghurst sDrewth 06:43, 24 May 2017 (UTC)

Creating creator templates is now awkward ...

Help ! I have made a number of creator-template-things for artists etc. The first times were awkward, having to understand every step, but doable.

But things have radically changed. There seems to have been a bad change of policy. It is more linking to Wikidata, which seems, in se, good. But it has become now very difficult to create a Creator-item, there is no guidance or guided procedure for persons like me, who are not within the circle of Wikidata-illuminati. After the deprecation of the previous guided procedure, i twice (or maybe three times) managed to create a new creator-thingy, but i do not know how i made it and if i will manage in future ...

So, i do have some questions:

  • Why do you, managers/masters of the infrastructure of the Wikimedia Commons, hate the common Commons contributors this much ?
  • Will there be some form of understandable guidelines for creating Creator-thingies again ?
  • Will it in future be possible again for common people like me, to add a full name or an alternative name in a creator-thingy ?

Yours , --Paulbe (talk) 23:21, 23 May 2017 (UTC)

Paulbe, I am sorry you found current system harder to use. The intention was just the opposite. Relying on Wikidata data makes Creator data much more likely to be updated when better or new information is available and more likely to be in synch with the rest of Wikipedia. Also majority of new Creator templates were created by tools like "Creator from Wikidata" and there is no need for that as it is just easier to just give the template wikidata q-code and let the template pull the info from Wikidata. That said there is still a lot too be done: There are numerous small involvements that can be done to the new template. There is also a need for better documentation as you pointed out. One issue with documentation is the {{TemplateBox}} used for creating documentation pages is hard to use for pages that don't fit the most common pattern. Maybe what we need is documentation that something along the lines that there are really 3 ways of using the template:
  1. Most preferable (from maintenance point of view) is Syntax #1 or the template only has Wikidata and Options fields and all the rest is added to wikidata if needed. This syntax does not work at the moment for 100% of pages and I guess we need to link to How-to pages on Wikidata for those unfamiliar with it.
  2. Slightly less preferable is that you start with Syntax #1 look at the results and if some information is needed than you add local fields to the creator template (instead of adding info to Wikidata) until it looks right. It would be more convenient if you do not replicate Wikidata, so if date of birth shows up without adding birthdate than do not add it, Otherwise somebody in the future will need to compare them and check if they agree.
  3. The least preferred solution is Suntax #2 which relies 100% on Commons fields the way pages in Category:Creator templates without Wikidata link do. This option might not be convenient but people maintaining creator templates but it still works and will likely be with us for years to come.
So in other words, if new system it too painful to master than just use the old system or most convenient subset of the two. --Jarekt (talk) 02:24, 24 May 2017 (UTC)
@Paulbe: I have added a simple search to Wikidata for the creator name that you are undertaking, and hopefully that will make things easier. There is still the link to the template above the search, and you can stroll down to the #2 section. If you could explain the difficulties that you face, or the shortcomings on the presentation of the template then please express them.

Re the change, can I saw HURRAH, adding/fixing data at one place is a win. The Wikisources have been pulling wikidata data for a while and it is a godsend, especially with regard to images. I suspect that it will be even better here as there is more data pulled.  — billinghurst sDrewth

Support for 'near'

I see support for the 'near' option was removed from the template. Why? Its use also triggers Category:Bad use of creator template - option, even this option *is* mentioned in Template:Creator/doc. Jastrow (Λέγετε) 10:37, 29 May 2017 (UTC)

from User talk:Your revert on File:Chariot-race BM GR 1837.06-09.75.jpg

Hello Jastrow!
  1. I removed this option from this image, because it isn't and wasn't an entry in Module:I18n/name, which is used by Template:NameTemplate:Creator for validation. Pages with near pop up at Category:Bad use of creator template - option, which I work on.
  2. I checked all versions of {{Name}}, but found type near none-existing ever.
  3. If you want to use this entry, please give me a hint, what the near type means due to a creator. If possible post an example sentence or a synonym. I will implement it.
  4. Are there further discussions about these type entries? I read your post concerning {{Name}} discussion, but these give no explanation relating to near.
I would be glad, to add entry near to {{Name}}. –Plagiat (talk) 11:49, 29 May 2017 (UTC)
Near? For an author name? That doesn't make sense to me either.  — billinghurst sDrewth 12:48, 29 May 2017 (UTC)
I'm not talking about {{Name}}. {{Creator}} supported the 'near' option until 21 April. This option should have been ported along with support for 'manner of', 'follower of' and so on. Regarding usage, please refer to Template_talk:Creator/Archive_2#Determiner and Template_talk:Creator/Archive_2#Near. Jastrow (Λέγετε) 13:01, 29 May 2017 (UTC)
We had this discussion 5 years ago. I still find that term very confusing in English, but it might be just s specialized term used by art historians. wiktionary:near and w:Near do not mention that meaning of the word. The Concise Oxford Dictionary of Art Terms does not mention it either, nor does Art Glossary of Terms of The Art History Archive. Jastrow can you find any references describing use of that phrase In English? If we have references for such use we should add it to wiktionary:near and than link to it, because most English speakers would not know what that means. My theory is that in French "Près" might be used that way and "Près" is translated as "near" but in English we do not use word "near" that way. In English we would say in the manner of ... or in the style of .... We already have manner of ... so how is it different? If we decide to add it or add other terms in the future, then at the moment the support for 'manner of', 'follower of' and so on is in the Module:I18n/name so adding support for "near" would be done there. --Jarekt (talk) 01:58, 30 May 2017 (UTC)
We've had this discussion many times before, which I find a bit tedious to be honest. I can only quote what I wrote five years ago: "I'm fully aware it reads weird, but it's the accepted lingo. To be completely honest I'm not sure how it differs from 'manner of'. I use it when museums use it in their caption, that's all. A Google search for "near the * painter" "corpus vasorum" will show you how it's used in academic context. See also this alabastron in the Met, 'attributed to near the Laurion Painter'." Jastrow (Λέγετε) 08:55, 30 May 2017 (UTC)
I have added the option near. Output is Attributed to near the $name. I think this solves the problem phrase, which is used in academic descriptions. I hope I will find an suitable German translation, the meaning is similar to "Près". --Plagiat (talk) 12:16, 30 May 2017 (UTC)
Template Near has some translations of term "near" but I am afraid that those might be spacial proximity meaning. I still think we should add this meaning to wiktionary:near if we can find some reference justifying it. Currently {{name|near|John Doe}} gives "attributed to an artist close to John Doe" which I would not know what it means. We need a link to some explanation of the term. Also much more comprehensible English phrase would be "Attributed to style of ...". --Jarekt (talk) 12:34, 30 May 2017 (UTC)
I sometimes see phrase "Attributed to an artist near the Chicago Painter" as in here. That is much more clear in English. --Jarekt (talk) 12:47, 30 May 2017 (UTC)

┌─────────────────────────────────┘
I think its meaning is the environment, sphere or zone of influence of a person, group or organization. We shall add a person to attributed to near, because an artist doesn't make sense corresponding to a field author. --Plagiat (talk) 15:34, 30 May 2017 (UTC)

New Version of the template

I did a major upgrade to Module:Creator, fixing bugs in previous version and improving Creator template maintenance categories and Quick Statements (used to upload data to Wikidata). See Category:Creator templates with Wikidata link: quick statements. Please report any issues here. I have plans to do a lot of improvements to the template including rewriting parts or all of Template:NationAndOccupation in Lua. If anybody wants to collaborate, let me know. --Jarekt (talk) 17:39, 1 June 2017 (UTC)

This is great! I like the one-click preloaded QuickStatements form with data to import to Wikidata a lot! I hope the data transfer for Template:Artwork will also run this smoothly! Perhaps it could also add the properties reference URL (P854) and retrieved (P813) to the source. The function will be used a lot I guess, so this could pay off. Though it's not demanded here it would conform to the more strict rules for bots: d:Wikidata:Bots#Statement adding bots. retrieved (P813) may be especially relevant if you plan to remove the data from the templates here once it is transferred. --Marsupium (talk) 18:19, 1 June 2017 (UTC)
Marsupium, thanks for link to d:Wikidata:Bots#Statement adding bots I can easily add reference URL (P854) and retrieved (P813) to each statement although in my opinion it is kind of silly in this case, since it provides no additional information and only makes items more bulky. Since I can do it either way I might just ask at d:Wikidata:Project chat to see version is preferred. There is still a lot to be done on {{Creator}}, but than I was thinking about looking at {{Institution}} template, since they are so similar. So it is likely someone will beat me to {{Artwork}}. --Jarekt (talk) 19:24, 1 June 2017 (UTC)
Great Jarekt! I hope you'll take on {{Institution}} too :-)
What would you put in reference URL (P854)? Commons sure is not a valid reference. Multichill (talk) 19:35, 1 June 2017 (UTC)
Multichill, my understanding is that d:Wikidata:Bots#Statement adding bots ask for reference URL (P854) to URL of the wikipedia page so I would do URL to Commons page + date. It is still a very weak reference. --Jarekt (talk) 19:45, 1 June 2017 (UTC)
Someone messed up the bot policy page. Awesome. Fixed it. Multichill (talk) 19:56, 1 June 2017 (UTC)
Perhaps sometimes more diligence isn't vain: That was not "someone messing up the policy". User:ArthurPSmith "added requirements from conclusion of RFC d:Wikidata:Requests for comment/Improve bot policy for data import and data modification. --Marsupium (talk) 14:23, 3 June 2017 (UTC)

Approximate dates not reflected in output

cf. Creator:Sir James Prior.

His date of birth is given as "c. 1790", and I set that on Wikidata (d:Q17014517) using the appropriate magic qualifier. This template seems to fetch the year fine, but the qualifier is not reflected: it says "1790" instead of "c. 1790". --Xover (talk) 05:44, 20 June 2017 (UTC)

@Jarekt: Pinging in case you missed this yesterday. You'll want to support the sourcing circumstances property, with the qualifiers listed there (circa, near, presumably, and disputed), for dates (birth, death, floruit, etc.). --Xover (talk) 05:30, 21 June 2017 (UTC)
Yes at the moment the creator template does not handle complex dates from wikidata or any dates other than in YYYY-MM-DD, YYYY-MM or YYYY formats. I am planning to write some module to combine Module:Wikidata and Module:Complex date. In the mean time, if something does not work based on Wikidata, than fallback on local parameters. --Jarekt (talk) 10:56, 21 June 2017 (UTC)

Is Template:Creator needed after Wikidata?

[ the answer is "yes", but I wanted a catchy heading. :) ]

Looking at something like Creator:Edmond Malone, where all that's left locally are technical parameters and everything else is fetched from Wikidata. Do we really need to go by way of the T:Creator meta-template and a creator-specific T:Creator-wrapper, rather than just bung the Wikidata ID into a "creator-id" param on T:Artwork? Or less radically, just use something like {{Creator|Q1229512}} (without the creator-specific T:Creator-wrapper).

Of the four params left there (Sortkey, Wikidata, Linkback, and Option), |Option= is purely technical and an implementation detail; |Sortkey= can usually be derived from the structured data on Wikidata, or in a pinch can be explicitly set on Wikidata; |Linkback= has some purpose I'm not quite sure of but seems to be another implementation detail; and |Wikidata= which is the one value-adding param left.

In fact, for all creators where all relevant info is on Wikidata, software support in Mediawiki could provide proper UI for picking the association visually and by name rather than futzing with opaque technical identifiers (users should never have to deal with "Q1229512" unless they really really want to).

Anyways, I'm sure these aren't new ideas, but wanted to sort of send up a trial balloon to see if we're there yet. ----Xover (talk) 07:12, 25 June 2017 (UTC)

There are plans to introduce Wikidata-style structured data here, see Commons:Structured data/Sloan Grant. Hopefully, we will be able to fill the name of the creator through a nice interface, and the software will automatically render it in a creator-template-like using Wikidata. If that works, we might be able to get rid of creator pages that do not add any information relative to Wikidata. But no idea how things are going on in this respect. --Zolo (talk) 09:11, 25 June 2017 (UTC)
I think what Xover is saying is that, since for example {{Creator:Ramon Alorda Pérez}} and {{Creator|Wikidata=Q20006382}} gives exactly the same results than why do we need to set up Creator templates? Also why not just pass the creator q-code to {{Artwork}} instead of passing Creator template. And the answer is that the only advantage of creating page in creator namespace is to have a place to customize the look of creator infoboxes over what is generated with the wikidata, for example current software does not handle complex dates (that need {{Complex date}} template) or alternative names. Places have an issue described in Phabricator:T167521. So if creator page created only based on wikidata does not look right, you can customize it. Also {{Creator:Ramon Alorda Pérez}} might be easier to remember than {{Creator|Wikidata=Q20006382}}. If Wikidata has all the relevant properties than Sortkey, and Linkback, are not necessary. I assume that in the future artwork pages will look like {{Artwork|Wikidata=Q20006382}} and the template will add its own Creator template. --Jarekt (talk) 20:41, 25 June 2017 (UTC)
  Comment I am still using Alternative names = ... parameter; and with a separate namespace one can create redirects for alternate names.  — billinghurst sDrewth 13:15, 28 June 2017 (UTC

birthdate

does not show any more, only death date--Oursana (talk) 21:56, 7 June 2017 (UTC)

I just tried Creator:Biagio Camagna and it has both dates. Can you give an example? --Jarekt (talk) 02:07, 8 June 2017 (UTC)

I see dates all right, but there appears to be formatting issues when there are more than one of them. See [[Creator:Anselmo Bucci ]], when data stored locally are removed.

{{#invoke: Wikidata|formatStatementsE|entity=Q569638|property=P569}}

works fine: and .

That said, It would make more sense to use "or" rather than "and":

{{#invoke: Wikidata|formatStatementsE|entity=Q569638|property=P569|conjtype=or}}

works fine: or .

It would be even better if dates were sorted chronologically and if "may 1887" was shown only once. 23 May 1887 or 21 May 1887.-> 21 or 23 May 1887.--Zolo (talk) 13:52, 10 June 2017 (UTC)

There are still many issues with the new template and with date handling. I keep track of some of them at Module talk:Creator/sandbox. I was thinking about writing a new module to interface Wikidata and Module:Complex date, just did not get around to do that yet. I will concentrate on merging simple creator templates with wikidata, before I look into more complicated data. --Jarekt (talk) 14:57, 10 June 2017 (UTC)
Creator:Rogier van der Weyden doesn't show the birthdate, I saw several examples like this.--Oursana (talk) 20:21, 10 June 2017 (UTC)
I see the birthday in Creator:Rogier van der Weyden. Maybe purging will help. --Jarekt (talk) 02:36, 11 June 2017 (UTC)
I have the ›and‹ issue with location (P276) too. Workaround: Change rank:normal to rank:preferred, so only one (preferred) entry will be displayed. –Plagiat (talk) 12:17, 11 June 2017 (UTC)
If the values are equal, it's quite a bad idea to manipulate them in Wikidata to circumvent the flaws of a template on Commons not combining them correctly I think. --Marsupium (talk) 17:05, 12 June 2017 (UTC)
Current handling of dates works for a single ISO date and maybe foe other cases, but not much else. I am planning to Write some Lua code combing wikidata and module:Complex date, but at the moment we are stuck with 90% solution. Unless there is a clear preference between 2 Wikidata versions I would not be changing preferences there to suit our needs. Until there is new code for handling dates I think we need just add challenging dates by "birthdate" and "deathdate" parameters. Also if someone knows Lua and wants to try writing Lua code combing wikidata and module:Complex date, please give it a shot. --Jarekt (talk) 19:13, 12 June 2017 (UTC)
Sorry, I still do not see the birthdate after creator's name in Creator:Rogier van der Weyden, nor in Creator:Claude Lorrain as in many others. These give 2 birthdates by year--Oursana (talk) 23:06, 30 June 2017 (UTC)
  Fixed with help of parameter "Lifespan" (I ought to document it). I also hope to release better handling of dates by Creator templates soon. I just finish testing Module:Wikidata date I wrote for that purpose. --Jarekt (talk) 03:04, 1 July 2017 (UTC)
please check Creator:Antonello de Saliba--Oursana (talk) 22:04, 21 July 2017 (UTC)
@Oursana: This looks like an artefact of the limited support for complex dates in the current integration with Wikidata outlined above. I've added a |Lifespan= parameter as a workaround for now. @Jarekt: Pinging on the off chance you're not already aware of this issue. --Xover (talk) 07:22, 22 July 2017 (UTC)
thank you--Oursana (talk) 16:40, 22 July 2017 (UTC)
I do not see any issues with Creator:Antonello de Saliba. What was the issue there. --Jarekt (talk) 18:56, 22 July 2017 (UTC)
Revision of Creator:Antonello_de_Saliba did not show the birthdate--Oursana (talk) 23:24, 22 July 2017 (UTC)
At the moment the lifespan years if not precisely known are not shown and you are right I see a problem since in the revision you have shown the local death date should have overwrote wikidata one. --Jarekt (talk) 02:47, 23 July 2017 (UTC)

Issue with nationality from Wikidata

cf. Creator:Sir James Prior.

If I remove |nationality= from the template, the Description field disappears from the rendered output. Also removing |occupation= does not affect anything (in case there's a dependency that both be either local or both be from Wikidata). One possible reason I can think of is that his nationality on Wikidata is set to the w:Kingdom of Ireland (and should probably be w:United Kingdom of Great Britain and Ireland). The local parameter here is "IE" (which I'm guessing is either w:Republic of Ireland or, possibly, w:Northern Ireland). In our description, all the historical nationalities (and quite possibly also the modern ones) should be aliases of a meta-nationality displayed as "Irish". --Xover (talk) 05:55, 20 June 2017 (UTC)

I will revisit handling of |nationality= and |occupation= that might help with this issue, but in the mean time if something does not show properly based on Wikidata, than fine-tune it using template parameters. Last week I was removing many redundant fields from Commons templates, which are the same on Commons and Wikidata, simplifying the templates and making them easier to manage but I suspect that most will still rely on some local parameters. --Jarekt (talk) 11:54, 20 June 2017 (UTC)
I've run across a lot of Creator templates for artists whose nationality is Flemish, Southern Netherlandish, or Northern Netherlandish. These can't currently be pulled from Wikidata because Module:Creator assumes modern nation states (Template:CountryAdjective) with a two-letter ISO code, rather than historic countries (Template:Nationality). I think this can be fixed by simply adding the historic nationalities' Q-codes onto Module:Creator/conf mapping to the country adjectives that Template:Nationality understands (it's a short list, you might just snarf it all for a quickfix). But I'm not sure that solution scales with the number of historic nations that might be relevant (England and Ireland alone probably amount to 10-15 country-level legal entities).
And this raises a related issue: Commons has (aiui) treated |Nationality= as interchangeably either "Country of citizenship" and "School of". This sort of duality won't work when pulled from Wikidata where those concepts will be distinct and orthogonal properties. For instance, I just ran across a painter whose country of citizenship is Germany but is from the Flemish school. I suspect this will require changes to the information model of T:Creator to resolve; I don't think can be handled by simple preference/fallback type logic. Not sure how to handle that, so just flagging it as something to look into. --Xover (talk) 19:35, 24 July 2017 (UTC)

Work location from Wikidata

cf. eg. Creator:Théodore Baron. Pulling Workloc from Wikidata is limited to the last defined property. Should handle multiple locations, including the time periods specified there. (just dropping a note for Jarket's todo list ;D). --Xover (talk) 10:32, 18 July 2017 (UTC)

Work location is also something Module:Creator does not handle well. Ideally we could pull all the locations and the periods of residence, but that might become very long. To me this field on Commons often has too much information I never use. I find Work location mostly useful if places of birth and death are missing; otherwise I never look at it. But I agree that current approach of returning only (random) one from the list is wrong. At the moment my priorities were dates and places of birth and death. --Jarekt (talk) 15:57, 20 July 2017 (UTC)
I agree with your priorities. :) But I've not really seen any egregiously long list of work locations so far. Is it really a problem, or merely a dislike? Perhaps an approach could be to fetch them all but cap the number displayed to some generous but not excessive number? --Xover (talk) 13:40, 21 July 2017 (UTC)
I think it is more of a "merely a dislike" than "really a problem" but some creator pages have very long local lists of places and dates that must have taken a lot of work to research and assemble and I think make creator templates very long and unwieldy. I do not have example at the moment. I will try to fetch at least a list of all the places from Wikidata. --Jarekt (talk) 02:29, 23 July 2017 (UTC)
If the incidence is high enough to matter, perhaps a collapsible list could be used for display? --Xover (talk) 10:42, 24 July 2017 (UTC)
The whole creator template is collapsible. Collapsible list in collapsible template would be strange. Less developed Work locations might be my mild preference, but it is not much of a deal. --Jarekt (talk) 13:09, 24 July 2017 (UTC)

Quality of wikidata data

Just a general remark. The quality of data from wikidata is often bad, sometimes really bad. For starters, the dates are often very crude. Result: dates become distorted. Wikidata has to do better than this, otherwise there's no point using it. Vincent Steenberg (talk) 20:11, 18 July 2017 (UTC)

"The quality of data from wikidata is often bad" So fix it. (Note: seems to relate to this edit.) Andy Mabbett (talk) 12:14, 19 July 2017 (UTC)
Well, Wikidata is not to blame per se, but I’d agree that wide-spread removal of all local data can seem a bit hasty.
The approach that Jarekt is leading is very sensible to me: get bots to compare data, remove it locally when identical and flag it for human review otherwise. This makes a lot of sense. Jean-Fred (talk) 13:10, 19 July 2017 (UTC)
Right. Important context is that Vincent Steenberg's complaint does not appear to be with one of Jarekt's bot-assisted edits, but rather with one of my manual ones. I've not yet had time to unravel what it was specifically that was offensive in it (I suspect it's the date of birth/death vs. baptism/burial), but perhaps Vincent might be prevailed upon to make their complaint specific? (Vincent: on a personal note, I appreciate feedback; if you have a problem with my edits, please do let me know!) --Xover (talk) 17:40, 19 July 2017 (UTC)
Sorry, I got a bit frustrated after that edit on Creator:Simon Luttichuys. The thing is, only his baptism and funeral dates are known. For example his baptism took place on 6 March 1610. The RKD then concludes that he could have been born as early as February 1610. Fair enough, but a user on wikidata then took that date (fabruary 1610) and made it his birth date, refering even to the RKD record. That's not the way forward I think. Right now his birth date on wikidata is 1610. That's an improvement, but I think in these cases – and there are many of them – the baptism date/funeral date should be imported from wikidata rather than the factual date. Vincent Steenberg (talk) 20:20, 19 July 2017 (UTC)
@Vincent Steenberg: No worries. I'm prone to some measure of frustration myself in such circumstances (Shakespeare's birth vs. baptism and attempts to "fix" it are the bane of my existence!). :) In any case, thanks for the clarification. My edit there was clearly too aggressive and I should have checked it better. Mea culpa!
I do, however, have to disagree with you slightly on some things. The way Wikidata handles multiple, possibly conflicting, datum is to include all of them, but, where possible, to mark them as deprecated/normal/preferred. If a wrong, but cited, datum appears on an item, it shouldn't be removed but marked deprecated. And, in general, the information should reflect what the sources say, not what a Wikidata editor "knows" to be true. In other words, if Luttichuys's birth date is explicitly unknown, or is explicitly 1610 with year resolution, then that information should be added, cited, and set to preferred, rather than the bad date deleted. There are intricacies of course, like what to do with unsourced claims. but in broad strokes...
I would also question whether Commons really needs day-resolution dates for birth/baptism and death/burial, and thus also whether we need to care about baptism/burial dates (at year resolution, inferred birth/death dates are good enough). Wikipedia does, certainly, as will many other users of the data. But on Commons, I think, the year should suffice in practically every case. That's neither here nor there, of course, because in the task at hand we really do need to preserve whatever granularity of data is present on the Commons side.
And per Jarekt below, that probably means getting the handling of burial dates on Wikidata settled, and then adapting the code of the Creator template. In the mean time, please do let me know if you have concerns with any of my other edits! --Xover (talk) 13:30, 21 July 2017 (UTC)

"The quality of data from wikidata is often bad" might be true but as I am reconciling many of Commons/Wikidata conflicting dates, places and even genders - it is mostly Commons that is wrong (at least according to the online references available from Wikidata). One of the issues with wikidata is that as it aggregates information from many sources it also aggregates mistakes from many sources with no way to tell them apart. I have seen entries with 3 or 4 different dates each one with a different "reliable" source. About Vincent suggestion to import baptism date and funeral dates: the code's logic at the moment uses baptism date if birth date is completely missing, however that is probably rare as the birth date is set to the same year. At the moment I am not pulling funeral date as the discussion about how to save it continues here (please join the discussion). --Jarekt (talk) 15:37, 20 July 2017 (UTC)

As a first approximation, I'm thinking use the date with the highest resolution, or the birth/death date if resolution is the same. But since Wikidata has no way to indicate rank between two separate properties ("birth date" vs. "date of baptism"), perhaps it might even make sense to have a boolean flag on Creator to indicate editor preference for one or the other? As a safety valve for the possibility that there is some case where using a day-resolution birth date would be undesirable. --Xover (talk) 13:36, 21 July 2017 (UTC)
For instance, take a look at Creator:Sven Markelius. Both Birthloc and Deathloc would in most cases be given as "Stockholm" (analogous to "Greater London area"). The actual birth and death locations given on Wikidata are too specific for the use on Commons (but Wikipedia might want it that specific). A way to indicate desired granularity may be needed for most params, and for this example, relatively complicated code to walk the tree up to a relevant level (municipality, in this case). --Xover (talk) 13:50, 21 July 2017 (UTC)
Oh, and mustn't forget about floruit dates. --Xover (talk) 08:50, 22 July 2017 (UTC)
Ok I will try to use date of baptism if it is more precise than date of birth. Or maybe just show both dates in the same field. Anyway any information from wikidata can be overwritten with the local parameter (all except for name at the moment), so if place is too precise or date if wrong than just overwrite it. My bot is assisting me in removing redundant field, but the only way other fields should be changed is once someone look at them and decide that wikidata info is better than Commons. --Jarekt (talk) 02:13, 23 July 2017 (UTC)
Right, we can override data locally, but then we're no further in the goal of reducing local possibly-conflicting local data. I've been chipping away at one of the maint. categories, and it's a bit too high an incidence of the problems above and necessitating the use of local overrides. Some can be fixed by fixing the data on Wikidata, but for others we run into conflicting information models (lack of burial date on WD, just as a obvious example) or contextually specific display preferences (like specificity of locations). Some of this stuff will require significant code changes to resolve, and, as mentioned above, conflicting goals will require local overrides in a way that does not propagate duplicative data (e.g. a boolean param to prefer baptism/burial or floruit dates over birth/death). --Xover (talk) 10:35, 24 July 2017 (UTC)
I do not think we can ever have creator template that will always pick ideal display format based on available Wikidata data. Most new templates do not use a lot of customization with local parameters and stick with the default, which I guess is good enough and might improve. By the way, floruit dates would be going into "Workperiod" field not birth/death dates. Right? --Jarekt (talk) 13:20, 24 July 2017 (UTC)
No, I think floruit dates would usually be used in place of birth/death when the latter are unavailable or otherwise undesirable (disputed, too imprecise, etc.). So in parens after the name in the header, or to replace the birth/death date in the table proper. Speaking from a historicist perspective, the idea is that birth/death and floruit are there to help identify the specific individual in question. Thus also work period; i.e. "The artist that worked in watercolours and that painted bridges and windmills, that was active in Antwerpen between 1280 and 1322." But when we're into that level of detail on presentation, I'm probably not the best person to ask. I'm a dabbler on Commons, and deal much more with writers than visual artists, so the conventions in that field on this project may be different. --Xover (talk) 14:42, 24 July 2017 (UTC)
So the dates in the top row after the name usually come from birth/death dates (local or from wikidata) or in some cases birth/death year fields (used when date is uncertain but year is not), but if those were missing than people usually added them to the end of "Name" field. With the wikidata based templates "Name" field is no longer used and I am moving dates found at the end of "name" field to "Lifespan" field. If there are no birth/death dates or local "Lifespan" field than I place dates from "Workperiod" field in the top row with "Fl." in front of them (see here). However we never place Workperiod dates in birth/death date fields or properties. I hope this makes sense. --Jarekt (talk) 16:52, 24 July 2017 (UTC)

Historical place names

Another issue that may bite us in use of Wikidata... Present day Saint Petersburg has changed names several times. In 1914, the name was changed from Saint Petersburg to Petrograd; in 1924 to Leningrad; and in 1991 back to Saint Petersburg. For a birth or death date in 1954 say, it would arguably be correct to say that death location was Leningrad. Pulling this from Wikidata will result in Saint Petersburg (Leningrad is just an alias of Saint Petersburg there). Currently the only ways to handle this is to either accept the anachronistic name, or to override it locally with all the issues such local overrides carry with them. I can't really think of a good solution for this, so I'm just dropping it here for better minds than mine to chew on. --Xover (talk) 14:41, 21 July 2017 (UTC)

Saint Petersburg, Leningrad and several other spellings were always redirected to "Saint Petersburg" if used in creator template and the same way on Wikidata last time I checked there was only one item for them. The only exception is Tokyo and Edo which for some reason have separate items and in the past had separate internationalization templates on Commons. --Jarekt (talk) 02:40, 23 July 2017 (UTC)

Alternative names from Wikidata

Alternative names from Wikidata seems to still be missing. (just dropping a note for Jarket's todo list ;D). --Xover (talk) 14:15, 18 July 2017 (UTC)

I was not sure how should I handle them and I did not want to repeat bad handling of alternative names by the Magnus' tool that was used in the past to cast Wikidata info to Creator template. The issue is that on Wikidata you have list of alternative names for each language. Magnus' tool gathered them all and added different spelling of the names in different languages and alphabets. That resulted in often a very long list of with Alternative names in every alphabet. I think that for example for Russian names an Russian, English and German spellings are all you need and for western European names we do not need variants in other alphabets. I could start pooling only alternative names in English, which will be better than nothing but will not work for names in other alphabets. --Jarekt (talk) 15:48, 20 July 2017 (UTC)
Isn't LangSwitch the established way of dealing with that on Commons? --Xover (talk) 13:42, 21 July 2017 (UTC)
Most names do not have different alternatives in different languages, but some do. We could run all the alternatives from all the provided languages through LangSwitch, buth than if there are 5 alternatives in english and 1 in french than french speaker will see only one. I now know how to access aliases so I will give it a shot. --Jarekt (talk) 02:23, 23 July 2017 (UTC)
That would be the case here too (absent Wikidata) if LangSwitch is used. And any existing LangSwitch alternate names locally can be moved to Wikidata. --Xover (talk) 10:40, 24 July 2017 (UTC)
I think it isn't a good idea to use the Wikidata aliases instead of the current local alternative names here on Commons. The aliases are often very messy, containting ASCII-normalized labels, aliases imported from ULAN by Multichill and similar messy data, they simply serve another purpose obiously. Some of the local values here could be replaced by evaluating birth name (P1477) and pseudonym (P742), e.g. the {{name|birth|Jeffrey Koons}} on Creator:Jeff Koons. For other uses we need a new property on Wikidata perhaps. Perhaps native label (P1705), name in kana (P1814), name in native language (P1559) have some value, too. (I haven't investigated how those are used.) --Marsupium (talk) 17:31, 26 July 2017 (UTC)

Mix'n'match

I started a Mix'n'match project to use that tool to match some of creator templates in Category:Creator templates without Wikidata link with wikidata items. If anybody wants to try to work with this cool tool please give it a shoot. The manual for the tool can be found at meta:Mix'n'match. The tool will add Commons Creator page (P1472) properties to the matched items. --Jarekt (talk) 17:19, 26 July 2017 (UTC)

Occupation/natinnality description in Hebrew

The description in English is Nationality and then occupation. But in hebrew it should be the other way round. First occupation and than nationality. Can work also: "occupation1, occupation2, and occupation3 nationality". I fixed it what evryting was in template. But now with "module", I dont know how to change it. -- Geagea (talk) 07:31, 7 August 2017 (UTC)

Return to "Creator/Archive 2" page.