LanguageSelector on strategy wiki

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

LanguageSelector on strategy wiki

Gergő Tisza
The LanguageSelector extension [1] can automatically set the interface
language based on browser settings, which is nowadays the norm for
every serious multilanguage web page. It is not used on WMF wikis,
because it would interfere with caching. The strategic planning wiki
[2] has, however, relatively low traffic, and probably much higher
logged-in to anon ratio than the rest of the sites. Any chance
LanguageSelector (or something equivalent, if it exists) could be used
there?

[1] http://www.mediawiki.org/wiki/Extension:LanguageSelector
[2] http://strategy.wikimedia.org/wiki/Main_Page

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Brion Vibber-3
On 9/9/09 6:28 AM, Tisza Gergő wrote:
> The LanguageSelector extension [1] can automatically set the interface
> language based on browser settings, which is nowadays the norm for
> every serious multilanguage web page. It is not used on WMF wikis,
> because it would interfere with caching. The strategic planning wiki
> [2] has, however, relatively low traffic, and probably much higher
> logged-in to anon ratio than the rest of the sites. Any chance
> LanguageSelector (or something equivalent, if it exists) could be used
> there?

Not sure; it ties in with the rest of our infrastructure so it's got the
same caching layers in front of it...

We've been hashing around the idea of allowing Accept-Language through
for eg Chinese variant selection, but the main problem with doing it
well is that we need some pre-processing at the cache level to keep the
cache locality relatively non-insane. :) The set of possible
Accept-Language headers is open-ended and huge, so we can't just add a
Vary: without greatly increasing the amount of cache space that'll be
used by that site.

That would be easier to do with Varnish (which has a much cleaner
plug-in system) than with Squid, but we're nowhere near a Varnish
deployment yet.


Mark, how hard would it be in theory to swap some settings around to
make one of our low-traffic sites take different caching
characteristics, like leaving just strategy.wikimedia.org with either a
Vary: Accept-Language or just having it not cache as much?

-- brion

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Domas Mituzas

> Mark, how hard would it be in theory to swap some settings around to
> make one of our low-traffic sites take different caching
> characteristics, like leaving just strategy.wikimedia.org with  
> either a
> Vary: Accept-Language or just having it not cache as much?

thats not squid setting, one can just send proper cache-control headers.

on the other hand, can we please avoid having these kinds of "special  
cases" all over - it is pain to do performance management with current  
stuff already.

Cheers,
Domas

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Brion Vibber-3
On 9/10/09 9:04 AM, Domas Mituzas wrote:
>
>> Mark, how hard would it be in theory to swap some settings around to
>> make one of our low-traffic sites take different caching
>> characteristics, like leaving just strategy.wikimedia.org with
>> either a
>> Vary: Accept-Language or just having it not cache as much?
>
> thats not squid setting, one can just send proper cache-control headers.

As long as Squid isn't overwriting those headers, as we do for
Cache-Control. :)

> on the other hand, can we please avoid having these kinds of "special
> cases" all over - it is pain to do performance management with current
> stuff already.

Yeah, special cases suck. :(

-- brion

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Domas Mituzas
> As long as Squid isn't overwriting those headers, as we do for
> Cache-Control. :)

Squid is overriding at the edge all text content CC headers into:

Cache-Control: private, s-maxage=0, max-age=0, must-revalidate

MediaWiki Cache-Control is used internally though. This allows us full  
control on lifetime of object with application only, no need to tweak  
any squid stuff.

> Yeah, special cases suck. :(

Especially when they're just eye-candy for english-language site.

Domas

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Casey Brown-5
In reply to this post by Brion Vibber-3
On Thu, Sep 10, 2009 at 11:48 AM, Brion Vibber <[hidden email]> wrote:
> Mark, how hard would it be in theory to swap some settings around to
> make one of our low-traffic sites take different caching
> characteristics, like leaving just strategy.wikimedia.org with either a
> Vary: Accept-Language or just having it not cache as much?
>

Well, I *think* we requested this on foundationwiki a few years ago...
but we got turned down because of the squid-setup issue.  (I can't
find a bug though.)  If you get it on strategywiki, can we get it
there too? :-)

--
Casey Brown
Cbrown1023

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Brion Vibber-3
On 9/10/09 2:40 PM, Casey Brown wrote:

> On Thu, Sep 10, 2009 at 11:48 AM, Brion Vibber<[hidden email]>  wrote:
>> Mark, how hard would it be in theory to swap some settings around to
>> make one of our low-traffic sites take different caching
>> characteristics, like leaving just strategy.wikimedia.org with either a
>> Vary: Accept-Language or just having it not cache as much?
>>
>
> Well, I *think* we requested this on foundationwiki a few years ago...
> but we got turned down because of the squid-setup issue.  (I can't
> find a bug though.)  If you get it on strategywiki, can we get it
> there too? :-)

We push foundationwiki pretty hard sometimes (such as at fundraiser
time)... we'd want to make sure we can actually handle it efficiently
before considering that.

-- brion

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Brian J Mingus
On Thu, Sep 10, 2009 at 3:45 PM, Brion Vibber <[hidden email]> wrote:

> On 9/10/09 2:40 PM, Casey Brown wrote:
> > On Thu, Sep 10, 2009 at 11:48 AM, Brion Vibber<[hidden email]>
>  wrote:
> >> Mark, how hard would it be in theory to swap some settings around to
> >> make one of our low-traffic sites take different caching
> >> characteristics, like leaving just strategy.wikimedia.org with either a
> >> Vary: Accept-Language or just having it not cache as much?
> >>
> >
> > Well, I *think* we requested this on foundationwiki a few years ago...
> > but we got turned down because of the squid-setup issue.  (I can't
> > find a bug though.)  If you get it on strategywiki, can we get it
> > there too? :-)
>
> We push foundationwiki pretty hard sometimes (such as at fundraiser
> time)... we'd want to make sure we can actually handle it efficiently
> before considering that.
>
> -- brion
>
>
apachebench?
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Domas Mituzas
>>
> apachebench?

How does apachebench help with efficiency? Please consider thinking  
before posting on this mailing list!

Domas

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Erik Moeller-4
In reply to this post by Gergő Tisza
2009/9/9 Tisza Gergő <[hidden email]>:
> The LanguageSelector extension [1] can automatically set the interface
> language based on browser settings, which is nowadays the norm for
> every serious multilanguage web page. It is not used on WMF wikis,
> because it would interfere with caching.

I'm not convinced using the browser language settings for anything
other than suggestions is a good practice, as it doesn't necessarily
relate at all to language speaking ability of the user behind the
browser (think Internet cafes, shared computers, etc.). I notice that
it's possible to disable this behavior in the extension and just use
it as a UI language picker, which I agree would be useful if we can
make it work efficiently.

IMO an approach that replicates the behavior of separate MediaWiki
instances on a per-page basis, i.e. where the UI language reflects the
content language _of the page_, may be worth considering as well.
Then, if you navigate through an entry point in your language, and
peruse pages in your language, your UI will be in your language as
well, consistently.
--
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Roan Kattouw-2
In reply to this post by Domas Mituzas
2009/9/10 Domas Mituzas <[hidden email]>:
> Squid is overriding at the edge all text content CC headers into:
>
> Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
>
> MediaWiki Cache-Control is used internally though. This allows us full
> control on lifetime of object with application only, no need to tweak
> any squid stuff.
>
Speaking of which, could we exempt api.php from this? It sets sane
Cache-Control: headers on its own, which should not be overwritten.
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=14402#c11 and
downwards.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

api.php cache-control (was: LanguageSelector bla bla bla)

Domas Mituzas
Hi!
> Speaking of which, could we exempt api.php from this?

We could, we may, I just did it, though...

can anyone explain the C-C header logic to me? For now I see it is  
mostly:

Cache-Control: s-maxage=0, must-revalidate, max-age=0
Expires: Thu, 01 Jan 1970 00:00:01 GMT

Also, opensearch has this:
Cache-Control: s-maxage=1200, must-revalidate, max-age=1200

what is the 'must-revalidate' doing here? why is there no 'public', etc?

"It sets sane Cache-Control: headers on its own," - does it? :)

Domas

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: api.php cache-control (was: LanguageSelector bla bla bla)

Roan Kattouw-2
2009/9/11 Domas Mituzas <[hidden email]>:
> Hi!
>> Speaking of which, could we exempt api.php from this?
>
> We could, we may, I just did it, though...
>
Yay, thanks!

> can anyone explain the C-C header logic to me? For now I see it is
> mostly:
>
> Cache-Control: s-maxage=0, must-revalidate, max-age=0
> Expires: Thu, 01 Jan 1970 00:00:01 GMT
>
> Also, opensearch has this:
> Cache-Control: s-maxage=1200, must-revalidate, max-age=1200
>
> what is the 'must-revalidate' doing here? why is there no 'public', etc?
>
> "It sets sane Cache-Control: headers on its own," - does it? :)
>
I guess we need public instead of must-revalidate in some places.
Someone asked if we shouldn't add must-revalidate conditionally [1],
but when I asked on what condition (hey, I don't know all that much
about C-C headers, I'm just the code monkey here :P ) I got no
response. If someone tells me what the correct behavior is, I'll
happily implement it.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Nikola Smolenski
In reply to this post by Erik Moeller-4
Дана Friday 11 September 2009 00:29:54 Erik Moeller написа:

> 2009/9/9 Tisza Gergő <[hidden email]>:
> > The LanguageSelector extension [1] can automatically set the interface
> > language based on browser settings, which is nowadays the norm for
> > every serious multilanguage web page. It is not used on WMF wikis,
> > because it would interfere with caching.
>
> I'm not convinced using the browser language settings for anything
> other than suggestions is a good practice, as it doesn't necessarily
> relate at all to language speaking ability of the user behind the
> browser (think Internet cafes, shared computers, etc.). I notice that
> it's possible to disable this behavior in the extension and just use
> it as a UI language picker, which I agree would be useful if we can
> make it work efficiently.

I believe I can say as a professional that you are correct, albeit it is my
opinion that the browser settings can be usefully used as long as you leave
the user quick, simple and obvious ability to change the language on his own.

One thing that would be *extremely* useful regardless is the ability to keep a
language throughout the browsing session. This would mean that on, say,
Italian Wikipedia, you could have a link to Wikimedia Commons like
http://commons.wikimedia.org/wiki/Pagina_principale?uselang=it - and when
someone clicks on the featured picture *the interface would stay in Italian*
and then when someone clicks on Entra / Registrati *the interface still stays
in Italian*, and when someone actually registers the interface becomes
Italian in his preferences and so on. This would do a lot for acceptance of
Commons among the Wikipedias, and from there I see other useful ways it could
be used. If this is done, recognition of the browser language could be more
easily be experimented with.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Chad
On Fri, Sep 11, 2009 at 3:02 PM, Nikola Smolenski <[hidden email]> wrote:

> Дана Friday 11 September 2009 00:29:54 Erik Moeller написа:
>> 2009/9/9 Tisza Gergő <[hidden email]>:
>> > The LanguageSelector extension [1] can automatically set the interface
>> > language based on browser settings, which is nowadays the norm for
>> > every serious multilanguage web page. It is not used on WMF wikis,
>> > because it would interfere with caching.
>>
>> I'm not convinced using the browser language settings for anything
>> other than suggestions is a good practice, as it doesn't necessarily
>> relate at all to language speaking ability of the user behind the
>> browser (think Internet cafes, shared computers, etc.). I notice that
>> it's possible to disable this behavior in the extension and just use
>> it as a UI language picker, which I agree would be useful if we can
>> make it work efficiently.
>
> I believe I can say as a professional that you are correct, albeit it is my
> opinion that the browser settings can be usefully used as long as you leave
> the user quick, simple and obvious ability to change the language on his own.
>
> One thing that would be *extremely* useful regardless is the ability to keep a
> language throughout the browsing session. This would mean that on, say,
> Italian Wikipedia, you could have a link to Wikimedia Commons like
> http://commons.wikimedia.org/wiki/Pagina_principale?uselang=it - and when
> someone clicks on the featured picture *the interface would stay in Italian*
> and then when someone clicks on Entra / Registrati *the interface still stays
> in Italian*, and when someone actually registers the interface becomes
> Italian in his preferences and so on. This would do a lot for acceptance of
> Commons among the Wikipedias, and from there I see other useful ways it could
> be used. If this is done, recognition of the browser language could be more
> easily be experimented with.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I looked at this exact issue before (there's a bug for it too). It should
be _very_ trivial to set uselang values into the session or a cookie.
Right now uselang= only works on the page you're on, which isn't
ideal.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Brian J Mingus
In reply to this post by Domas Mituzas
On Thu, Sep 10, 2009 at 4:22 PM, Domas Mituzas <[hidden email]>wrote:

> >>
> > apachebench?
>
> How does apachebench help with efficiency? Please consider thinking
> before posting on this mailing list!
>
> Domas
>
>
apachebench does help with efficiency. It is inefficient (not to mention
irresponsible) to wait to benchmark your code until you have a throng of
users actually relying on it. Apachebench will allow you to set the header
needed to trigger the language content shift in mediawiki while
simultaneously hammering the server with such requests.  Please think before
being hypercritical of reasonable suggestions.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Domas Mituzas
Hello!

> apachebench does help with efficiency. It is inefficient (not to  
> mention
> irresponsible) to wait to benchmark your code until you have a  
> throng of
> users actually relying on it.

It isn't matter of benchmarking, it is matter of relative resource  
costs, compared with other projects, and no way you'd get the answer  
with benchmarking tool.
Do note, we have a cluster which serves thousands of other requests,  
so we may have capacity to serve various exceptions, but we may as  
well want to spend that capacity on more efficient things, like, um,  
wikis without eyecandies (interface language changes for english  
language wikis? way to go!)

> Apachebench will allow you to set the header
> needed to trigger the language content shift in mediawiki while
> simultaneously hammering the server with such requests.

We already know the costs, we do profile. We have way more detailed  
costs than anything 'ab' can provide.
We have way more capacity in our cluster than a single-threaded  
benchmark tool can load properly.

Domas

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Aryeh Gregor
In reply to this post by Brian J Mingus
On Fri, Sep 11, 2009 at 3:21 PM, Brian <[hidden email]> wrote:
> apachebench does help with efficiency. It is inefficient (not to mention
> irresponsible) to wait to benchmark your code until you have a throng of
> users actually relying on it. Apachebench will allow you to set the header
> needed to trigger the language content shift in mediawiki while
> simultaneously hammering the server with such requests.  Please think before
> being hypercritical of reasonable suggestions.

Number one: suggesting "use apachebench" is not really helpful,
because anyone who's even the slightest bit competent knows about it.
Although I'm sure you were only trying to be helpful, giving very
basic suggestions can be taken to imply that you have a very low
opinion of your audience's technical knowledge, and tends to offend
people.

Number two: no, it's not inefficient to profile instead of benchmark.
Benchmarking is artificial and will not trigger real usage patterns.
It's inefficient to waste effort tracking down and fixing performance
problems that might not arise in the real world, and at the same time
a real-life usage pattern could very easily trigger something your
benchmarking tool missed.  Real-time profiling mostly allows serious
performance problems to be identified and fixed within minutes, so
it's not irresponsible at all to use it.

Number three: individuals' histories of contributions, both to
discussion and to actual code, are normally taken into account by
people responding to them.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Brian J Mingus
In reply to this post by Domas Mituzas
On Fri, Sep 11, 2009 at 1:32 PM, Domas Mituzas <[hidden email]>wrote:

> Hello!
>
> > apachebench does help with efficiency. It is inefficient (not to
> > mention
> > irresponsible) to wait to benchmark your code until you have a
> > throng of
> > users actually relying on it.
>
> It isn't matter of benchmarking, it is matter of relative resource
> costs, compared with other projects, and no way you'd get the answer
> with benchmarking tool.
> Do note, we have a cluster which serves thousands of other requests,
> so we may have capacity to serve various exceptions, but we may as
> well want to spend that capacity on more efficient things, like, um,
> wikis without eyecandies (interface language changes for english
> language wikis? way to go!)
>
> > Apachebench will allow you to set the header
> > needed to trigger the language content shift in mediawiki while
> > simultaneously hammering the server with such requests.
>
> We already know the costs, we do profile. We have way more detailed
> costs than anything 'ab' can provide.
> We have way more capacity in our cluster than a single-threaded
> benchmark tool can load properly.
>
> Domas
>
>
If you know the costs so well, why is there a need to see if the foundation
wiki buckles under the load during fundraiser time?

I believe you have grossly misrepresented the capabilities of apachebench,
and per your message it appears that you've never used it.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LanguageSelector on strategy wiki

Brian J Mingus
In reply to this post by Aryeh Gregor
On Fri, Sep 11, 2009 at 1:36 PM, Aryeh Gregor
<[hidden email]<Simetrical%[hidden email]>
> wrote:

> On Fri, Sep 11, 2009 at 3:21 PM, Brian <[hidden email]> wrote:
> > apachebench does help with efficiency. It is inefficient (not to mention
> > irresponsible) to wait to benchmark your code until you have a throng of
> > users actually relying on it. Apachebench will allow you to set the
> header
> > needed to trigger the language content shift in mediawiki while
> > simultaneously hammering the server with such requests.  Please think
> before
> > being hypercritical of reasonable suggestions.
>
> Number one: suggesting "use apachebench" is not really helpful,
> because anyone who's even the slightest bit competent knows about it.
> Although I'm sure you were only trying to be helpful, giving very
> basic suggestions can be taken to imply that you have a very low
> opinion of your audience's technical knowledge, and tends to offend
> people.
>

Quite the contrary, if I were to engage in a long diatribe about the
benefits of apachebench it could be taken to mean I have a very low opinion
of my audience's technical knowledge. There are lots of technologies out
there, sometimes folks just need a pointer.


> Number two: no, it's not inefficient to profile instead of benchmark.
> Benchmarking is artificial and will not trigger real usage patterns.
> It's inefficient to waste effort tracking down and fixing performance
> problems that might not arise in the real world, and at the same time
> a real-life usage pattern could very easily trigger something your
> benchmarking tool missed.  Real-time profiling mostly allows serious
> performance problems to be identified and fixed within minutes, so
> it's not irresponsible at all to use it.
>

Benchmarking is not artificial by necessity - only by a lack of proper
technique. If you can't get accurate profiling data by using benchmarks then
you don't know how to benchmark.


> Number three: individuals' histories of contributions, both to
> discussion and to actual code, are normally taken into account by
> people responding to them.
>

elitism++. I suppose I should send you my resume before I send my next
message to the list.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12