I think somehow the language to load the page with is being cached. For example, if I set Accept-Language to 'es' and load http://i18n.mbsandbox.org/ I get Spanish. If I change it to 'de' and continue browsing, everything is still in Spanish.
The same problem happens with multiple users on multiple computers - for example, if I load a page requesting German, when reosarevok loads the page requesting Spanish, he will get the interface in German.
Description
I think somehow the language to load the page with is being cached. For example, if I set Accept-Language to 'es' and load http://i18n.mbsandbox.org/ I get Spanish. If I change it to 'de' and continue browsing, everything is still in Spanish.
The same problem happens with multiple users on multiple computers - for example, if I load a page requesting German, when reosarevok loads the page requesting Spanish, he will get the interface in German.
MusicBrainz::Server::Translation->_set_language checks $ENV{LANGUAGE} and returns if it's set. If it's not, it sets it from the Accept-Language header. This means that the first person to load the page sets the variable and from there on it never changes regardless of what Accept-Language has. Commenting out the line which returns when $ENV{LANGUAGE} is already set solved that and lead us to the next problem.
By default, it tries to use the XS version of gettext. This appears to have some problems where it caches things instead of returning what you actually asked it for. Adding Locale::Messages->select_package ('gettext_pp'); to the top of MB::S::Translation fixed that.
We're still not sure that using a single $ENV{LANGUAGE} variable will actually work properly with multiple simultaneous requests. The language should probably be linked to the session instead. However the two changes mentioned at least make it possible for http://i18n.mbsandbox.org/ to work with more than one language.
nikki added a comment - 22/Jan/12 08:48 PM Ian and I made a bit of progress:
MusicBrainz::Server::Translation->_set_language checks $ENV{LANGUAGE} and returns if it's set. If it's not, it sets it from the Accept-Language header. This means that the first person to load the page sets the variable and from there on it never changes regardless of what Accept-Language has. Commenting out the line which returns when $ENV{LANGUAGE} is already set solved that and lead us to the next problem.
By default, it tries to use the XS version of gettext. This appears to have some problems where it caches things instead of returning what you actually asked it for. Adding Locale::Messages->select_package ('gettext_pp'); to the top of MB::S::Translation fixed that.
We're still not sure that using a single $ENV{LANGUAGE} variable will actually work properly with multiple simultaneous requests. The language should probably be linked to the session instead. However the two changes mentioned at least make it possible for http://i18n.mbsandbox.org/ to work with more than one language.
Sub-task
Closed
Normal
Ian and I made a bit of progress:
MusicBrainz::Server::Translation->_set_language checks $ENV{LANGUAGE} and returns if it's set. If it's not, it sets it from the Accept-Language header. This means that the first person to load the page sets the variable and from there on it never changes regardless of what Accept-Language has. Commenting out the line which returns when $ENV{LANGUAGE} is already set solved that and lead us to the next problem.
By default, it tries to use the XS version of gettext. This appears to have some problems where it caches things instead of returning what you actually asked it for. Adding Locale::Messages->select_package ('gettext_pp'); to the top of MB::S::Translation fixed that.
We're still not sure that using a single $ENV{LANGUAGE} variable will actually work properly with multiple simultaneous requests. The language should probably be linked to the session instead. However the two changes mentioned at least make it possible for http://i18n.mbsandbox.org/
to work with more than one language.