Estructura de MySQL para traducciones

Question

Según este enfoque, el idioma predeterminado es ya traducido en la primera tabla. Si un usuario no necesita una traducción, no tendrá problemas con ellos. Sólo tiene que conectar tabla principal, eso es todo ...

tabla de productos (InnoDB):

Obj_id(PK)    name     desc 
---------  -------------------  ------------------ 
    1   Million Dollar Baby Short description is... 
    2   Music Album   Another explanation... 

TRADUCCIÓN TABLA (InnoDB)

trans_id (PK) Obj_id (FK) lang  field    trans 
-------------- ----------- ------ -------- --------------------- 
     22    1   TR  name  Milyonluk Bebek 
     23    1   BA  name  Djevojka od milijun... 
     24    1   TR  desc  Kisa açiklama burada 
     25    1   BA  desc  Kratki opis je ovdje 
     26    2   BA  name  Glazba albuma 

Pero el problema se produce cuando el administrador quiere cambiar el idioma predeterminado . Tengo dos opciones para resolver este problema:

1. administrador tiene que decidir default_lang al comienzo del proyecto y si todavía quiere cambiar default_lang en el futuro, el programa a decir: Go to hell.

2. Al igual que la primera solución, el administrador tiene que decidir default_lang al principio, pero el sistema podrá transferir nuevos datos default_lang de la tabla de traducción a la tabla primaria (no hago esto en realidad).

Creo que mis soluciones no son lo suficientemente buenas.

¿Tiene una mejor idea acerca del problema DEFAULT_LANG con o sin cambiar la estructura (si es posible, no cambie la estructura, me gusta)?

Answer 1

¿Has mirado en gettext?

http://www.gnu.org/software/gettext/

Answer 2

Me pregunto si tener una mesa por cada idioma sería mejor. De esa manera, simplemente cambiaría las tablas que están siendo utilizadas.

TRANSLATIONS_TR 
TRANSLATIONS_EN 
TRANSLATIONS_FR 
TRANSLATIONS_BR 

Luego, en las rutinas de visualización del usuario, usted decide qué tabla consultar cuando se muestra texto de traducción.

Answer 3

gettext resuelve un tipo diferente de problema que una base de datos multilingüe: gettext es para la interfaz de usuario, mientras que la base de datos es para el contenido.

Utilizará gettext o equivalente para dispositivos como mensajes de error, una etiqueta de botón o un título de página, donde hay una pequeña lista de elementos que cambian con poca frecuencia.

Una base de datos multilingüe es para grandes volúmenes de contenido que pueden o no cambiar con frecuencia, como, por ejemplo, los títulos de cientos de miles de libros y películas o descripciones de licitaciones.

Answer 4

Mi enfoque que yo creo que sería (estoy en el proceso de construcción de este yo):

Tal vez (1) El producto tiene (n) Nombres (en función del lenguaje, suponiendo que sólo tiene una columna que describe el idioma, al igual que 'es', 'es')

[ Product ]—(1)—————(N)-[ProductName] 
| id |    | name  | 
         | language | 

Tal vez sea mejor producto-lenguaje en un N: relación M:

[ Product ]-(N)—————————(M)-[Language] 
| id |  |  |iso_code| 
      (translation) | name | 


[ Product ]<————[ProdTranslation]———>[language] 
| id  |  | name   | |iso_code| 
|default name?|       | name |--- (name of language: "English") 

Otra opción podría ser considerar cada traducida del produ ct ser un "tipo de producto" (una subclase). modelo lógico siguiente:

[ Product ] 
| id  |-(1)————(1)-[ EnglishProduct ] 
|default name?|   | name (in eng.) | 
|    | 
|    |-(1)——(1)-[FrenchProduct] 
|    |   | name(in fr.)| 

Al aplicar la presente en una base de datos relacional, entonces se podría o bien a) tienen 3 mesas (en este ejemplo, más con más idiomas) o b) poner todo en una sola tabla. Depende de la cantidad de idiomas que tendría, tamaño del nombre/descripción, funcionamiento, etc.

[ Product ] 
| id  | 
| name_en | 
| name_fr | 
| name_de | 

El código de consulta de la base de datos que conocer el idioma a utilizar, y luego consultar el nombre de la columna de la derecha .