title: Preventing HTML character entities in locale files from getting munged by Rails3 xss protection
body: <p>We're building an app, our first using Rails 3, and we're having to build I18n in from the outset. Being perfectionists, we want real typography to be used in our views: dashes, curled quotes, ellipses et al.</p>
  
  <p>This means in our locales/xx.yml files we have two choices: </p>
  
  <ol>
  <li>Use real UTF-8 characters inline.
  Should work, but hard to type, and
  scares me due to the amount of
  software which still does naughty
  things to unicode.</li>
  <li>Use HTML
  character entities (&amp;#8217;
  &amp;#8212; etc). Easier to type,
  and probably more compatible with
  misbehaving software.</li>
  </ol>
  
  <p>I'd rather take the second option, however the auto-escaping in Rails 3 makes this problematic, as the ampersands in the YAML get auto-converted into character entities themselves, resulting in 'visible' &amp;8217;s in the browser.</p>
  
  <p>Obviously this can be worked around by using <code>raw</code> on strings, i.e.:</p>
  
  <pre><code>raw t('views.signup.organisation_details')
  </code></pre>
  
  <p>But we're not happy going down the route of globally <code>raw</code>-ing every time we <code>t</code> something as it leaves us open to making an error and producing an XSS hole.</p>
  
  <p>We could selectively <code>raw</code> strings which we know contain character entities, but this would be hard to scale, and just feels wrong - besides, a string which contains an entity in one language may not in another.</p>
  
  <p>Any suggestions on a clever rails-y way to fix this? Or are we doomed to crap typography, xss holes, hours of wasted effort or all thre?</p>