https://bugzilla.wikimedia.org/show_bug.cgi?id=14404
--- Comment #22 from Philippe Verdy <[email protected]> 2010-07-17 07:34:10 UTC --- > Ahh, but this would recurse too. Imagine if {{ {{int:foo}} }} called potentially up to N templates, each of which had another {{int:}}. Two deep would be N^2 Actually no ! The UI language is always the same while rendering a page. So all dependencies are computed within the restricted set of the contant UI language. This will never multily the number of rendered pages to manitain in the cache, but will only store different versions (and different lists of backlinks for each UI language) ONLY when that UI language is used. What does this means ? Backlinks are all dropped from a page when it is edited, but as it is saved, it is always within the contect of a specific UI language. If later a visitor comes that wants another UI language, it won't be present in the cache and the page will be regenerated. You can still minimize the impact of #int: and of {{USERLANGUAGE}}: when evaluating end rendering pages, detect if one of them is used (use the same algorithm used for computing lifetimes of pages) : first start evaluating as if the page was generated within a locale-neutral root language. Then if one of these #int: or {{USERLANGUAGE}} is being evaluated, set the language code in the result structure (that contains the generated text, the lifetime, and the UI language code). After evaluating all the page, you immediately see if the result is dependant from a UI language, and if so, you'll index the generated page in the cache as {{UILANGUAGE}}:{{FULLPAGENAME}} and you'll drop: :{{FULLPAGENAME}} from the cache. Otherwise you'll index it as :{{FULLPAGENAME}} and you'll drop all pages in the cache that match: *:{{FULLPAGENAME}} With such algorithm, you can significantly reduce the workload because a lot of pages or templates do not depend on the UI language. And you absolutely don't need to regerate at the same time all the pages for all supported UI languages: generate them only on the fly, as they are effectively demanded by users (the first version that will be indexed will be the version built for the UI language used by the page editor saving it, but only when it will be requested through as standard GET request after saving it and being redirected to it. Additional backlinks (to templates or page names that depend on the UI language) can be added as well on the fly very long after the page has been saved, but of course, you also opt for rendering the page immediately in and save the backlinks for the page being rendered for the default Project language (my opinion is that it would complicate things for no benefit, and would increase the response time for the user saving a page while its UI language is not the default UI language of the project). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
