¿Por qué gettext no tiene una opción de almacenamiento db?

Question

Estoy haciendo algo de i18n en una aplicación web usando Django, que usa gettext como su base i18n. Parece una idea obvia que las traducciones deben almacenarse en la base de datos, y no es difícil hacerlo, pero los archivos po en el sistema de archivos todavía se están utilizando. ¿Por qué es esto?

Mi sospecha actual es que los beneficios de desarrollar una base de datos db simplemente se ven superados por la fiabilidad/familiaridad de gettext como un paquete bien establecido. ¿Hay otras razones importantes para continuar almacenando las traducciones en el sistema de archivos?

Answer 1

El rendimiento es la razón principal. Gettext no está utilizando una base de datos porque una base de datos siempre será considerablemente más lenta que un archivo. El tiempo de carga del diccionario es muy importante y por esta razón casi todo el mundo está usando archivos para eso.

Además, los archivos gettext compilados (.mo) están optimizados para cargarse en la memoria y por esta razón son más apropiados que los archivos de texto sin formato (como los archivos .po no compilados).

Siempre puede utilizar la plataforma de traducción, probablemente que utiliza un servidor de base de datos, para haciendo la traducción y exportar los resultados a archivos de texto.Ejemplos: Pootle, Narro, Launchpad Rosetta, Transifex (hosted only).

No confunda sus archivos de idioma de la aplicación con la base de datos de localización. Su aplicación debe usar diccionarios basados ​​en archivos que son rápidos de cargar y su sistema de localización probablemente tendrá que usar una base de datos y lógicamente podrá exportar datos a los archivos.

Por cierto, usar gettext es probablemente la mejor decisión tecnológica que pueda tomar con respecto a la localización. Nunca he visto ninguna solución comercial o desarrollada internamente para poder competir con ella en características, herramientas e incluso soporte.

Answer 2

Esto parece una idea obvia para usted, no creo que todos estén de acuerdo. Que yo sepa Django usa los archivos .po por las razones siguientes: control de

• Versión - usted tendrá que crear más ".po a la base de datos" herramientas, ya que todavía tienen que mantener diferentes personas que trabajan en traducciones, y no se puede alejarse de tener archivos .po para ese propósito
• gettext es una forma estándar de hacer traducciones en .nix world, hay muchas herramientas para trabajar con él y es fácil de editar, diff, etc.
• No es necesario golpear la base de datos si necesita traducir algo. Algunas vistas pueden funcionar sin ninguna solicitud de DNS, por lo que no es necesario vincularlas a la base de datos solo para obtener la traducción. (Puedo estar equivocado, pero en el caso de mod_wsgi - las traducciones se cargarán una vez y se almacenarán en la memoria para cada hilo).

Por cierto, si necesita tener diferentes traducciones para los campos, es una pregunta un poco diferente y debe marcar http://www.muhuk.com/2010/01/dynamic-translation-apps-for-django/ y elegir la aplicación que mejor se adapte a sus necesidades.

Answer 3

Es una forma muy común de hacer traducciones que ha existido por mucho tiempo permitiendo que cualquier problema sea resuelto a lo largo de los años. Me imagino escribiendo algo así como gettext sería demasiado fácil hacer generalizaciones incorrectas sobre cómo funcionan los idiomas. ¿Por qué debería el equipo de desarrollo de Django pasar tiempo investigando eso y desarrollándolo cuando ya se ha hecho en un sistema probado y probado? Además, los traductores profesionales probablemente saben qué hacer con los archivos PO, ya que una base de datos de traducción doméstica puede evitar que funcionen de la manera en que están acostumbrados.

¿Por qué prefiere traducciones en una base de datos? Supongo que podría preferirlo ya que podría hacer una interfaz de traducción a la base de datos. Si ese es el caso, eche un vistazo a Pootle, es una poderosa interfaz de traducción basada en la web que trabaja directamente con archivos PO e incluso puede integrarse con sistemas de control de versiones comunes. Agregue algunos ganchos post-commit y puede tener dicho sistema con poco trabajo y sin la sobrecarga de una base de datos de traducciones.

Espero que ayude.