I18n.t and UTF-8 black diamond ?

I am using Rails 3.0.0.rc, Nginx 0.7.67, and Passenger 2.2.15. I am
using I18n.t on string literals defined for various locales, for
example: I18n.t(:organization), where the :es locale defines
organization: "organización".

I have verified the following:

* <meta charset="UTF-8"> is set on HTML5 doctypes
* <meta http-equiv="Content-type" content="text/html; charset=UTF-8">
is set on HTML4 doctypes
* my text editor is set to encode files as UTF-8
* I am not pulling the strings from the database, so the database is
not an issue.
* My browser is set to UTF-8 and auto-detect Universal.

And I still see the dreaded black diamond "?" for extended chars.

If I substitute HTML entities for the offending chars, e.g.
organization: "organizaci&#243;n" and call html_safe on the result,
I18n.t(:organization).html_safe, the characters display correctly in
the browser, , but it seems like that should not be required, and
tedious to code.

What obvious thing am I missing here? Any help appreciated.

Thanks,

Michael

Have you checked what bytes are being sent over the wire by the
server ?

Fred

Michael Kintzer wrote:

I am using Rails 3.0.0.rc, Nginx 0.7.67, and Passenger 2.2.15. I am
using I18n.t on string literals defined for various locales, for
example: I18n.t(:organization), where the :es locale defines
organization: "organizaci�n".

I have verified the following:

* <meta charset="UTF-8"> is set on HTML5 doctypes
* <meta http-equiv="Content-type" content="text/html; charset=UTF-8">
is set on HTML4 doctypes
* my text editor is set to encode files as UTF-8
* I am not pulling the strings from the database, so the database is
not an issue.
* My browser is set to UTF-8 and auto-detect Universal.

And I still see the dreaded black diamond "?" for extended chars.

Those facts cannot all be true. If you are seeing the diamond, then
your browser is trying to display the content as UTF-8 but being fed
something else -- most likely ISO 8859-1. Make sure the file containing
the string in question is properly encoded -- run it through iconv if
necessary.

Best,

Thanks for the replies. Marnen, you were correct, and the original
file was in the wrong encoding.

-Michael