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

Toasty!