I was checking out Iran monuments on the Heritage API and it seems like they're loaded, but the links to the wiki pages unfortunately aren't there, even the bluelinks.
Note that those results are coming from here, where there are definitely pages that exist.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T183712 Move WLM monuments data to Wikidata | |||
| Resolved | Lokal_Profil | T174966 Move WLM-IR data to Wikidata | |||
| Open | None | T142897 Heritage Monuments database/API seems to be lacking Wiki page links |
The mapping assumes that the wiki article is the page which the name parameter wikilinks to.
Looking at the source for the page it however seems as though the links are being generated by either another parameter or by the template assuming that the name parameter can always be used as a wikilinks?
So the "name" parameter here is "توضیح" which technically means "description" if you ask me.
Could you point me to the logic that determines the (localized) "name" parameter and also a valid/working table of this nature? Thanks!
So (if I understand things correctly) the template today simply wraps name/توضیح/description in [[ ]] to try and create links to articles. That is why most of them are red links.
So توضیح=test is rendered as [[test]].
What the bot currently expects is that the link is made explicit in the parameter. i.e for the above example it would expect توضیح=[[test]].
The reason for this is that there is no way for the bot (as it currently works) to know if the link is red and blue so with the current way the parameters are handled it would have to assume that they all exist, which is obviously not true. The benefit of the توضیح=[[test]] method is that you would only link the text where there is an article and of course you can use normal disambiguation such as توضیح=[[test (the other one)|test]].
Some countries also have the article link as a separate parameter in the template, the end result is similar to using توضیح=[[test]].
The mapping logic for the various parameters can be found here.
Setting this to stalled as it requires a change on the fa.wiki side first to work (or a mechanism to validate links but that sounds expensive)
So for the monuments database side it think (@JeanFred correct me if you disagree) it might be to expensive to, during each harvest, evaluate if the auto generated link goes to an existing page or not. To allow the article to be harvested would then require either a new parameter which gives the target for the wikilink (when one exists) or that the name/توضیح field is changed to include [[ ]] syntax when the value should be wikilinked. Both these solutions also allow you to link to articles that don't have the same exact name as the monument (e..g due to disambiguation). Out of these two I would recommend the first.
Note that Iran is not the only country with this issue, it is also true for many (most?) of the Latin American lists (PE, VE, CL, BO, CO, UY at least). These autowikilink the name unless, a link target parameter is provided in which case that is used instead, or a second link target parameter is used in which case you can link to multiple articles from the name filed. So I would suggest we figure out a general solution before we start recommending any country to start doing changes.
From a migration point of view (i.e. T174966: Move WLM-IR data to Wikidata). If the links get harvested by the monuments database then migrating them is not an issue. If they don't then it is possible to check if there an article exists with the same title as the name/توضیح field and if it is not a redirect and if so use that as the target item on Wikidata. This requires that you are confident that these links are always (or in the large majority of cases) appropriate because we will be inserting monument specific statements into the corresponding item.
Found this one again. @JeanFred do you agree that validating the links (likely for all datasets) would be expensive or do you think that is doable?
In general do we want to recommend any particular solution?
This open task is tagged with Wiki-Loves-Monuments 2017 which was three years ago. If this task was/is resolved, then please update the task status. If this task was not resolved but is still valid, then please update the project tags to include at least one active project tag, so this task could be found when looking at that other project. (Without reaction, this task might get declined at some point.) Thanks a lot!
@Aklapper (a general response to most of the dozens of changes you made) a number of these just need to be moved to a to-be-created 2020 board, in order not to loose track. The team currently has no bandwidth to actually address these issues - hopefully that changes again.
Changing to decline would not be helpful for long term tracking. Please consider this a 'reaction' to all of those, I don't have the means to mass-respond or even evaluate the dozens of emails I just got from you.
Given that WLM is an ongoing effort, anything that is left on an old board may be considered relevant for future years. We are probably not exactly using Phabricator the way it was intended, sorry for that.
@Effeietsanders: Hi, if there is no capacity then tasks should not be moved to "2020" but to the Backlog of https://phabricator.wikimedia.org/project/board/575/ . If you'd like a 2020 board please see https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects - thanks!
Removing Wiki-Loves-Monuments 2017 tag as that was three years ago; adding general Wiki-Loves-Monuments tag.
Removing task assignee due to inactivity, as this open task has been assigned for more than two years (see emails sent to assignee on May26 and Jun17, and T270544). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be very welcome!
(See https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.)