BUG/FEATURE:  Version 0.2 against 080703-2 (maybe other cases too) has a side-effect: when previewing a message for publication, the request language temporarily becomes the language chosen for the message.

EXPLANATION: If i understand things correctly, the following is the explanation: Clicking on the preview button when publishing causes the preview method in message_controller to be called. The information sent to the server in the http header includes a parameter  lang=something.  Since the preview method is part of a new request, it uses this info whether or not it's in the URL or in the list of parameters from a submit form. After clicking confirm, the new request no longer has the hidden lang=something field sent to the samizdat server in the http server, so the request language reverts to what it was before.

DISCUSSION: Is this a bug or a feature? FEATURE: If someone is publishing something in some language, then s/he should normally know something about that language, even if s/he had not previously indicated this in his/her language preferences. Someone publishing something in a language that s/he does not really know should at least trust someone else in that language, and be able to consult that person in the case of any concerns. So is there a problem with temporarily switching to the chosen language? Probably not. It should also not be a problem switching back to the previous language afterwards, because multi-lingual people will not necessarily want to switch their preferred language to the language of that individual message. BUG: If someone feels that this is a bug, then one of the two 'lang' parameters could have its name changed. Probably changing the internal one in samizdat message_controller would make most sense in this case.

Personally, i see it as a feature. :)

PROBLEM:

Some software packages (e.g. the version of mir which imports
rdf feeds) do not do Accept-Language http header negotiation
when importing feeds. It would to be able to help these faulty
software packages.

SUGGESTED SOLUTION:

In request.rb, allow a URL parameter lang= to override the
environment variable and cookie settings in accept_language.

--- s070818/samizdat/lib/samizdat/engine/request.rb        2007-08-14 01:16:53.000000000 +0200
+++ /usr/lib/ruby/1.8/samizdat/engine/request.rb        2007-08-27 00:41:19.027004488 +0200
@@ -170,6 +176,11 @@
     # lang cookie overrides Accept-Language
     lang = cookie('lang') and config_lang.include? lang and
       @accept_language.unshift lang
+
+    # lang in URL overrides above Accept-Language settings
+    l = self['lang'] and config_lang.include? l and
+      @accept_language.unshift l
+
     # use first language from config by default
     @accept_language.size == 0 and @accept_language = [config_lang[0]]
     # set interface language

DISCUSSION:

Should there be any additional safety checks against the
content of the parameter? (E.g. in twiki there were some exploits
with people putting `some script` into the URL for searches)
Or is the config_lang.include? l  likely enough to remove
any chance of this sort of exploit? After all, sysadmin would
need to enter the dangerous code in the config file for this
to work, and it would need to be parsed unchanged when parsing
the config file, which seems unlikely when using odd characters.

Is this a problem of encouraging people to use URL parameters
instead of http header negotiation characters? i don't know
much about this.

i was not sure whether this should count as a bug or a patch -
this probably depends on whether we consider missing functionality
in other software to be something that we must handle or only
that we should or may handle it.