I18n.t and UTF-8 black diamond?

Rails
1

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:

  • is set on HTML5 doctypes

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ó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

2

On Sep 8, 7:05 am, Michael K. [email protected] wrote:

  • my text editor is set to encode files as UTF-8
    tedious to code.

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

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

Fred

3

Michael K. 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:

  • is set on HTML5 doctypes

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,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

4

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

-Michael