I believe the main problem stems from that roundup saves utf-8 encoded strings
to its database and jinja2 uses unicode strings internally. When a value from the database
is called from the jinja2 engine while processing  a template, it gets utf-8 and treats it as str.

References:
http://www.roundup-tracker.org/docs/upgrading.html#migrating-from-0-6-to-0-7
"Added internationalization support. This is done via encoding all data stored in roundup database to utf-
8 (unicode encoding)."

http://jinja.pocoo.org/docs/dev/api/#unicode
"Jinja2 is using Unicode internally which means that you have to pass Unicode objects to the render 
function or bytestrings that only consist of ASCII characters. "

"For Jinja2 the default encoding of templates is assumed to be utf-8."

Charset for the client:
At a later stage it seems that a way was added to encode the result of roundup to
the charset that the client requested. But this seems to be handled inconsistently in some templates.
It probably should be solved consistently. So I suggest to come up with a test case where the
current thing fails and create an extra issue for it.

Potential solution to the unicode errors:
We could make sure that all variables from roundup are unicode objects when called
from the jinja2 engine. Either at the roundup end or transform it at the jinja2 end.

We could add a custom jinja2 filter that does the utf-8 to unicode conversion and then 
add it to each call to tje jinja template where a string is to be returned. If we call the custom filter
'u' it would look like "{{ msg.content.hyperlinked()|u }} 
jjinja2 itself cannot know if the function will return a str or something different.