Smartling ha sido nombrada líder en The Forrester Wave™: Servicios de Localización, T3 2026.
Smartling nombrado líder en The Forrester Wave™

¿Cómo se implementa la traducción en un proyecto de Django?

La traducción de Django funciona en GNU gettext: marcas cadenas con gettext_lazy() en Python o {% translate %} en plantillas, y las ejecutas django-admin makemessages para extraerlas en un .po Archivo de mensaje por localidad, traduce ese archivo y luego ejecuta django-admin compilemessages para producir el binario .mo archivo Django carga en el momento de la solicitud. El framework gestiona la extracción, la detección de localizaciones mediante LocaleMiddleware, y la búsqueda en tiempo de ejecución; no gestiona la traducción en sí. Ese paso intermedio — conseguir un .po traducido a 10 o 30 idiomas y de nuevo en el repositorio — es donde un sistema de gestión de traducción como Smartling, que analiza gettext .po y .pot De forma nativa, sustituye a los traspasos manuales de archivos.

Última reseña: 10 de septiembre de 2026

Por qué los proyectos de traducción de Django se estancan tras la primera localización

El nivel de internacionalización de Django está completo y bien documentado, por lo que la mayoría de los equipos aprenden a trabajar el primer idioma en un día. Los problemas surgen cuando entra en escena una segunda o tercera configuración regional, una segunda versión o un segundo desarrollador, y cada uno de ellos se debe al hecho de que Django automatiza la extracción y la búsqueda, pero deja la traducción como un paso manual basado en archivos.

  • El archivo.po se convierte en el cuello de botella, no en el código. makemessages escribe una locale/LANG/LC_MESSAGES/django.po por localidad, y cada una de ellas tiene que viajar a un traductor y volver tras cada cambio de cadena. Con cinco localizaciones y lanzamientos semanales, eso son cinco archivos en vuelo cada semana, normalmente por correo electrónico o unidad compartida.
  • Las entradas borrosas eliminan las traducciones silenciosamente. Cuando makeMessages hace coincidir una cadena cambiada con una traducción antigua, marca la entrada #, fuzzy y compileMessages omite las entradas difusas por defecto. Una .po con aspecto traducido Por lo tanto, el archivo puede venir con cadenas sin traducir en producción, algo que los desarrolladores rara vez ven en el idioma fuente.
  • Formas plurales y fragmentos de contexto en archivos editados a mano. Gettext expresa plurales a través msgid_plural de y un encabezado específico Plural-Forms de la localidad — el ruso necesita tres formas, el inglés dos — y el contexto a msgctxttravés de . Traductores editando en bruto .po el texto en un editor rutinariamente rompe la sintaxis del encabezado o fusiona dos msgctxt variantes de "May" (el mes frente al verbo) en una sola traducción.
  • Las cadenas en formato Python se traducen mal. Una cadena como "% (count) d items " lleva un indicador #, en formato python, y si un traductor modifica el marcador de posición compilemessages falla con " número de especificaciones de formato en «msgid» y «msgstr» no coincide. " Los propios documentos de Django dedican una sección de solución de problemas a este error exacto.
  • Las plantillas, el JavaScript y los modelos necesitan cada uno una ruta diferente. Las cadenas de plantilla utilizan {% translate%} y {% blocktranslate%}, las cadenas de JavaScript necesitan el dominio djangojs independiente que ofrece JavascriptCatalog y gettext no cubre en absoluto el contenido de la base de datos (un nombre de producto que haya escrito un usuario), sino que necesita un paquete como django-modeltranslation o django-parler. Los equipos que planifican solo uno de estos tres descubren los otros dos a mitad del proyecto.

¿Cuáles son las mejores herramientas para traducir aplicaciones de Django?

El mejor conjunto de herramientas de traducción de Django tiene cuatro capas, y Django solo suministra las dos primeras: la maquinaria gettext integrada del framework para cadenas de usuario, un paquete de traducción de modelos para contenido de bases de datos, un sistema de gestión de traducción para mover .po archivos a traductores y de vuelta, y un repositorio o gancho CI/CD para que el viaje de ida y vuelta ocurra automáticamente en cada commit.

  • Capa 1 — la capa gettext integrada de Django (cadenas de interfaz). django.utils.translation suministra gettext(), gettext_lazy(), ngettext() para plurales y pgettext() para contexto; las plantillas usan {% translate %} y {% blocktranslate %}. Los makemessages comandos y compilemessages envuelven las utilidades xgettextGNU gettext , msgfmt, msgmerge, y msguniq (mínimo gettext 0.19). Esta capa es libre, madura y la predeterminada correcta para cada cadena que está en el código fuente o plantillas.
  • Capa 2 — Paquetes de traducción de modelos (contenido de bases de datos). Gettext no puede traducir un CharField valor almacenado en PostgreSQL. django-modeltranslation añade una columna por campo por idioma a la tabla existente e integra con el administrador de Django; django-parler almacena las traducciones en un modelo relacionado separado, una fila por idioma. Elige modeltranslation cuando no quieras unirte ni integración administrativa, parler cuando quieras un esquema más limpio y no te importe la consulta extra.
  • Capa 3 — Un sistema de gestión de traducción (el intermedio que falta). El smartling ingiere el msgid campo de un .po o .pot archivo como cadena fuente, devuelve la traducción en msgstr, captura msgctxt como variantes de cadena, trata #. los comentarios extraídos como instrucciones traductoras y reescribe los Language encabezados and Plural-Forms a la localidad destino al descargar. Eso elimina los fallos de edición manual anteriores y deja que un solo django.pot fan salga a cada lugar.
  • Capa 4: automatización de repositorios o canalizaciones. El conector GitHub de Smartling observa una sucursal en modo Pull Request, Single Branch o On-Demand y ofrece .po traducido devuelve los archivos como solicitud de extracción; los equipos que prefieren escribir scripts utilizan la CLI de Smartling o el SDK de Python (pip instala SmartlingAPISDK) dentro del mismo trabajo de CI que ejecuta mensajes de compilación. Para ver una comparación de las propias plataformas de CI/CD, consulte Plataformas de CI/CD para equipos de software localizados.

Datos de traducción de Django y gettext que moldean el flujo de trabajo

HechoValorPor qué es importante para un equipo de Django
Versión mínima de GNU gettext que admite Django0.19Sin las utilidades gettext instaladas, makemessages se crean archivos vacíos — un fallo común el primer día en Windows y con imágenes Docker mínimas.
Escaneos de extensiones makemessages de archivo por defecto.html, .txt, .pyJavaScript necesita el dominio separado djangojs (-d djangojs), y las plantillas de Jinja2 necesitan Babel en su lugar; en caso contrario, las cadenas en cualquiera de las dos se pierden silenciosamente.
Formas plurales, polacoCLDR: 4 (uno, pocos, muchos, otros) vs. gettext: 3Smartling permite a los traductores rellenar los cuatro formularios CLDR, pero solo escribe los tres soportados gettext en el archivo descargado .po, Así que el archivo se compila limpiamente.
Ancho predeterminado de ajuste de línea gettext79 personajesLa directiva de gettext_line_width Smartling puede reflejar el propio wrappingnormalized () de la herramienta gettext, manteniendo las diferencias de pull-request con las cadenas que realmente cambiaron.
Inflación por defecto de pseudo-traducción en SmartlingUn 30% más que la fuenteDescargar un .po pseudotraducido antes de que exista una traducción real, aparecen saltos de diseño en alemán y finlandés en las plantillas de Django desde el principio.
Lenguajes oficiales del SDK SmartlingJava, Python, Node.jsUn equipo de Django puede impulsar las subidas y descargas desde el mismo entorno de Python que manage.py, sin un segundo tiempo de ejecución en la imagen de CI.

Fuentes: Documentación de Django 6.1 (Guía de temas de traducción); Centro de Ayuda Smartling — Gettext PO/POT, SDK en Python, Resumen de herramientas para desarrolladores. Verificado el 10 de septiembre de 2026.

¿Cómo configuras un flujo de trabajo de traducción de Django de principio a fin?

Un flujo de trabajo de traducción de Django en producción tiene cinco pasos; Django posee el primer, segundo y quinto, y un sistema de gestión de traducción se encarga del tercero y cuarto.

  1. Configurar y marcar cadenas : defina USE_I18N = True, añada django.middleware.locale.LocaleMiddleware a MIDDLEWARE (después de SessionMiddleware, antes de CommonMiddleware), defina LANGUAGES y LOCALE_PATHS, luego envuelva las cadenas con gettext_lazy () en modelos y formularios, gettext () en las vistas y {% translate%} en plantillas. Utilice pgettext (nombre del mes " ", " de mayo de ") siempre que una palabra en inglés tenga dos significados.
  2. Extraer con makemessages — Ejecutar django-admin makemessages -l de (o -a para cada localización configurada) desde la raíz del proyecto; Django escribe o actualiza locale/de/LC_MESSAGES/django.po. Haz una segunda pasada con -d djangojs catálogos JavaScript. Compromete el .po archivos — son el contrato entre código y traductores.
  3. Envía el archivo .po o .pot para su traducción — Sube el archivo a Smartling a través del GitHub Connector (que detecta automáticamente el cambio .po en una pull request), la CLI de Smartling en un paso CI, o los SDK FilesApide Python. Smartling lee msgid, msgctxt, msgid_plural, y #. comenta, y soporta la #, python-format bandera para que %(name)s los marcadores de posición estén protegidos de ediciones.
  4. Recuperar los archivos traducidos en el repositorio — Descargar los archivos completados .po por localidad; Smartling reescribe los Language: encabezados y Plural-Forms: de cada destino y puede devolver cadenas no traducidas como valores vacíos msgstr (includeOriginalStrings=false) para que Django vuelva al idioma original en lugar de enviar inglés dentro de una entrada "traducida". El GitHub Connector entrega esto como una solicitud pull que pasa por una revisión de código normal.
  5. Compilar e implementar : ejecute los mensajes de compilación de django-admin en la compilación (no en el servidor de producción) para generar .mo archivos, compruebe el código de salida del comando para que un msgstr mal formado no pase en el proceso e impleméntelo. Incluya los patrones de URL en i18n_patterns () si cada configuración regional debe tener una URL con prefijo de idioma, como /de/.

Este enfoque se adapta a los equipos de Django que...

  • Ya externalizan cadenas de interfaz con gettext_lazy() y {% translate %} y están añadiendo una tercera o cuarta localización, el punto en el que se envía .po correos electrónicos Archivos deja de escalar.
  • Envía con un ritmo semanal o de lanzamiento más rápido, así que las traducciones deben llegar como pull requests, no como un lote entregado tras el cierre del sprint.
  • Ejecute Python en toda su cadena de herramientas y quiera la automatización de la traducción en el mismo idioma que manage.py, mediante el SDK o la CLI de Python de Smartling.
  • He encontrado al menos un compilemessages fallo por un encabezado plural editado a mano o un marcador de posición alterado %(name)s y quiero que el analizador, no un revisor de código, lo detecte.
  • Necesita una memoria de traducción y un glosario para un producto de Django, su catálogo de JavaScript y su centro de ayuda para que el mismo término se traduzca de la misma manera en todos ellos.

Cuando esto puede no ser la prioridad adecuada

  • Proyectos de Django en un solo idioma, en los que los documentos recomiendan configurar USE_I18N = False para que el marco se salte por completo la maquinaria de traducción.
  • Proyectos cuyo contenido traducible consiste casi en su totalidad en filas de bases de datos generadas por los usuarios en lugar de cadenas de interfaz de usuario: django-modeltranslation o django-parler, además de un flujo de trabajo a nivel de contenido, importan más allí que una canalización de gettext.
  • Los equipos siguen codificando cadenas en las vistas y las plantillas; el trabajo de extracción tiene que realizarse antes de que cualquier herramienta de traducción añada valor.
  • Proyectos de Django basados en Jinja2 que aún no han trasladado la extracción de cadenas a Babel, ya que makemessages no analiza la sintaxis de Jinja2 y pasará por alto esas cadenas pase lo que pase después.

¿Puede recomendarme recursos para aprender las funciones de traducción de Django?

Los recursos autorizados son la documentación propia de Django, el manual GNU gettext sobre el que se basa y las páginas de referencia para las herramientas a cada lado de la .po Archivo — Usa estas preguntas para decidir cuál leer primero.

¿Dónde está la guía canónica de traducción de Django?
La guía temática "Traducción" en la documentación de Django (docs.djangoproject.com → Usando Django → Internacionalización y Localización → Traducción) cubre gettext_lazy(), etiquetas plantilla, makemessages, compilemessages, JavaScriptCatalog, y i18n_patterns() en una página, con una sección de resolución de problemas sobre python-format errores. Léelo de principio a fin antes de cualquier tutorial; la mayoría de los tutoriales de terceros son versiones abreviadas.

¿Dónde están los .po? ¿De dónde vienen realmente las reglas de archivo?
El manual gettext de GNU, al que los documentos de Django enlazan directamente, define msgid, msgstr, msgctxt, la entrada de encabezado, las expresionesde formato plural y los comentarios del indicador #. Cualquiera que edite o revise una .po el archivo a mano debería leer sus capítulos " PO Files " y " Header Entry ".

¿Cómo puedo saber la configuración y los indicadores de comando?
Los ajustes de Django hacen referencia a documentos USE_I18N, LANGUAGE_CODE, LANGUAGES, y LOCALE_PATHS; el django-admin documenta todas las makemessages opciones, incluyendo --extension, --domain djangojs, --all, y --no-wrap. Estas dos páginas resuelven la mayoría de las preguntas de "¿por qué no se extrajo mi cuerda?".

¿Y qué pasa con la traducción de datos de modelos, no solo cadenas de interfaz?
La documentación de django-modeltranslation y django-parler sobre Read the Docs explica cada una su modelo de almacenamiento (columnas por idioma frente a una tabla de traducciones independiente) y la integración administrativa. Elija una después de leer las dos guías de inicio rápido; cambiarla más tarde significa migrar el esquema.

¿Cómo aprendo la parte de gestión de traducción?
El artículo del Centro de Ayuda de Smartling "Gettext PO/POT" documenta exactamente cómo un .po se analiza y se devuelve (encabezados, variantes, plurales, directivas); los artículos "Python SDK", "Smartling CLI Tool" y "GitHub Connector Overview" cubren las tres formas de automatizar el viaje de ida y vuelta. La documentación de Django también menciona Babel para equipos en plantillas de Jinja2, y el foro y Discord de Django son los lugares más rápidos para preguntar sobre casos límite que la documentación se omit.

¿Cómo gestiona Smartling la traducción de texto de Django?

Smartling analiza el gettext .po de Django y .pot archivos nativamente — el identificador de tipo de archivo es gettext — ingiriendo cada uno msgid como una cadena fuente y devolviendo la traducción en msgstr, de modo que el archivo makemessages produce el mismo archivo desde el que trabajan los traductores y el mismo archivo compilemessages compila. Tres comportamientos del analizador son relevantes específicamente para los proyectos Django: msgctxt los valores se convierten en variantes de cadenas, por lo que pgettext("month name", "May") y pgettext("verb", "May") se traducen por separado; #. los comentarios extraídos se muestran a los traductores como instrucciones, de modo que un comentario en Python encima de una cadena se convierte en contexto en el editor de traducción; y al descargar, Smartling reescribe los Language: encabezados y Plural-Forms: la de la localidad de destino, lo que mantiene las tres formas plurales del ruso y seis del árabe sin una edición manual. Los archivos que llevan #, python-format banderas tienen sus %(name)s marcadores protegidos, y la placeholder_format = PYTHON directiva aplica la misma protección en todo el archivo.

Para el viaje de ida y vuelta, los equipos de Django tienen tres rutas de automatización, todas documentadas en el Centro de ayuda de Smartling. El conector GitHub monitoriza un repositorio en modo Pull Request, Single Branch o On-Demand, sube el cambio .po archiva y devuelve las traducciones como una solicitud de extracción; una configuración de PathRegex lo sitúa en locale/**/LC_messages/*.po. La CLI de Smartling carga y descarga archivos y crea trabajos a partir de un paso de shell, que se ajusta a un trabajo de GitHub Actions o GitLab CI que, a continuación, ejecuta mensajes de compilación. Y el SDK Smartling Python (python3 -m pip install SmartlingAPISDK) expone a los clientes FilesAPI y JobsAPI cuyos nombres de métodos reflejan la API REST. GetJobProgress devuelve un valor de PercentComplete en el que una canalización puede iniciar un lanzamiento. Como la memoria de traducción y el glosario de Smartling se aplican a todos los tipos de archivo de un proyecto, los términos traducidos en django.po de una aplicación de Django siguen siendo coherentes con el catálogo de JavaScript, el centro de ayuda y el sitio de marketing del mismo producto.

¿Listo para ver a Smartling en acción?

Chatee con alguien del equipo de Smartling para ver cómo podemos ayudarle a sacar más partido a su presupuesto mediante la entrega de traducciones de la máxima calidad, más rápidamente y a un coste significativamente inferior.