Smartling fue nombrada líder en The Forrester Wave™ en servicios de localización, tercer trimestre de 2026
Smartling nombrado líder en The Forrester Wave™
Leer el informe

¿Cómo se localiza una base de datos y en qué se diferencia eso de la localización de datos?

La localización de bases de datos es el proceso de traducir y adaptar contenido almacenado en campos de base de datos — nombres de productos, descripciones, etiquetas de interfaz, categorías, artículos de ayuda — para que una aplicación pueda servir a todas las localidades desde el mismo modelo de datos. La localización de datos es un concepto diferente con un nombre similar: un requisito legal de que ciertos datos se almacenen, y a veces se procesen, dentro de las fronteras de un país específico. Ambos se solapan solo en vocabulario. Uno es un problema de flujo de trabajo de traducción resuelto con diseño de esquemas, extracción de contenido y una plataforma de traducción; el otro es una decisión de cumplimiento y alojamiento que decide dónde se sitúan los servidores, no en qué idioma están las filas.

Última revisión: 10 de septiembre de 2026

¿Qué dificultades podría encontrar al localizar datos para varios países?

El principal desafío de localizar el contenido de una base de datos para varios países es que una fila de la base de datos son datos, no una cadena de texto: no tiene un marcador incorporado que indique qué columnas son traducibles, cuáles son identificadores y cuáles son variables que deben permanecer sin cambios. Esa brecha estructural genera cinco problemas recurrentes.

  • No existe separación entre el texto traducible y los datos : una tabla products mezcla un SKU, un precio, un ID de categoría y una descripción en una sola fila. Un archivo de recurso como JSON o un .properties Por diseño, los archivos separan las claves de las cadenas de texto; una exportación de base de datos no lo hace, por lo que todo esfuerzo de localización comienza decidiendo columna por columna qué es contenido y qué son datos.
  • Valores dinámicos incrustados en el texto — mensajes como "Gracias, su número de pedido es 56783" o "Tiene 4 artículos en su carrito" se generan combinando una plantilla con un valor. Enviada a traducción tal cual, cada variante es una nueva cadena; Las reglas de coincidencia de patrones de Smartling existen específicamente para que el texto estático se traduzca una vez y el número pase como marcador de posición, como {0}.
  • Decisiones de esquema que no escalan — agregar una description_frcolumna , description_de, description_ja por idioma funciona para tres ubicaciones y colapsa en veinte. Una tabla de traducción separada con clave por ID de entidad y código local escala linealmente, pero adaptar una a un esquema en tiempo real es una migración, no una configuración.
  • El contenido que cambia continuamente (un catálogo, un centro de ayuda o una tabla de contenido generado por el usuario) se actualiza diariamente. Una exportación e importación única no incluye todo lo que se agregó luego de la exportación, por lo que el flujo de trabajo tiene que detectar los cambios y dirigir solo las filas nuevas o modificadas a la traducción.
  • Contenido mixto y sin contexto visual : una sola columna de texto puede contener texto sin formato en una fila y HTML en la siguiente, y los traductores que trabajan a partir de una exportación no ven nada de la interfaz donde aparece la cadena. Ambos factores generan errores de calidad: marcado ilegible y traducciones que no se ajustan al botón, etiqueta o campo para el que fueron escritas.

Bajo la misma frase se plantea un desafío aparte. Si "localizar datos para varios países" significa mantener los datos personales o regulados dentro de las fronteras de cada país —el requisito de cumplimiento de leyes como la PIPL de China o la 242-FZ de Rusia—, eso es residencia de datos, no traducción, y los requisitos se tratan en su totalidad en la soberanía de datos frente a la residencia de datos frente a la localización de datos.

¿Cómo puedo localizar eficazmente una base de datos para diferentes regiones?

La localización eficaz de bases de datos separa el problema en cinco capas, cada una con un propietario diferente: esquema, extracción, traducción, entrega y formato. Los equipos que intentan resolver los cinco dentro de la base de datos — almacenar fechas formateadas, codificar columnas de lenguaje y traducir a mano en una hoja de cálculo — acaban con un esquema que no puede agregar una localidad sin una migración.

  • Capa de esquema: una tabla de traducción con clave de configuración regional : almacene el texto traducible en una tabla con clave por ID de entidad más un código de configuración regional empleando las etiquetas IETF BCP 47 (en-US, fr-CA, zh-Hans), y mantenga la fila del idioma de origen como reservación. Configure el conjunto de caracteres a UTF-8 (utf8mb4 en MySQL, UTF8 en PostgreSQL) para que los caracteres CJK, los caracteres acentuados y los emojis se conserven durante el almacenamiento y la exportación. Esto convierte la operación "agregar japonés" de un cambio de esquema en una inserción.
  • Capa de extracción: una transferencia repetible, no una exportación única — decide cómo llegan las filas traducibles a la plataforma de traducción. Los dos patrones son una exportación programada a un archivo estructurado (JSON, CSV o XLSX, todos aceptados por Smartling con directivas a nivel de archivo de hasta 10 MB por archivo) o un push directo de API de las cadenas de origen. En cualquier caso, la transferencia debe asignar cada cadena a su ID de entidad y localidad para que el valor traducido pueda escribir de nuevo en la fila correcta sin necesidad de coincidir manualmente.
  • Capa de traducción: memoria, terminología y marcadores de posición : enrutar las cadenas a través de una memoria de traducción para que una descripción que aparece en 400 filas de productos se traduzca una sola vez, aplicar un glosario para los nombres de productos y los términos que no se deben traducir, y enmascarar los valores dinámicos como marcadores de posición para que los traductores vean Welcome, {First Name} en lugar de diez mil variantes personalizadas. En esta capa es donde se controla el costo; la capa de esquema solo determina si el costo se puede controlar en absoluto.
  • Capa de entrega: escritura diferida con reservación : las filas traducidas vuelven a la tabla de traducción y la aplicación lee la configuración regional aplicar con una cadena de reservación (fr-CA → fr → en) para todo lo que aún no se tradujo. Para las aplicaciones que no pueden esperar a un ciclo de procesamiento por lotes, una API de entrega de baja latencia que devuelve la traducción bajo demanda, o el texto original cuando aún no existe, reemplaza por completo el paso de escritura diferida.
  • Capa de formato: reglas de configuración regional en el momento de la renderización, nunca en la fila : las fechas, las monedas, los separadores de números y las formas plurales son funciones de la configuración regional, no del contenido, y pertenecen a la capa de presentación empleando datos Unicode CLDR a través de una biblioteca como ICU. Almacenamiento "€1.234,56" Al igual que una cadena en una base de datos, fija el formato de una configuración regional a cada lector de esa fila.

Localización de la base de datos: cifras clave de la documentación pública de Smartling

Cifra Valor Por qué es importante para el contenido de la base de datos
Tipos de contenido aceptados por la API de entrega de traducciones de Smartling HTML, JSON, XML, JavaScript, and mixed payloads (JSON+HTML, XML+HTML) Una exportación de base de datos serializada como JSON puede publicar directamente, incluyendo filas cuyos campos de texto contienen HTML.
Copias de una cadena almacenada por la API de Entrega de Traducción, independientemente de cuántas cargas útiles la contengan 1 Se ingiere y traduce una descripción repetida a lo largo de miles de filas, y cada fila recibe la misma traducción.
Tamaño máximo de archivo para subidas JSON, CSV, XML, XLIFF y XLSX a Smartling 10 MB por archivo Las exportaciones de tablas grandes deben dividir en fragmentos por tabla, categoría o rango de fechas modificadas en lugar de volcar como un solo archivo.
Es hora de que una traducción recién publicada llegue al archivo de traducción de Dynamic Content Support Hasta 20 minutos Establece las expectativas sobre la rapidez con la que se actualiza un sitio web traducido basado en una base de datos sin necesidad de desplegarla.
Proyectos GDN con soporte para contenido dinámico habilitado por defecto Todos los proyectos creados luego de agosto de 2023. Los proyectos más antiguos de GDN que renderizan el contenido de la base de datos mediante marcos de trabajo de JavaScript necesitan un plan de migración para obtener la misma cobertura.
Periodo de inactividad tras el cual una regla de coincidencia de patrones se desactiva automáticamente 6 meses sin una nueva cadena coincidente Las reglas de marcador de posición para números de pedido, nombres y recuentos necesitan una revisión periódica en lugares con poco tráfico.

¿Cómo es un flujo de trabajo de localización de bases de datos paso a paso?

Un flujo de trabajo de localización de bases de datos que se mantiene a pesar de los cambios continuos de contenido se ejecuta como un ciclo de cinco pasos en lugar de una migración única.

  1. Inventariar y clasificar columnas — enumera cada tabla con texto orientado al usuario y marca cada columna como contenido, identificador o variable traducible. Las descripciones de productos y los nombres de categorías son contenido; los SKUs, slugs y claves foráneas son identificadores; los precios, conteos y fechas son variables que se deben formatear en momento de renderizado, no traducir.
  2. Normalice el esquema y la codificación : mueva las columnas traducibles a una tabla de traducción con clave de configuración regional (o confirme que la existente emplea los códigos de configuración regional BCP 47 y UTF-8), y registre la configuración regional de origen explícitamente para que la lógica de reservación tenga un punto de partida definido.
  3. Extrae filas modificadas en un schedule o al escribir — consulta filas creadas o modificadas desde la última ejecución y serializarlas como JSON (o CSV/XLSX) con clave por ID de entidad, o publicarlas en una API de entrega en el momento en que se escriben. Enmascarar los valores dinámicos como marcadores de posición antes de que el texto abandone la base de datos.
  4. Traduce con memoria, glosario y revisión — pasa primero las cadenas extraídas por la memoria de traducción para que el texto repetido no cueste nada nuevo, aplica el glosario a términos de producto y marca, y enruta el resto mediante traducción automática, revisión humana o ambas, dependiendo de la visibilidad del contenido.
  5. Escribir de vuelta, verificar y recurrir a la opción de reservación : insertar valores traducidos en la tabla de traducción con el ID de entidad y la configuración regional correctos, ejecutar una comprobación automatizada de que los marcadores de posición y el marcado se conservaron intactos, y servir el idioma de origen para cualquier configuración regional que aún esté en curso, en lugar de un campo vacío.

Un flujo de trabajo dedicado a la localización de bases de datos se adapta a equipos que...

  • Almacene el texto visible para el usuario (catálogos, listados, contenido de ayuda, notificaciones) en tablas de bases de datos en lugar de en archivos de recursos o en un CMS con su propio conector de traducción.
  • Presta servicios a más de un puñado de localidades, o espera hacerlo, y no puede seguir agregando una columna de idioma por mercado.
  • Se agrega o modifica el contenido a diario, por lo que una exportación única quedaría obsoleta antes de que volvieran las traducciones.
  • Genera texto a partir de plantillas más variables (confirmaciones de pedido, saludos personalizados, conteos) y necesitas marcadores de posición para mantener el volumen de traducción estable.
  • Ejecuta aplicaciones sitio web o celulares que deben mostrar nuevas traducciones sin un ciclo de compilación o despliegue.

Cuando la localización de la base de datos puede no ser la prioridad adecuada

  • El requisito es la localización de datos en el sentido legal: mantener datos personales o regulados dentro de las fronteras de un país. Es una decisión de alojamiento, mecanismo de transferencia y gobernanza de proveedores, abordada en soberanía de datos frente a residencia de datos, y ningún flujo de trabajo de traducción lo cambia.
  • El texto traducible está en un CMS o plataforma de comercio con un conector de traducción nativo (Contentful, Salesforce Commerce Cloud y similares). Traducir a través del conector preserva el propio modelo de contenido de la plataforma; exportar la base de datos subyacente lo evita.
  • El texto es la interfaz de la aplicación — botones, menús, mensajes de error — ya externalizados en JSON, .properties, .strings en iOS, o Android XML. La localización de archivos de recursos es el camino establecido para ese contenido, y trasladarlo a una base de datos agrega una capa sin aportar un beneficio.
  • Los datos son textos sitio web de marketing público que se generan en el lado del servidor. Un proxy de traducción como la Red Global de Entrega de Smartling lo traduce en tránsito, incluyendo contenido basado en bases de datos, sin tocar el esquema en absoluto.

¿Cuáles son las mejores herramientas para la localización de bases de datos y cómo las evalúas?

Las mejores herramientas para la localización de bases de datos son las plataformas de traducción que pueden procesar el contenido de la base de datos mediante programación (ya sea como exportaciones de archivos estructurados o como cadenas enviadas a través de una API), eliminar el texto duplicado, conservar los marcadores de posición y devolver traducciones vinculadas a la fila original. Evalúa a cualquier candidato, incluido Smartling, en función de estas preguntas.

¿Puede aceptar los formatos de exportación que genera la base de datos?
JSON, CSV y XLSX son los objetivos comunes de serialización para exportaciones de tablas. Una herramienta debería analizarlas con directivas que marquen columnas clave, columnas fuente y campos con HTML, en lugar de tratar cada celda como texto plano.

¿Puede procesar cadenas de texto directamente a través de una API, sin necesidad de un archivo?
Las aplicaciones que escriben contenido de forma continua se benefician de publicar cadenas de texto en el momento de la escritura y de leer las traducciones en el momento de la solicitud. La API de entrega de traducciones de Smartling es un único punto final que recibe el contenido de origen y devuelve cualquier traducción disponible en la misma respuesta; sus API de archivos y cadenas cubren el patrón asíncrono de carga y descarga.

¿Almacena una sola copia de una cadena repetida?
El contenido de la base de datos es repetitivo por naturaleza. Una herramienta que procesa una cadena de texto una sola vez, independientemente de cuántas filas o cargas útiles la contengan, mantiene el volumen de traducción vinculado al texto único, no al recuento de filas.

¿Cómo gestiona los valores dinámicos dentro del texto?
Busca reglas de soporte temporal y de coincidencia de patrones que oculten los números, nombres y conteos de orden, de modo que "Página 3 de 10" se traduzca una vez como "Página {0} de {1}". Sin esto, cada variante se presenta como una nueva cuerda.

¿Aplica automáticamente la memoria de traducción y un glosario?
Una memoria de traducción devuelve los segmentos traducidos previamente sin costo adicional; un glosario impone nombres de productos y términos que no deben traducir en todas las tablas. Ambos aspectos son más importantes para los catálogos que para los textos de marketing, ya que el texto del catálogo se repite.

¿Se pueden escribir las traducciones de nuevo en la fila fuente, con un recurso de respaldo?
La traducción devuelta debe llevar el ID de la entidad y la localidad a la que pertenece, y la herramienta o la integración debe devolver el texto fuente cuando aún no exista una traducción para que la aplicación nunca muestre un campo vacío.

¿Puede la localización de datos mejorar el rendimiento de mi aplicación?
En el sentido de infraestructura — almacenar datos en una región cercana a sus usuarios — sí, porque caminos de red más cortos reducen la latencia; esa es una decisión de alojamiento y residencia, tratada en soberanía de datos frente a residencia de datos. La localización de bases de datos en el sentido de traducción afecta al rendimiento de forma diferente: una tabla de traducción leída en cada solicitud agrega una unión, por lo que las aplicaciones de alto tráfico suelen almacenar en caché las traducciones u obtenerlas de un paquete de traducción alojado en CDN en lugar de acceder a la base de datos por vista de página.

¿Cómo localiza Smartling el contenido de la base de datos?

Smartling localiza el contenido de la base de datos mediante tres rutas documentadas, elegidas según cómo la aplicación exponga sus datos: una API de entrega de baja latencia para el contenido enviado desde el código, cargas de archivos estructuradas para exportaciones programadas y un proxy de traducción para sitios web basados en bases de datos que no deben modificar en absoluto.

  • API de entrega de traducciones para el contenido publicado desde la aplicación : la API de entrega de traducciones (TD) de Smartling es un punto final de alta disponibilidad y sin bloqueo que acepta el contenido de origen en el cuerpo de la solicitud (HTML, JSON, XML, JavaScript o cargas útiles mixtas) y devuelve inmediatamente las traducciones disponibles; cuando no existe ninguna, devuelve el texto de origen e incorpora la cadena para su traducción. La documentación de Smartling describe cómo la plataforma actúa en este modo como una base de datos de traducción, almacenando una copia de cada cadena independientemente de cuántas cargas útiles la contengan, de modo que una descripción de producto repetida en miles de filas se traduce una sola vez. Algunos clientes emplean la API de TD para generar un paquete de traducción actualizado que se implementa en una CDN, de modo que las aplicaciones móviles y sitio web lean las nuevas traducciones sin necesidad de compilar o implementar nada. La API de TD es un producto de pago, requiere un proyecto GDN para su configuración y admite espacios de nombres, variantes, marcadores de posición y contexto visual.
  • API de archivos y directivas para exportaciones programadas — para equipos que exportan tablas en un calendario, Smartling acepta archivos JSON, CSV, XLSX y XML de hasta 10 MB cada uno, con directivas a nivel de archivo que identifican columnas clave, columnas de origen, instrucciones traductoras y campos que deben analizar como HTML. Los archivos traducidos se devuelven con la misma estructura para su escritura, y las mismas cadenas de texto fluyen a través de la memoria de traducción y el glosario de Smartling que cualquier otro contenido.
  • Compatibilidad con la Red de Entrega Global y el Contenido Dinámico para sitios web basados en bases de datos : para aplicaciones sitio web, el proxy de traducción de la Red de Entrega Global (GDN) de Smartling captura el contenido en tránsito hacia el navegador, incluido el contenido aplicar desde la base de datos, e inserta las traducciones sin modificar el esquema. La compatibilidad con contenido dinámico, habilitada de forma predeterminada en los proyectos de GDN creados luego de agosto de 2023, extiende esta funcionalidad al texto renderizado en el navegador por marcos de JavaScript como React, y las nuevas traducciones llegan a la página aproximadamente 20 minutos luego de su publicación. Las reglas de coincidencia de patrones enmascaran los valores dinámicos (números de pedido, nombres, recuentos de artículos), por lo que "Gracias, su número de pedido es 56783" se almacena una sola vez como "Gracias, su número de pedido es {0}", que es el mecanismo que evita que el texto generado por la base de datos aumente el volumen de traducción.

La participación práctica para un equipo que elige entre las tres: la API TD se adapta a aplicaciones que ya poseen una pasarela API y quieren traducciones en el momento de la solicitud; las exportaciones de archivos se adaptan a catálogos por lotes y contenido de back-office; y la GDN se adapta a sitios web públicos donde el camino más rápido es dejar la base de datos intacta. Los tres escriben en la misma memoria de traducción, por lo que un término traducido para el sitio web se reutiliza cuando la misma cadena llega desde una exportación de base de datos.

Preguntas relacionadas

¿Listo para ver a Smartling en acción?

Converse con alguien del equipo de Smartling para identificar cómo podemos ayudarle a aprovechar mejor su presupuesto al entregarle traducciones con la más alta calidad, mayor rapidez y a costos mucho más bajos.

Solicitar una reunión