¿Cómo se localiza una base de datos y en qué se diferencia 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 reseña: 10 de septiembre de 2026
¿A qué desafíos me enfrentaré a la hora de localizar datos para varios países?
El principal desafío de localizar contenido de bases de datos para varios países es que una fila de base de datos es un dato, no una cadena: no tiene un marcador incorporado para determinar qué columnas son traducibles, cuáles son identificadores y cuáles son variables que deben pasar sin ser tocadas. Esa brecha estructural produce cinco problemas recurrentes.
- No hay separación entre texto traducible y datos : una
productstabla 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 separan claves de cadenas por diseño; una exportación de base de datos no lo hace, así que todo esfuerzo de localización comienza decidiendo columna a columna qué es contenido y qué es 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 — añadir una
description_frcolumna ,description_de,description_japor 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 vivo es una migración, no una configuración. - Contenido que cambia continuamente: un catálogo, un centro de ayuda o una tabla de contenido generado por los usuarios se actualiza a diario. Una exportación e importación únicas omite todo lo que se añade después de la exportación, por lo que el flujo de trabajo tiene que detectar los cambios y enviar solo las filas nuevas o modificadas a la traducción.
- Tipos de contenido mixtos 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 ninguna de las interfaces en las que aparece la cadena. Ambos generan errores de calidad: marcas estropeadas y traducciones que no se ajustan al botón, la etiqueta o el campo para los que se escribieron.
Un desafío aparte se encuentra bajo la misma frase. Si "localizar datos para varios países" significa mantener datos personales o regulados dentro de las fronteras de cada país — el requisito de cumplimiento bajo leyes como la PIPL de China o la 242-FZ de Rusia — eso es residencia de datos, no traducción, y los requisitos se cubren completamente en soberanía de datos, residencia de datos frente a 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 añadir una localidad sin una migración.
- Capa de esquema: una tabla de traducción con clave local: almacene el texto traducible en una tabla con la clave del ID de entidad y un código de configuración regional mediante las etiquetas BCP 47 del IETF (
en-US,fr-CA,zh-Hans) y mantenga la fila del idioma de origen como alternativa. Establezca el juego de caracteres en UTF-8 (utf8 mb4 en MySQL, UTF8en PostgreSQL) para que los guiones, los caracteresacentuadosy los emojis del CJK sobrevivan al almacenamiento y la exportación. Esto convierte " añadir " en japonés de un cambio de esquema en un inserto. - 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 escribirse de nuevo en la fila correcta sin necesidad de coincidir manualmente.
- Capa de traducción: memoria, terminología y marcadores de posición — enrutar cadenas a través de una memoria de traducción para que una descripción que aparezca en 400 filas de producto se traduzca una vez, aplicar un glosario para nombres de productos y términos de no 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. Esta capa es donde se controla el coste; la capa de esquema solo determina si el coste puede controlarse en absoluto. - Capa de entrega: escritura inversa con respaldo: las filas traducidas vuelven a la tabla de traducción y la aplicación lee la configuración regional solicitada con una cadena alternativa (
fr-CA→fr→en) para cualquier cosa que no esté traducida aún. Para las aplicaciones que no pueden esperar a un ciclo por lotes, una API de entrega de baja latencia que devuelva la traducción a petición o el texto fuente cuando aún no lo hay, sustituye por completo al paso de reescritura. - Capa de formato: reglas de configuración regional en el momento del renderizado, nunca en fila: las fechas, las monedas, los separadores de números y las formas en plural son funciones de la configuración regional, no del contenido, y pertenecen a la capa de presentación mediante datos CLDR Unicode de una biblioteca como la UCI. Almacenando " 1.234,56€ " como cadena de una base de datos bloquea el formato de una configuración regional en cada lector de esa fila.
Localización de bases de datos: cifras clave de la documentación pública de Smartling
| Figura | Valor | Por qué es importante para el contenido de las bases 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) | La exportación de una base de datos serializada como JSON se puede publicar directamente, incluidas las 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 | Una descripción repetida en miles de filas se ingiere y traduce una vez, 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 tienen que dividirse por tabla, categoría o rango de fechas de modificación en lugar de volcarse en 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 la expectativa sobre la rapidez con la que una página web traducida basada en una base de datos se actualiza sin un despliegue. |
| Proyectos de GDN con el soporte de contenido dinámico activado por defecto | Todos los proyectos creados después de agosto de 2023 | Los proyectos antiguos de GDN que renderizan el contenido de las bases de datos a través de marcos 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 cuerda a juego | Las reglas de marcadores de posición para los números de pedido, los nombres y los recuentos deben revisarse periódicamente en las zonas con poco tráfico. |
¿Qué aspecto tiene 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 sobrevive a los cambios de contenido en curso se ejecuta como un ciclo de cinco pasos en lugar de una migración única.
- 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 traducirse.
- Normalice el esquema y la codificación: mueva las columnas traducibles a una tabla de traducción con claves locales (o confirme que la existente utiliza códigos de configuración regional BCP 47 y UTF-8) y registre la configuración regional de origen de forma explícita para que la lógica de respaldo tenga un punto de partida definido.
- 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.
- 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.
- Vuelva a escribir, verifique y recurra: inserte los valores traducidos en la tabla de traducción con el identificador de entidad y la configuración regional correctos, compruebe automáticamente que los marcadores de posición y las marcas han sobrevivido intactos y sirva el idioma de origen para cualquier configuración regional aún 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 orientado al 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.
- Sirve en más de un puñado de locales, o espere hacerlo, y no puede seguir añadiendo una columna de idiomas por mercado.
- Añada o cambie el contenido a diario, por lo que una exportación única quedaría obsoleta antes de que llegaran las traducciones.
- Genere texto a partir de plantillas y variables (confirmaciones de pedidos, saludos personalizados, recuentos) y necesite marcadores de posición para mantener el volumen de traducciones sin cambios.
- Ejecute aplicaciones web o móviles que deben mostrar las nuevas traducciones sin un ciclo de creación o despliegue.
Cuando la localización de bases 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 usuario de la aplicación (botones, menús, mensajes de error) ya externalizada en JSON, .properties, iOS .strings, o XML de Android. La localización de los archivos de recursos es la ruta establecida para ese contenido y, al moverlo a una base de datos, se añade una capa sin añadir ningún beneficio.
- Los datos son textos web de marketing de cara al público renderizados en el servidor. Un proxy de traducción, como la Red de Entrega Global de Smartling, lo traduce en tránsito, incluido el contenido basado en bases de datos, sin tocar en absoluto el esquema.
¿Cuáles son las mejores herramientas para la localización de bases de datos y cómo las evalúas?
Las mejores herramientas de localización de bases de datos son las plataformas de traducción que pueden ingerir el contenido de las bases de datos mediante programación (como exportaciones de archivos estructurados o cadenas publicadas en una API), deduplicar el texto repetido, conservar los marcadores de posición y devolver las traducciones con la clave de la fila original. Evalúe a cualquier candidato, incluido Smartling, en función de estas preguntas.
¿Puede aceptar los formatos de exportación que produce la base de datos?
JSON, CSV y XLSX son los objetivos de serialización más comunes para la exportación de tablas. Una herramienta debería analizarlos con directivas que marquen las columnas clave, las columnas de origen y los campos que contienen HTML, en lugar de tratar cada celda como texto sin formato.
¿Puede aceptar cadenas directamente a través de una API, sin un archivo?
Las aplicaciones que escriben contenido de forma continua se benefician de publicar cadenas a la hora de escribir y de leer las traducciones a la hora de solicitarlas. La API de entrega de traducciones de Smartling es un punto final único que ingiere el contenido fuente y devuelve cualquier traducción disponible en la misma respuesta; sus API de archivos y cadenas cubren el patrón asincrónico de subir y descargar.
¿Almacena una copia de una cadena repetida?
El contenido de la base de datos es repetitivo por naturaleza. Una herramienta que ingiere una cadena una vez independientemente del número de filas o cargas útiles que contenga, 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 anteriormente sin coste nuevo; un glosario aplica los nombres de los productos y los términos no traducidos en todas las tablas. Ambos importan más para los catálogos que para el texto de marketing porque el texto del catálogo se repite.
¿Se pueden volver a escribir las traducciones con la clave de la fila de origen, con una alternativa?
La traducción devuelta debe incluir el identificador de entidad y la configuración regional a la que pertenece, y la herramienta o la integración deben devolver el texto fuente cuando aún no exista ninguna traducción para que la aplicación no muestre nunca un campo vacío.
¿La localización de datos puede mejorar el rendimiento de mi aplicación?
En el sentido de la infraestructura (almacenar datos en una región cercana a sus usuarios), sí, porque las rutas de red más cortas reducen la latencia; es una decisión de alojamiento y residencia, que abarca la soberanía de los datos frente a la residencia de los datos. La localización de bases de datos en el sentido de la traducción afecta al rendimiento de forma diferente: una tabla de traducción leída en cada solicitud añade una unión, por lo que las aplicaciones con mucho tráfico suelen almacenar en caché las traducciones o las obtienen de un paquete de traducción alojado en la CDN en lugar de ir a la base de datos por página vista.
¿Cómo localiza Smartling el contenido de las bases de datos?
Smartling localiza el contenido de la base de datos a través de tres rutas documentadas, elegidas según cómo la aplicación expone sus datos: una API de entrega de baja latencia para contenido enviado desde código, subidas estructuradas de archivos para exportaciones programadas y un proxy de traducción para sitios web basados en bases de datos que no deben modificarse 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 bloqueos que acepta el contenido fuente en el cuerpo de la solicitud (HTML, JSON, XML, JavaScript o cargas mixtas) y devuelve inmediatamente cualquier traducción disponible; si no existe, devuelve el texto original e ingiere la cadena para su traducción. La documentación de Smartling describe que la plataforma actúa como una base de datos de traducción en este modo, que almacena una copia de cada cadena independientemente del número de cargas útiles que la contenga, por lo que la descripción del producto repetida en miles de filas se traduce una vez. Algunos clientes utilizan la API de TD para generar un paquete de traducción actualizado implementado en una CDN, de modo que las aplicaciones web y móviles leen las nuevas traducciones sin necesidad de crear o implementar. La API TD es un producto de pago, requiere un proyecto de 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 analizarse como HTML. Los archivos traducidos regresan con la misma estructura para la escritura, y las mismas cadenas fluyen por la memoria de traducción y el glosario de Smartling que cualquier otro contenido.
- Red de entrega global y soporte de contenido dinámico para sitios basados en bases de datos: para las aplicaciones web, el proxy de traducción Global Delivery Network (GDN) de Smartling captura el contenido en tránsito hacia el navegador, incluido el contenido llamado desde la base de datos, e intercambia las traducciones sin ningún cambio en el esquema. El soporte de contenido dinámico, activado de forma predeterminada en los proyectos de GDN creados después de agosto de 2023, lo extiende al texto renderizado en el navegador mediante marcos de JavaScript como React, y las nuevas traducciones llegan a la página unos 20 minutos después de su publicación. Las reglas de coincidencia de patrones ocultan los valores dinámicos (números de pedido, nombres, recuentos de artículos), así que " Gracias, su número de pedido es 56783 " se almacena una vez como " Gracias, su número de pedido es {0}", que es el mecanismo que evita que el texto generado en la base de datos aumente el volumen de traducción.
La implicación práctica para el equipo que elige entre las tres: la API TD se adapta a las aplicaciones que ya tienen una pasarela de API y quieren traducciones en el momento de la solicitud; las exportaciones de archivos se adaptan a los catálogos por lotes y al contenido administrativo; y la GDN se adapta a los sitios web públicos en los que lo más rápido es dejar la base de datos en paz. 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?
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.