Hola lista,
soy nueva en esto pero necesito que alguien me diga si implementar una
web
en varios idiomas es complicado; si existe algún plugin en el q venga ya
implementado y alguna página de
información.
Muchas gracias.
Saludos,
Melisa Fernández
Un amor, una aventura, compañía para un viaje. Regístrate gratis en MSN Amor
& Amistad. Site de rencontre sérieux pour trouver l’amour Meetic
soy nueva en esto pero necesito que alguien me diga si implementar una web
en varios idiomas es complicado; si existe algún plugin en el q venga ya
implementado y alguna página de información.
Tienes varias opciones [1] aunque te recomendarÃa que usaras GetText
[2].
Existe un manual oficial para rails [3] y algún otro, en castellano [4]
y en
inglés [5]. También hay un fabuloso screencast [6] del amigo Vicent.
Deberás pensar como manejar la variable ‘locale’. A nivel de URL, cookie
o
session. A nivel de URL podrÃamos distinguir dos opciones: que
pertenezca a
la propia URI (http://www.psss.com/en/products) o pasarla como variable
con
el método get (http://www.psss.com/products?lang=en).
Con todos esos enlaces no tendrás problemas, pero si los tuvieras, no
dudes
en comentárnoslos.
Un saludo
[1]
[2] gettext - GNU Project - Free Software Foundation
[3] Peak Obsession
[4] http://www.kronoss.org/Internacionalización_en_Ruby_on_Rails
[5]
http://www.suite75.net/blog/dev/tutorial-gettext-for-rails-in-8-steps.html
[6]
http://www.vicentgozalbes.com/articles/2007/08/04/openticket-primeros-screencasts
Muchas gracias Iñigo, tu explicación muy clara ahora voy a investigar sobre
el tema.
Gracias de nuevo y saludos,
Melisa Fernández
en varios idiomas es complicado; si existe algún plugin en el q venga ya
el método get (http://www.psss.com/products?lang=en).
[4] http://www.kronoss.org/Internacionalización_en_Ruby_on_Rails
[5]
http://www.suite75.net/blog/dev/tutorial-gettext-for-rails-in-8-steps.html
[6]
http://www.vicentgozalbes.com/articles/2007/08/04/openticket-primeros-screencasts
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
Dale rienda suelta a tu tiempo libre. Mil ideas para exprimir tu ocio
con
MSN Entretenimiento. http://entretenimiento.msn.es/
Hola de nuevo,
he estado leyendo la información acerca de Gettext, pero me surgen una
serie
de dudas:
Tengo un pequeño jaleo mental.
Gracias de antemano.
Saludos,
Melisa Fernández
Gracias de nuevo y saludos,
Date: Wed, 5 Sep 2007 13:02:02 +0200
inglés [5]. También hay un fabuloso screencast [6] del amigo Vicent.
dudes
http://www.suite75.net/blog/dev/tutorial-gettext-for-rails-in-8-steps.html
Dale rienda suelta a tu tiempo libre. Mil ideas para exprimir tu ocio con
MSN Entretenimiento. http://entretenimiento.msn.es/
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
Acepta el reto MSN Premium: Protección para tus hijos en internet.
Descárgalo y pruébalo 2 meses gratis.
http://join.msn.com?XAPID=1697&DI=1055&HL=Footer_mailsenviados_proteccioninfantil
On 9/5/07, melisa Fernández [email protected] wrote:
Hola de nuevo,
he estado leyendo la información acerca de Gettext, pero me surgen una serie
de dudas:
- desde lo poco que he podido leer creo q este tipo de solución esta bien
para traducir un número pequeño de textos, pero lo q yo necesito es traducir
un site completo.
Esta diseñado para traducir lo que quieras y no solo un texto. Es un
wrapper de GNU/Gettext para Ruby, pero sigue estando compilado y su
performanse es buena, incluso para sitios enteros. Yo lo he usado y lo
sigo usando en sitios completos y es lo mejor que he encontrado.
Igual no hay nada muy feliz con respecto a la i18n, creo que es el
mayor dolor de cabeza al momento de realizar un sitio (maldita Torre
de Babel).
Saludos!
Hola, Melisa:
Primero, avisar que hablo desde el desconocimiento más absoluto de
Globalize. Personalmente, utilizo GetText y me parece la mejor
solución. Me parece relativamente cómodo y se guarda en ficheros
compilados.
Cuando dices que tienes que traducir sites completos, a qué te refieres?
Un saludo,
Serabe
Melisa, a mi forma de ver, deberÃas crear campos para cada idioma en la
tabla noticias, pero mejor veamos un ejemplo:
Supongamos que tienes una tabla llamada Noticias. En ella puedes tener,
por
ejemplo, los siguiente campos: id, title, description, created_at.
De esa manera tanto en el campo destinado al titulo (title) como el
campo
destinado para la descripción (description) solo puedes almacenar
contenido
para un idioma. Sin embargo, podemos solucionar el problema si la tabla,
en
vez de tener esos campos, tuviera estos otros: id, title_en,
description_en,
title_es, description_es, created_at.
Asà conseguimos poder guardar tanto el tÃtulo como la descripción de la
noticia en dos idiomas (ingles y castellano en este caso). De forma
análoga
para más idiomas.
Tendremos que modificar el formulario de creación y actualización de las
noticias, insertando los correspondientes campos para el nuevo idioma. Y
a
la hora de visualizar el contenido puedes hacer uso de la variable
‘locale’
para determinar qué campos debes mostrar en función del lenguaje elegido
por
el usuario.
Espero que esta solución te sea de utilidad.
Saludos.
Hola de nuevo,
cuando me refiero a traducir sitios completos hago referencia al
contenido
completo de una página; es decir, si un usario esta en la sección noticas y
la página esta en 2 idiomas dependiendo del idioma en q este visualizando
el
site podrá ver el contenido de una forma u otra (idioma).
Como los contenidos no son estáticos, los textos los debe incluir el
cliente
en el backend. Ségún he visto en Gettext este te traduce contenidos pero
son
estáticos, como el de un formulario por ejemplo q siempre tendrá los mismos
campos.
Pero para contenido dinámico Gettex creo q no es útil (hablo un poco sin
conocer, por eso estoy preguntando), debería de obtener los contenidos de
una base de datos?? o existe alguna otra
opción?
Y globalize en q consiste?
Muchas gracias y saludos,
Melisa Fernández
Primero, avisar que hablo desde el desconocimiento más absoluto de
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
Moda para esta temporada. Ponte al día de todas las tendencias.
http://www.msn.es/Mujer/moda/default.asp
Esta solución que propones, Iñigo, me parece una cagada, con
perdón.
Es el planteamiento que hace Globalize, y me parece HORROROSO.
De paso, ya que estamos, aprovecho yo también para preguntar a ver si hay
algo parecido a lo que existe en Symfony (seguramente exista)
En Symfony, si se tiene el modelo:
Producto { id, nombre, descripcion, created_at }
Y lo quieres internacionalizar, creas una tabla i18n,
así:
Producto { id, created_at }
Producto_i18n { culture, producto_id, nombre, descripcion }
Dónde en el modelo Producto_i18n es PK clave principal “culture” (es, etc
etc…) y “producto_id” FK clave externa
Es evidente que así tenemos un gestor de productos dinámico en cuánto a
lenguajes posibles de
traducción.
Y lo mejor de todo, es que esto se integra en el ActiveRecord de
Symfony; si
por ejemplo queremos el nombre del producto en español, haríamos:
$producto = ProductoPeer::getByPK(1);
$producto->setCulture(‘es’);
echo $producto->getNombre();
En inglés:
$producto->setCulture(‘en’);
echo $producto->getNombre();
Y así sucesivamente…
¿Existe algo así para RoR? Yo creo que tiene que existir… El caso es
¿dónde? 
Un saludo a todos y gracias
De: [email protected]
[mailto:[email protected]] En nombre de Iñigo Sola
NúñezEnviado el: miércoles, 05 de septiembre de 2007 16:10
Para: La lista sobre Ruby On Rails (rubyonrails.com) en castellano
Asunto: Re: [Ror-es] Multi - idiomas
Melisa, a mi forma de ver, deberías crear campos para cada idioma en la
tabla noticias, pero mejor veamos un ejemplo:
Supongamos que tienes una tabla llamada Noticias. En ella puedes tener,
por
ejemplo, los siguiente campos: id, title, description, created_at.
De esa manera tanto en el campo destinado al titulo (title) como el
campo
destinado para la descripción (description) solo puedes almacenar contenido
para un idioma. Sin embargo, podemos solucionar el problema si la tabla,
en
vez de tener esos campos, tuviera estos otros: id, title_en,
description_en,
title_es, description_es, created_at.
Así conseguimos poder guardar tanto el título como la descripción de la
noticia en dos idiomas (ingles y castellano en este caso). De forma
análoga
para más idiomas.
Tendremos que modificar el formulario de creación y actualización de las
noticias, insertando los correspondientes campos para el nuevo idioma. Y
a
la hora de visualizar el contenido puedes hacer uso de la variable
‘locale’
para determinar qué campos debes mostrar en función del lenguaje elegido por
el usuario.
Espero que esta solución te sea de utilidad.
Saludos.
Esta solución que propones, Iñigo, me parece una cagada, con perdón.
Para gustos los colores, pero veamos tu propuesta…
Es el planteamiento que hace Globalize, y me parece HORROROSO.
De paso, ya que estamos, aprovecho yo también para preguntar a ver si hay
algo parecido a lo que existe en Symfony (seguramente exista)
No me consta
En Symfony, si se tiene el modelo:
Producto { id, nombre, descripcion, created_at }
Y lo quieres internacionalizar, creas una tabla i18n, asÃ:
Producto { id, created_at }
Producto_i18n { culture, producto_id, nombre, descripcion }
Si nos ponemos un poco quisquillosos, salta a la vista que tu solución
es
menos eficiente. Almacenas un campo extra para la relación, por no
hablar
de los join que habrÃa que hacer en tiempo de ejecución.
Dónde en el modelo Producto_i18n es PK clave principal “culture” (es,
etc
etc…) y “producto_id” FK clave externa
No se si entiendo tu planteamiento. ¿‘Culture’ es la clave principal? De
ser
asà no podrás tener mas de un producto de cada idioma.
De cualquier forma no entiendo esta desnomarlización que propones, sobre
todo no veo las ventajas que aporta,… no las veo.
Es evidente que asà tenemos un gestor de productos dinámico en cuánto a
En inglés:
$producto->setCulture(‘en’);
echo $producto->getNombre();
Puedes conseguir lo mismo diseñandote un sencillo procedimiento a nivel
de
modelo. (y ahorrándote hacer joins)
Y asà sucesivamente…
¿Existe algo asà para RoR? Yo creo que tiene que existir… El caso es
¿dónde?
No me costa que exista.
Un saludo a todos y gracias
Igualemente.
On 9/5/07, Daniel R. Troitiño [email protected] wrote:
De cualquier forma ninguna solución de i18n y l10n para Rails es 100%
perfecta y todas tienen sus “peros” y ninguna es adecuada para todos
los problemas (me remito a lo que he escrito antes de las muchas
“culture” frente a las pocas “culture”).
Sólo agregar que “es por esto” que no hay ninguna
solución"out-of-the-box" en el core de Rails…
On 9/5/07, Iñigo Sola Núñez [email protected] wrote:
No me consta
menos eficiente. Almacenas un campo extra para la relación, por no hablar
de los join que habría que hacer en tiempo de ejecución.
La solución a primera vista es menos eficiente, pero desde luego es
más escalable cuando las “culture” son muchas. Muchas bases de datos
(MySQL con InnoDB, por ejemplo) tienen límites en el tamaño de las
filas, con unas cuantas “culture” y unos cuantos “description” (como
campos varchar) alcanzarías ese límite rápidamente.
Así que depende del problema yo escogería una solución u otra. Pocas
“culture”, la solución de todos los campos en una tabla. Muchas
“culture” la solución de tener una tabla separada con las
traducciones.
De hecho, creo que Globalize pre-1.2 sólo soportaba la segunda
solución (algo parecido, en realidad) y el nuevo Globalize ofrece como
opción la primera (lo que llaman “internal storage”).
Dónde en el modelo Producto_i18n es PK clave principal “culture” (es, etc
etc…) y “producto_id” FK clave externaNo se si entiendo tu planteamiento. ¿‘Culture’ es la clave principal? De ser
así no podrás tener mas de un producto de cada idioma.
De cualquier forma no entiendo esta desnomarlización que propones, sobre
todo no veo las ventajas que aporta,… no las veo.
Creo que Hari quería decir que “culture”+“producto_id” era la clave
principal. Sólo decir “culture” habrá sido un desliz.
En inglés:
$producto->setCulture(‘en’);
echo $producto->getNombre();Puedes conseguir lo mismo diseñandote un sencillo procedimiento a nivel de
modelo. (y ahorrándote hacer joins)
Justo lo que hace Globalize con “internal storage”. Si tienes marcado
un campo como “translatable” cuando lo pides modifica el nombre del
campo para pedir el correcto a la base de datos, sin joins. Con el
método “clásico” de Globalize él se hacía los select y los join (y por
lo tanto no se podía utilizar ni :select ni :include en los find).
Y así sucesivamente…
¿Existe algo así para RoR? Yo creo que tiene que existir… El caso es
¿dónde?No me costa que exista.
Como he dicho, creo que Globalize hace algo parecido.
De cualquier forma ninguna solución de i18n y l10n para Rails es 100%
perfecta y todas tienen sus “peros” y ninguna es adecuada para todos
los problemas (me remito a lo que he escrito antes de las muchas
“culture” frente a las pocas “culture”).
Bueno, para muestras, unos cuántos botones.
schema.yml de symfony:
archivo:
_attributes: { phpName: Archivo, isI18N: true, i18nTable:
archivo_i18n }
id: { type: integer, required: true, autoIncrement: true,
primaryKey:
true }
path: { type: varchar, size: 255 }
mime_type: { type: varchar, size: 20 }
created_at: { type: timestamp }
updated_at: { type: timestamp }
archivo_i18n:
_attributes:{ phpName: ArchivoI18n }
id: { type: integer, required: true, primaryKey: true, foreignTable:
archivo, foreignReference: id, onDelete: cascade }
culture: { isCulture: true, type: varchar, size: 7, required: true,
primaryKey: true }
nombre: { type: varchar, size: 150 }
descripcion: { type: varchar, size: 255 }
Que se traduce en el siguiente SQL (para MySQL):
CREATE TABLE archivo
(
id INTEGER NOT NULL AUTO_INCREMENT,
path VARCHAR(255),
mime_type VARCHAR(20),
created_at DATETIME,
updated_at DATETIME,
PRIMARY KEY (id)
)Type=InnoDB;
CREATE TABLE archivo_i18n
(
id INTEGER NOT NULL,
culture VARCHAR(7) NOT NULL,
nombre VARCHAR(150),
descripcion VARCHAR(255),
PRIMARY KEY (id,culture),
CONSTRAINT archivo_i18n_FK_1
FOREIGN KEY (id)
REFERENCES archivo (id)
ON DELETE CASCADE
)Type=InnoDB;
Lógicamente la clave de la tabla auxiliar es el ‘id’ del archivo y
‘culture’…
(Habrá quién proponga que exista una tabla “Cultures” con todos los
lenguajes, y se hagan tablas de cruce entre lenguajes y modelos
concretos…
Pero la simplificación que se usa en symfony de usar las convenciones de
locales me parece mejor, nos ahorra querys y es perfectamente válida -por
que no tiene sentido que pongamos dos cultures iguales con valores de
nombre
diferentes…-)
Desde luego, la solución que propone Globalize:
http://www.saimonmoore.net/2007/3/17/globalize-internal-storage-mechanism
Me parecen ambas, un tanto “malas”; en la anterior a la 1.2, guardaba
las
traducciones en una tabla de traducciones:
Before the for-1.2 release, Globalize used an external table
(globalize_translations) to store translations
Y ahora lo guarda mediante el "“Internal Storage Mechanism”, dónde está
duplicando campos dentro de una misma tabla.
Si miramos la primera opción de Globalize, vemos que la tabla de
traducciones puede llegar a ser enorme, pues tal y cómo lo explican
ahí,esa tabla es para toda la aplicación… Entiendo que para todos los modelos
O;)
La segunda, implica que un cambio de número de idiomas en tu
aplicación,tengas que volver a tocar tu código; si eres tu el que mantiene el sitio
web, sí, ganas en rapidez a la hora de ejecutar consultas… Pero como no
lo
mantengas tu, y quieras dar una solución multilenguaje a tu cliente final,
pues no me parece una solución acertada…
Ciertamente, la segunda solución es la más KISS; pero… El precio, a mi
entender, es alto.
Si queremos dotar a nuestra aplicación de un soporte multilenguaje REAL,
debería de ser posible agregar/eliminar lenguajes con facilidad a la
misma,
sin que tengamos que tocar el código fuente; por ello, sigo pensando que la
solución de Symfony es, por el momento, superior.
Y si lo que queremos es hacer la traducción de pocos términos, francamente,
con un gettext se va que chuta… Sin tanta
complicación.
Repito, pensando en la escalabilidad, entiendo que la solución de utilizar
dos tablas es bastante superior; y en cuánto a rendimiento, la diferencia
…
Database changed
mysql> select * from archivo;
…
83 rows in set (0.0161 sec)
mysql> SELECT * FROM archivo INNER JOIN archivo_i18n ON archivo.id =
archivo_i18n.id
…
83 rows in set (0.0181 sec)
Vamos, no creo que la diferencia de rendimiento sea un hándicap tan
grande.
Un saludo
De: Iñigo Sola Núñez [mailto:[email protected]]
Enviado el: miércoles, 05 de septiembre de 2007 21:25
Para: [email protected]; La lista sobre Ruby On Rails
(rubyonrails.com) en castellano
Asunto: Re: [Ror-es] Multi - idiomas
Esta solución que propones, Iñigo, me parece una cagada, con perdón.
Para gustos los colores, pero veamos tu propuesta…
Es el planteamiento que hace Globalize, y me parece HORROROSO.
De paso, ya que estamos, aprovecho yo también para preguntar a ver si hay
algo parecido a lo que existe en Symfony (seguramente exista)
No me consta
En Symfony, si se tiene el modelo:
Producto { id, nombre, descripcion, created_at }
Y lo quieres internacionalizar, creas una tabla i18n,
así:
Producto { id, created_at }
Producto_i18n { culture, producto_id, nombre, descripcion }
Si nos ponemos un poco quisquillosos, salta a la vista que tu solución es
menos eficiente. Almacenas un campo extra para la relación, por no hablar
de los join que habría que hacer en tiempo de ejecución.
Dónde en el modelo Producto_i18n es PK clave principal “culture” (es, etc
etc…) y “producto_id” FK clave externa
No se si entiendo tu planteamiento. ¿‘Culture’ es la clave principal? De
ser
así no podrás tener mas de un producto de cada idioma.
De cualquier forma no entiendo esta desnomarlización que propones, sobre
todo no veo las ventajas que aporta,… no las veo.
Es evidente que así tenemos un gestor de productos dinámico en cuánto a
lenguajes posibles de traducción.
Y lo mejor de todo, es que esto se integra en el ActiveRecord de
Symfony; si
por ejemplo queremos el nombre del producto en español, haríamos:
$producto = ProductoPeer::getByPK(1);
$producto->setCulture(‘es’);
echo $producto->getNombre();
En inglés:
$producto->setCulture(‘en’);
echo $producto->getNombre();
Puedes conseguir lo mismo diseñandote un sencillo procedimiento a nivel de
modelo. (y ahorrándote hacer joins)
Y así sucesivamente…
¿Existe algo así para RoR? Yo creo que tiene que existir… El caso es
¿dónde?
No me costa que exista.
Un saludo a todos y gracias
Igualemente.
Hari S.
escribió:> Esta solución que propones, Iñigo, me parece una cagada, con perdón.
Este tipo de comentarios desestimulan la interacción y las respuestas
que puedan dar los usuarios de la lista. Yo soy tímido por naturaleza y
cuando me responden así, prácticamente me obligan a ir de la lista.
Creo que uno puede no estar de acuerdo con algo y con el debido respecto
mostrar su punto de vista.
Benjamín Cárdenas
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs