So, for the sake of completeness, here's the fragment of Apache config we use to solve this: ## Javascript Language helper ### only serve if exists RewriteCond "/opt/local/apache2/htdocs/trans/lang_$1.js" -s RewriteRule ^/xwiki/gen/js/lang_(.+)\.js "${servers:htdocs}/trans/lang_$1.js" [L] ### otherwise serve the english one RewriteRule ^/xwiki/gen/js/lang(.+)\.js "${servers:htdocs}/trans/lang_en.js" [L] The files we serve there are javascript files that are output by an xwiki-page when an upgrade is needed, for the languages that we need. Indeed, the tiny history we had of one curriki user (who got her machine repaired in a country, then fixed later in another, she was sure everything was clean) shows that things can go badly wrong there and its useful to have a fallback. paul Le 12 avr. 2012 à 13:58, Ludovic Dubost a écrit :
I think unfortunately that you can manually set this in your browser at least in Firefox. XWiki's core does not do any check on the value of the language
Ludovic
2012/4/12 Paul Libbrecht <[email protected]>
Hello developers,
We had some (rare) users that had a very bad issue because we told their browser to load the lang_xx.js of their language. And their language was... wild! See: http://jira.xwiki.org/browse/CURRIKI-5694 for a sample of the things that got submitted to us. Sure, we'll now protect against these bizarre languages, still, there might be other things broken.
Is there some guarantee on the set of possible languages provided by $context.language? I was expect the possible values of ISO-623-1 but that was clearly not sufficient!
paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs