2010-02-26 13 views
6

Estoy desarrollando un sitio web en PHP y me gustaría darle al usuario la facilidad de cambiar de alemán a inglés.¿Cuál es la mejor manera de poner un sistema de traducción en el sitio web php?

Por lo tanto, una política de traducción se debe considerar:

debo almacenar los datos y su traducción en una tabla de base de datos ((1, "Hola", "hola"), (2, "Buenos días", "Guten Tag"), etc ..?

O debería utilizar el ".mo" archivos para almacenarlo?
¿Qué camino es el mejor?
¿Cuáles son los pros y los contras?

+0

Duplicado. Consulte http://stackoverflow.com/questions/2275270/whats-the-simplest-php-alternative-to-the-php-gettext-extension-which-can-be-sup http://stackoverflow.com/questions/2149116/php-localization-question –

Respuesta

4

Hay algunos factores que debes considerar.

¿El sitio web se actualizará frequentemente? si es así, ¿por quién? usted o el dueño? ¿Con qué cantidad de datos/información está tratando? y también ... ¿lo haces con frecuencia (para muchos clientes)?

No puedo pensar que el uso de una base de datos relacional pueda reducir los graves impactos de velocidad a menos que tenga un tráfico MUY alto (varios cientos de miles de páginas vistas por día).

Si lo hace con frecuencia (para muchos clientes) no lo piense más: construya un CMS (o use uno existente). Si realmente necesita considerar el impacto en la velocidad, puede personalizarlo para que cuando termine con el sitio web pueda exportar páginas HTML estáticas siempre que sea posible.

Si actualiza con frecuencia, se aplica lo mismo que arriba. Si el cliente tiene que actualizar (y no usted), nuevamente, necesita un CMS. Si está tratando con mucha información (grandes y muchos artículos), necesita un CMS.

Con todo, un CMS le ayudará a construir rápidamente la estructura de su sitio web, agregar contenido rápidamente y no preocuparse tanto por el código, ya que será reutilizable.

Ahora, si solo necesita crear un sitio web pequeño rápidamente, puede hacerlo fácilmente con matrices y archivos de datos codificados.

+0

Actualización. Esta publicación de la mía falla al sugerir una estrategia de almacenamiento en caché que no sea HTML estático. También se podría usar Memcache, Redis o alguna base de datos NoSQL bajo ciertas circunstancias. – mspir

1

Si necesita proporcionar una interfaz web para agregar/editar traducciones, entonces la base de datos es una buena idea.

Si, sin embargo, sus traducciones son estáticas, usaría gettext o incluso matriz PHP simple.

De cualquier forma puede aprovechar Zend_Translate.

pequeña comparación, los dos primeros de Zend tutorial:

matrices
  1. Llanura PHP: Pequeñas páginas; uso más simple; solo para programadores.
  2. Gettext: GNU standard for linux; a salvo de amenazas; necesita herramientas para la traducción
  3. Base de datos: Dinámico; El peor rendimiento
0

Recomendaría las matrices PHP, se pueden construir en torno a una GUI para facilitar el acceso.

6

También sugiero el paquete Zend Framework Zend_Translate.

El manual ofrece una buena visión general en How to decide which translation adapter to use. Incluso cuando no se usa ZF, esto le dará algunas ideas sobre lo que hay y cuáles son los pros y los contras.

adaptadores para Zend_Translate

  • matriz
    • Uso de PHP matrices pequeñas páginas;
    • uso más simple; sólo para programadores
  • Csv
    • Uso separados por comas (.csv / .txt)
    • formato de archivo de texto simple; rápido; posibles problemas con los caracteres Unicode
  • Gettext
    • uso de gettext binario (*.mo) archivos GNU estándar para Linux;
    • hilo-seguro; necesita herramientas para la traducción
  • Ini
    • Uso sencilla ini (* .ini)
    • formato de archivo de texto simple; rápido; posibles problemas con los caracteres Unicode
  • Tbx
    • intercambio de Uso base de datos terminológica (.tbx/ .xml)
    • estándar de la industria para las cadenas de terminología aplicación inter; formato XML
  • Tmx
    • Uso TMX (.tmx/ .xml)
    • estándar de la industria para la traducción entre la aplicación; Formato XML; legible
  • Qt
    • Uso lingüista QT (* Ts) Archivos
    • marco de aplicación multiplataforma; Formato XML; legible
  • xliff
    • Uso xliff (.xliff/ .xml)
    • un formato más sencillo como TMX pero relacionado con él; Formato XML; legible
  • XmlTm
    • Uso xmltm (* .xml)
    • estándar de la industria para la memoria de traducción de documentos XML; Formato XML; legible
8

justo después de haber abordado este mismo recientemente (12 idiomas y contando) en un sistema de producción y de haber topado con algunos de los principales problemas de rendimiento a lo largo de la manera que sugeriría un sistema híbrido.

1) Almacene las cadenas de idioma y las traducciones en una base de datos; esto facilitará la interacción con/actualizar/eliminar elementos y será parte de sus rutinas de respaldo normales.

2) Guarde los idiomas en archivos planos en el servidor y sáquelos según sea necesario para mostrar en la página.

Los beneficios aquí son muchos, ¡sobre todo es rápido! No me ocupo de la sobrecarga de conexión para MySQL o de la ralentización del tráfico durante la transferencia. (especialmente importante si su servidor de base de datos no es localhost).

Esto también lo hará muy fácil de usar.Almacene los datos de su base de datos en el archivo como un conjunto serializado php y GZIP el contenido del archivo para reducir la sobrecarga de almacenamiento (esto también lo hace más rápido en mi evaluación comparativa).

Ejemplo:

$lang = array(
    'hello' => 'Hallo', 
    'good_morning' => 'Guten Tag', 
    'logout_message' = > 'We are sorry to see you go, come again!'  
); 

$storage_lang = gzcompress(serialize($lang)); 

// WRITE THIS INTO A FILE SUCH AS 'my_page.de' 

Cuando un usuario carga el sistema por primera vez hacer un file_exists('/files/languages/my_page.de'). Si el archivo existe, cargue el contenido, descomprima y anule la serialización, y estará listo para funcionar.

Ejemplo

$file_contents = get_contents('my_page.de'); 
$lang = unserialize(gzuncompress($file_contents)); 

Como se puede ver que puede hacer que el almacenamiento en caché específica para cada página en el sistema de mantenimiento de la sobrecarga aún más pequeño y utilizar la extensión de archivo para indicar el lenguaje ... (my_page.en , my_page.de, my_page.fr)

Si el archivo NO existe, consulte el DB, construya su matriz, serialícela, gzip y escriba el archivo faltante, al mismo tiempo que acaba de construir el archivo. array que la página necesita, así que continúa para mostrar la página y todo el mundo está contento.

Finalmente, esto le permite crear páginas de actualización accesibles para quienes no son programadores, pero también controla cuándo aparecen los cambios al decidir cuándo eliminar los archivos de caché para que puedan ser reconstruidos por el sistema.

advertencias y errores

Mientras guardé todo en la base de datos directamente nos golpean algunas ralentizaciones PRINCIPALES cuando nuestro tráfico se disparó.

Tratar de mantenerlos en matrices de archivos planos fue un problema porque las actualizaciones eran dolorosas y propensas a errores.

No comprimir GZIP los contenidos de los archivos de caché ha hecho que el sistema de idioma sea un 20% más lento en mis puntos de referencia.

Asegúrese de que todos los campos de su base de datos que contienen los idiomas están configurados en UTF8-general-ci (o al menos una de las opciones de UTF8, considero general-ci el mejor para mi uso). Si no lo hace usted no será capaz de almacenar conjuntos de caracteres no Unicode en su base de datos (como el chino, japonés, etc.)

Extensión: En respuesta a un comentario más abajo, asegúrese de ajustar su base de datos tiene en cuenta las cadenas de idioma de nivel de página.

id  string    page  global 
1  hello    NULL   1 
2  good_morning  my_page.php 0 

Todo lo que aparece en los encabezados o pies de página puede tener un indicador global que será consultada en todos los archivos de caché creado, de lo contrario consultarlos por página para mantener su sistema de respuesta.

+1

Mantenerlo en una base de datos realmente reduciría la carga de la página y reduciría el rendimiento. O bien estaría almacenando en caché todas las cadenas que ocuparán la memoria innecesaria, o buscará una fila para cada cadena que solo provocaría una revisión de la conexión. Las matrices son mucho más rápidas, más fáciles de administrar y más fáciles de obtener. – casraf

+2

@henasraf - Estoy completamente en desacuerdo. Con el almacenamiento en caché de archivos, obtiene el beneficio de tener una base de datos para actualizaciones y nuevas inserciones de fila, pero solo debe consultar las filas necesarias la PRIMERA vez que se carga la página. Una persona toma ese golpe y todos los demás se benefician. También te equivocas al asumir que tienes que tirar cada fila. Puede consultar un archivo para cada página en su sistema y solo cargar las cadenas para esa página haciendo que los archivos sean pequeños. Finalmente, haciendo un readfile y unserialize en un archivo plano con gzip es en realidad más rápido en mis benchmarks que incluir un archivo php array no gzip. – Shane

+0

Hola @shanee, esta es una manera impresionante de tratar con la localización ... Después de todos estos años, ¿todavía crees que es eficiente o sugerirías un enfoque mejor? – KAD

5

Las matrices PHP son de hecho la forma más rápida de cargar traducciones. Sin embargo, usted realmente no desea actualizar estos archivos a mano en un editor. Esto podría funcionar al principio, y para uno o dos idiomas, pero cuando su sitio crece esto se vuelve realmente difícil de mantener.

Te aconsejo que configures unas tablas simples en una base de datos donde guardes las traducciones, y construyas una aplicación simple que te permita actualizar las traducciones (algunos formularios para agregar y actualizar textos). En cuanto a la base de datos: use una tabla para almacenar variables de traducción; use otro para vincular las traducciones a estas variables.

Ejemplo:

`text` 

id variable 
1 hello 
2 bye
`text_translations` 

id textId language translation 
1 1  en  hello 
2 1  de  hallo 
3 2  en  bye 
4 2  de  tschüss

Así que lo que hace es:

  • crear la variable en la primera tabla

  • añadir las traducciones de que en la segunda tabla (en el idioma que desee)

vez que haya actualizado las traducciones, crear/actualizar un archivo de idioma para cada idioma que se está utilizando:

  • seleccionar las variables que necesita y su traducción (consejo: utilizar Inglés si hay sin traducción)

  • crear una gran matriz con todas estas cosas, por ejemplo:

$texts = array('hello' => 'hallo', 'bye' => 'tschüss');
  • escribir la matriz a un archivo, por ejemplo:
file_put_contents('de.php', serialize($texts));
  • en su PHP/HTML crear la matriz del archivo (basado en el idioma seleccionado por el usuario), por ejemplo:
$texts = unserialize(file_get_contents('de.php'));
  • en su PHP/HTML utilizan las variables, por ejemplo:
<h1><?php echo $texts['hello']; ?></h1> 

or if you like/enabled PHP short tags: 

<p><?=$texts['bye'];?></p>

Esta configuración es muy flexible, y con unas formas para actualizar las traducciones que es fácil de mantener su sitio al día en varios idiomas.

0

Sé consciente de que todos en el mundo cuando se trata de computadoras, por lo general, saben inglés común utilizado en la computadora o en Internet como Acerca de nosotros, Inicio, Enviar, Eliminar, Leer más, etc. Pregunta: ¿Realmente necesitan ser traducidos? ?

Ok, honestamente, algunas traducciones a esas palabras no son realmente 'requeridas', todo se trata de 'estilo'.

Ahora, si realmente se desea, para las palabras comunes que no necesitan cambiarse para siempre, es mejor utilizar un archivo php que muestre lang array para solo local e inglés. Y para algunos contenidos como blog, noticias y algunas descripciones, use la base de datos y guárdelos en tantos como sea necesario. Debes hacerlo manualmente

¿Utiliza y confía en Google Translate? Creo que debes pensar 1000 veces. Al menos por esta década.

Cuestiones relacionadas