|operations/mediawiki-config : master||Added setting to adjust the range of PropertyIDs using new link formatter|
|operations/mediawiki-config : master||Beta: use the new link formatter to format P1 on wikidata beta|
|operations/mediawiki-config : master||wmgWikibaseMaxItemIdForNewPropertyIdHtmlFormatter fully on|
|operations/mediawiki-config : master||wmgWikibaseMaxItemIdForNewPropertyIdHtmlFormatter 3000|
|operations/mediawiki-config : master||Introduce wmgWikibaseMaxItemIdForNewPropertyIdHtmlFormatter|
|mediawiki/extensions/Wikibase : master||Use link formatter using cache instead of wb_terms for properties|
|mediawiki/extensions/Wikibase : master||Renamed ItemIdHtmlLinkFormatter to ItemPropertyIdHtmlLinkFormatter|
|Resolved||Addshore||T201831 Deploy item/property link formatter that uses cache instead of wb_terms DB table|
|Resolved||Addshore||T201838 Use link formatter that uses cache instead of wb_terms for all wikidatawiki properties|
It is not only config change indeed.
It's a bit odd as the thing is called ItemIdHtmlLinkFormatter
yeah, it might not be that obvious, especially that currently the code in this class is basically the same as in LabelsProviderEntityIdHtmlLinkFormatter.
To quote the commit message of aef2372916411750a2d2a1274958ca1400ffb261: "This (separating the link formatter for itemd IDs) is needed to be able to evolve it separately from the one for Properties."
Those formatters haven't evolved that far away just yet. I am not sure if this is going to happen. I do remember though that the existing formatter weren't perfect (e.g. link's "title" attribute showing ID, whereas there were ideas it could e.g. show description). So it does not seem necessary to have a separate formatter class for property IDs (this statement with a remark that I am not aware of detailed plans of UI changes, so might be completely wrong). It might be better to rename ItemIdHtmlLinkFormatter, or even more drastically fold it back to LabelsProviderEntityIdHtmlLinkFormatter, if they're really 100% the same, and are only is used in the very same contexts.
Code changes related to property formatting coming up!
and LabelsProviderEntityIdHtmlLinkFormatter indeed seems to be used more broadly than ItemIdHtmlLinkFormatter so it might be better to be careful with jumping to conclusions too early (I mean conclusions on merging those two classes)