On 05.11.2012 05:43, Tim Starling wrote:
On 02/11/12 22:35, Denny Vrandečić wrote:
- For re-rendering the page, the wiki needs access to the data.
We are not sure about how do to this best: have it per cluster, or in one place only?
Why do you need to re-render a page if only the language links are changed? Language links are only in the navigation area, the wikitext content is not affected.
Because AFAIK language links are cached in the parser output object, and rendered into the skin from there. Asking the database for them every time seems like overhead if the cached ParserOutput already has them... I believe we currently use the one from the PO if it's there. Am I wrong about that?
We could get around this, but even then it would be an optimization for language links. But wikidata is soon going to provide data for infoboxes. Any aspect of a data item could be sued in an {{#if:...}}. So we need to re-render the page whenever an item changes.
Also, when the page is edited manually, and then rendered, the wiki need to somehow know a) which item ID is associated with this page and b) it needs to load the item data to be able to render the page (just the language links, or also infobox data, or eventually also the result of a wikidata query as a list).
As I've previously explained, I don't think the langlinks table on the client wiki should be updated. So you only need to purge Squid and add an entry to Special:RecentChanges.
If the language links from wikidata is not fulled in during rendering and stored in the parseroutput object, and it's also not stored in the langlinks table, where is it stored, then? How should we display it?
Purging Squid can certainly be done from the context of a wikidatawiki job. For RecentChanges the main obstacle is accessing localisation text. You could use rc_params to store language-independent message parameters, like what we do for log entries.
We also need to resolve localized namespace names so we can put the correct namespace id into the RC table. I don't see a good way to do this from the context of another wiki (without using the web api).
-- daniel