Sat, Apr 7
I don't know, I only know the one of the example I provided.
Mar 16 2018
The same happens with templates. You can change a template without that affecting the watch list entries or recent changes entries of the articles using that template. Additionally, the CSS pages used in the article are in the Transcluded templates list (page information) and in the Templates used in this page list (edit), so it is exactly the same as the templates for that too.
Mar 15 2018
At eswiki we mostly use it for the infoboxes and there are some things we have to do in many infoboxes that could be useful for others too:
Feb 7 2018
Nov 3 2017
Sep 21 2017
Aug 31 2017
@Joe, that might be true for the htmlCacheUpdate jobs, but not for the refreshLinks jobs. From my understanding, the refreshLinks jobs should be processed even if they are older than the max TTL, because discarding those jobs only because they are old would make the categories, backlinks,... less accurate.
Aug 18 2017
Aug 16 2017
Aug 14 2017
This doesn't only happen in commons. It happens also in eswiki. The categories aren't refreshed until a null edit.
Aug 5 2017
At least in eswiki we would also need a way to check if an entity or a value are from a given type (or list of types). For us it would be very useful having a way to do queries like this through Lua:
Aug 4 2017
@Lea_Lacroix_WMDE for what I see the problem seems to be that the new tables are populated only for meta. If a local user page is used instead of a global user page a null edit in the user page fixes the problem. Maybe the script used to populate the tables on meta should be used also in Wikidata (and in all the other wikis if the babel info is used also in those wikis for something)?
Aug 2 2017
Jul 30 2017
@Sjoerddebruin, you can go to the input of the widget using the tab. There are many things that aren't nice with this (like the drop downs not being removed when you go to the widget or not being able to save pressing enter in the widget) but I usually do it only with the keyboard and there are no major problems other than a few usability improvements that I noticed.
Jul 4 2017
Jul 1 2017
Jun 27 2017
@Lucas_Werkmeister_WMDE It's still triggering the error for the author property of Q6012487 and probably many others. I suppose it's the same problem, so I don't know if it would be more appropriate reopening this bug or creating a new one.
Jun 9 2017
OK @Lucas_Werkmeister_WMDE, so if that's intended I think it works as expected. Thanks.
@Lucas_Werkmeister_WMDE I think it is working now, but I think there may be a problem still in how the value type constraint is checked (or with my understanding of what a type is). It still displays an error when the entity instead of being an instance of a given entity is a subclass of a given entity, anyway, in this case I don't know if the problem is with the constraint itself or with my understanding, but for me if a cars are a subclass of vehicles they are still vehicles (as well as all the instances of the car class).
Jun 8 2017
@Salix, looking a bit through meta to look for something that could be more helpful to you I found a script by @Krinkle that simplifies the process of adding a new button to the new toolbar. Is this alternative useful to you or it is still too complex?
@Salix, did you check the mediawiki.org page about customizing the 2010 editor?
May 27 2017
@MGChecker I'm not talking about linking the properties, I'm talking about displaying them based on the property. It doesn't affect Wikidata, while it will have the desired behavior on the client wikis. Anyway you may not realize that even if what you are saying about the redirects is already done in many wikis it gets confusing from the Wikidata perspective. If in Wikidata someone goes to the Bonnie article of enwiki and they don't realize they were redirected to an article about Bonnie and Clyde they could think it is a bug or remove the sitelink. There is no indicator in Wikidata that the link will be to a redirect page, so the link doesn't follow the expectations of the user. Being able to use redirects as sitelinks in Wikidata using the "workaround" you described is clearly a bug, not a workaround, and that should be fixed, not allowing them is the expected behavior here. Using redirects you are linking articles about different topics together without the reader being able to know the difference between both.
I don't think that allowing sitelinks to redirect pages would be good in this context. I think that a better solution for this problem would be displaying the sitelinks to the elements linked by the properties has part (P527) and part of (P361) of the Wikidata item. This would be more easily maintainable both in Wikidata and in Wikipedia, and would prevent having to create redirects for all the articles that people wants to link.
May 26 2017
May 24 2017
May 21 2017
Aug 21 2016
Jun 3 2016
Jun 1 2016
One reason I see for the need of a null edit is that the articles from the categories take forever to be updated when the categories are added automatically through templates that use Wikidata to update. It can be specially annoying when this categories are maintenance categories and you have to wait until there is a legitimate edition to the modified pages to update the category links. At the end it's common to end up making null edits or &forcelinkupdate to update the category and know which pages are really still requiring maintenance.
May 21 2016
May 6 2016
Feb 7 2016
Feb 6 2016
Feb 5 2016
Feb 3 2016
Jan 31 2016
More or less. What I suggest is to make the default: empty and the others not visible for the values which have it undefined. If one parameter have a default value and the others no the one with the default parameter should be the only one specifying a default.