Estoy por empezar en un nuevo proyecto donde muy probablemente usemos Rails. Uno de los requisitos del proyecto es que tenga internacionalización desde un principio.

Jeff Casimir - i18n - RubyConf Argentina 2012

Jeff Casimir – i18n – RubyConf Argentina 2012

El primer lugar al que hay que ir a leer es Rails Guides: Rails Internationalization (I18n) API. Pero también me acordé una charla de RubyConf Argentina que me gustó bastante en su momento. La charla en cuestión:

Jeff Casimir – Internationalization isn’t a bad word

En general me acuerdo por ahí las ventajas de extraer los Strings de nuestro código -por más que no vayamos a usar i18n- y que es una buena práctica de arranque.

Preparar el código para i18n es un trabajo de una vez, y quita todo lo que sea particular al lenguaje fuera de nuestra aplicación. La localización implica crear “locales”, traducir los textos y los formatos y formas de mostrar la información.

Uno de los aspectos importantes que menciona Jeff Casimir en su charla es evitar los “Copyedit commits”, o “commits con edición de texto”. Commits donde cambiamos apenas algun texto, que pueden hacer explotar todo por de repente un copio y pegue con comillas o caracteres raros de Word.

Algunas de las herramientas que menciona (de lo que tengo en mis apuntes):

Les recomiendo ver la charla, habla de varias buenas prácticas, cómo definir el locale (no usar geolocalización a menos que sea el último recurso) y más:

Pueden ver el resto de las charlas de RubyConf Argentina 2012 en estos enlaces: Día 1 | Día 2

Así que si tienen que agregar i18n a su aplicación, acá hay algunos lugares por dónde empezar. Veremos cómo me va y qué terminamos usando en nuestro proyecto actual.

No hay comentarios en este post

Feed de comentarios

Dejar un comentario

Notificarme los nuevos comentarios por correo electrónico. Tambien puedes suscribirte sin comentar.

Toasty!