¿Esquema multilingüe apropiado o exageración?

ACTUALIZACIÓN 2 : De hecho, terminé usando esto, y es genial después de un par de ajustes. Aquí está mi publicación sobre su diseño real, y en acción: http://tim.hithlonde.com/2013/lemon-schema-works/

Estoy creando una aplicación web y quiero que sea compatible con varios idiomas. Esta estructura tiene dos componentes:

1. Conexión de la configuración regional ('inglés', 'Deutch', etc.) con términos, y tener términos de conexión de rosetta stone y términos en un idioma específico.
2. Agrupación de términos por página. No quiero decir, SELECCIONAR término1, término2, etc. a través de los más de 30 términos que pueda necesitar en una página. Quiero preguntar por la página a la que están conectados.

Aquí está mi estructura de tabla propuesta (tenga en cuenta que todos los ID tienen relaciones / índices entre ellos para hacer consultas muy eficientes):

  * locale
      * id
      * value //English, Deutch, etc//
  * terms
    * id
    * value //In English//
  * page 
    * id
    * value //Think add entry, menu//
  * page_group //group all terms to a page, for easy pulling//
    * id
    * page.id
    * term.id
  * rosetta
    * id
    * locale.id
    * term.id
    * value //french word for amount, description, etc//

Esto permitirá consultas como:

SELECT localization.value,
        terms.value
FROM localization
INNER JOIN terms ON terms.id=localization.termid
INNER JOIN page_group ON page_group.termid=localization.termid
INNER JOIN page ON page.id=page_group.pageid
INNER JOIN locale ON locale.id=localization.localeid
WHERE page.value='add_entry' AND locale.id=custlangid
ORDER BY terms.id

Solo tengo que pedir dos artículos; la identificación del idioma que necesito y la página que necesito. Servirá todos los términos, en el idioma especificado, que forman parte del grupo de términos para esa página.

Creo que esta es una estructura realmente buena, pero me encantaría recibir algunos comentarios.

ACTUALIZACIÓN : Para aclarar, solo estamos hablando de la localización de los componentes de la interfaz de usuario . (etiquetas, navegación, texto útil) Toda la información que ingrese el usuario se almacenará en unicode, no en este esquema.

ACTUALIZACIÓN 2 : De hecho, terminé usando esto, y es genial. Aquí está mi publicación sobre su diseño real, y en acción: http://tim.hithlonde.com/2013/lemon-schema-works/

Hemos hecho mucho de esto, y los usuarios (administrativos) pudieron arreglar las traducciones en vivo. (Es posible que aún desee una capa de almacenamiento en caché, pero estoy totalmente convencido de manejar esto con una base de datos real y no con archivos de recursos; le da un montón de poder para consultar y encontrar cosas que necesitan ser traducidas, etc.). Creo que su esquema probablemente esté bien, por lo que pasaré algunas cosas que aprendimos con la esperanza de que sean útiles.

Una cosa que ha dejado fuera son las frases con puntos de inserción. En el ejemplo a continuación, el orden se invierte y el idioma sigue siendo el inglés, pero esto podría ser fácilmente dos idiomas diferentes; supongamos que son solo dos idiomas que normalmente ponen las cosas en un orden diferente.

Hello, <username> you have <x> points!

You've got <x> points to spend, <username>!

En nuestro pre.NET, teníamos una rutina que hacía la inserción para que las frases se vieran así:

Hello, {0:username} you have {1:points} points!

You've got {1:points} points to spend, {0:username}!

Obviamente, esto simplemente se usaría en su código como <%= String.Format(phrase, username, points); %>o similar

Lo que ayudó un poco al traductor. Pero .NET String.FOrmat no admite comentarios dentro de la cadena de formato, desafortunadamente.

Como dices, no querrás manejar eso en tu php con conocimiento local o metafrases.

Entonces, lo que teníamos era una tabla de frases maestras:

Frases, inglés, información complementaria

y una tabla localizada:

fraseid, localeid, traducción

También ha asumido con INNER JOINS que las versiones localizadas existen: tendimos a dejarlas fuera hasta que se tradujeran, de modo que esa consulta suya no devolvería nada al principio (ni siquiera la predeterminada)

Si no existía una traducción, la nuestra estaba predeterminada en inglés, luego recurría al código provisto (en caso de que la base de datos no tuviera la ID, y también estaba claro en el código qué identificador de frase "TXT_LNG_WRNNG_INV_LOW" realmente estaba tratando de obtener ) - entonces el equivalente de esta consulta es lo que usamos:

SELECT COALESCE(localized.translation, phrase.english, @fallback)
FROM DUAL
LEFT JOIN phrase
    ON phrase.phraseid = @phraseid
LEFT JOIN localized
    ON localized.phraseid = phrase.phraseid
    AND localized.localeid = @localeid

Obviamente, puede obtener todas las cosas al mismo tiempo utilizando su sistema de páginas.

Tendemos a no vincular cosas a la página porque se reutilizaron mucho entre páginas (y no solo en fragmentos de página o controles), pero eso está bien.

En el caso de nuestras aplicaciones nativas de Windows, utilizamos la reflexión y un archivo de mapeo desde el control hasta la etiqueta de traducción para que la traducción no requiriera una nueva compilación (en las aplicaciones anteriores a .NET tuvimos que etiquetar los controles usando la Etiqueta u otra etiqueta especial propiedades). Esto es probablemente un poco más problemático en PHP o ASP.NET MVC, pero es posible en ASP.NET, donde hay un modelo de página del lado del servidor completo.

Para las pruebas, obviamente puede consultar para encontrar traducciones faltantes muy fácilmente. Para encontrar lugares que necesiten ser etiquetados, traduzca el diccionario completo de frases usando pig-latin o Klingon o algo así como reemplazar cada carácter no espacial con? - el inglés debería destacarse y hacerle saber que se ha introducido algo de texto sin formato en su HTML.

Por lo general, las traducciones las realizan empresas especializadas externas. Como tal, sería una molestia administrar el contenido traducido dentro de una base de datos. Es mejor administrarlos en "paquetes" o archivos de propiedades a través de algún tipo de función de lenguaje que ofrece su plataforma. Para lograr eso, en la base de datos, simplemente colocaría una mnemónica para la cadena. Luego, según el idioma deseado, buscaría en el paquete. p.ej.

Data:
Employee_Status = empl_status.active

language Bundles:
Employee.us:  
  empl_status.active=Active

Employee.es
  empl_status.active=<spanish translation goes here>

To get the localized content:
    String status = getLocalizedContent("Employee","empl_status.active", "us");
    String status = getLocalizedContent("Employee","empl_status.active", "es");
    String status = getLocalizedContent("Employee","empl_status.active");

Solo crea 3 tablas

1.) Language Master (LangId, LangName)

2.) Maestro de recursos (ResourceMasterId, TableId, ColumnId, ColumnName)

3.) Detalles del recurso (ResourceMasterId, LangId, Value)

clave compuesta (ResourceMasterId, LangId) en Detalles del recurso