Does anyone mind if I create a magic word for current user's language? It will not fragment parser cache further than it is already because we already support {{int:}}. Note that this functionality is already emulatable with perversions like http://is.gd/4HQPeI - would be good if we saved users from PITA like this.
On Thu, Jan 26, 2012 at 10:29 PM, Max Semenik maxsem.wiki@gmail.com wrote:
Does anyone mind if I create a magic word for current user's language? It will not fragment parser cache further than it is already because we already support {{int:}}. Note that this functionality is already emulatable with perversions like http://is.gd/4HQPeI - would be good if we saved users from PITA like this.
There is a bug on BZ about this somewhere. You might also want to wait for Tim to get back to you, he was in SF for the hackathon and is traveling back home today.
Roan
Roan Kattouw wrote:
On Thu, Jan 26, 2012 at 10:29 PM, Max Semenik maxsem.wiki@gmail.com wrote:
Does anyone mind if I create a magic word for current user's language? It will not fragment parser cache further than it is already because we already support {{int:}}. Note that this functionality is already emulatable with perversions like http://is.gd/4HQPeI - would be good if we saved users from PITA like this.
There is a bug on BZ about this somewhere. You might also want to wait for Tim to get back to you, he was in SF for the hackathon and is traveling back home today.
https://bugzilla.wikimedia.org/show_bug.cgi?id=2085
I found this bug via Google, by the way (cf. https://bugzilla.wikimedia.org/show_bug.cgi?id=33406).
MZMcBride
On 26/01/12 22:29, Max Semenik wrote:
Does anyone mind if I create a magic word for current user's language? It will not fragment parser cache further than it is already because we already support {{int:}}. Note that this functionality is already emulatable with perversions like http://is.gd/4HQPeI - would be good if we saved users from PITA like this.
I don't mind as far as it's a magic word (ie. they still need to use int: to get it)
Max Semenik:
Does anyone mind if I create a magic word for current user's language? It will not fragment parser cache further than it is already because we already support {{int:}}. Note that this functionality is already emulatable with perversions like http://is.gd/4HQPeI - would be good if we saved users from PITA like this.
One possibility would be for that magic word to be used on every single page, for example to localize the stub / help templates appearing at top of the page.
I guess that would destroy the parser cache entirely.
On 30.01.2012, 12:36 Antoine wrote:
One possibility would be for that magic word to be used on every single page, for example to localize the stub / help templates appearing at top of the page.
I guess that would destroy the parser cache entirely.
Well, surprise: EVERY IMAGE PAGE ON COMMONS already has language-specific cache keys because it uses {{autotranslate}} and other stuff that relies on {{int:}}. Furthermore, in page source of [[en:Barack Obama]] (the typical modern example of performance engineer's hell):
<!-- Saved in parser cache with key enwiki:pcache:idhash:534366-0!*!0!!en!4!* and timestamp 20120130094638 generated by srv285 --> Ooops, cache is _already_ fragmented. I wasn't asking for another way of cache fragmentation, I merely proposed that we make retrieval of current language code less hacky and slow. :)
On Mon, 30 Jan 2012 02:35:06 -0800, Max Semenik maxsem.wiki@gmail.com wrote:
On 30.01.2012, 12:36 Antoine wrote:
One possibility would be for that magic word to be used on every single page, for example to localize the stub / help templates appearing at top of the page.
I guess that would destroy the parser cache entirely.
Well, surprise: EVERY IMAGE PAGE ON COMMONS already has language-specific cache keys because it uses {{autotranslate}} and other stuff that relies on {{int:}}. Furthermore, in page source of [[en:Barack Obama]] (the typical modern example of performance engineer's hell):
<!-- Saved in parser cache with key enwiki:pcache:idhash:534366-0!*!0!!en!4!* and timestamp 20120130094638 generated by srv285 -->
Ooops, cache is _already_ fragmented. I wasn't asking for another way of cache fragmentation, I merely proposed that we make retrieval of current language code less hacky and slow. :)
The TOC on that page should be the causes of that cache fragmentation. Theoretically that should be the very last built-in language cache fragmenting thing. That's on the to-do list for being eliminated, just like the cache fragmentation caused by edit section links was.
Daniel Friesen wrote:
<snip> > [[en:Barack Obama]] (the typical modern example of performance > engineer's hell): > > <!-- Saved in parser cache with key > enwiki:pcache:idhash:534366-0!*!0!!en!4!* and timestamp 20120130094638 > generated by srv285 --> > > Ooops, cache is _already_ fragmented. I wasn't asking for another > way of cache fragmentation, I merely proposed that we make retrieval > of current language code less hacky and slow. :)
The TOC on that page should be the causes of that cache fragmentation. Theoretically that should be the very last built-in language cache fragmenting thing. That's on the to-do list for being eliminated, just like the cache fragmentation caused by edit section links was.
Could you possible open a bug for that and mark it as blocking tracking bug 28424 "Avoid parser cache fragmentation":
https://bugzilla.wikimedia.org/show_bug.cgi?id=28424
Thanks!
wikitech-l@lists.wikimedia.org