[Ror-es] Multi - idiomas

[Daniel Rodriguez Troitiño]

On 9/5/07, Iñigo Sola Núñez <isola009 at gmail.com> wrote:
>
>
> > 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.

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

Creo que Hari quería decir que "culture"+"producto_id" era la clave
principal. Sólo decir "culture" habrá sido un desliz.

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

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").

> > Un saludo a todos y gracias
>
> Igualemente.