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
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
