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