How can I effectively localize a database for different regions?

Database localization is the process of translating and adapting content stored in database fields, such as product names, descriptions, UI labels, and categories, so one application can serve each locale from the same data model. It works best with a locale-keyed translation table, a repeatable export or API hand-off to a translation platform, and locale formatting applied at render time rather than stored in the database.

Como localizar um banco de dados e qual a diferença entre isso e a localização de dados?

A localização de banco de dados é o processo de traduzir e adaptar o conteúdo armazenado nos campos do banco de dados — nomes de produtos, descrições, rótulos da interface do usuário, categorias, artigos de ajuda — para que um único aplicativo possa atender a todos os idiomas a partir do mesmo modelo de dados. A localização de dados é um conceito diferente com um nome semelhante: uma exigência legal para que determinados dados sejam armazenados e, por vezes, processados dentro das fronteiras de um país específico. Os dois se sobrepõem apenas no vocabulário. Um deles é um problema de fluxo de trabalho de tradução resolvido com o design de esquemas, extração de conteúdo e uma plataforma de tradução; o outro é uma decisão de conformidade e hospedagem que define onde os servidores estão localizados, e não em que idioma as linhas estão.

Quais desafios posso enfrentar ao localizar dados para vários países?

O principal desafio da localização de conteúdo de banco de dados para vários países é que uma linha de banco de dados é um dado, não uma string: ela não possui um marcador integrado que indique quais colunas são traduzíveis, quais são identificadores e quais são variáveis que devem ser mantidas intactas. Essa lacuna estrutural gera cinco problemas recorrentes.

Não há separação entre texto traduzível e dados — uma tabela products mistura um SKU, um preço, um ID de categoria e uma descrição em uma única linha. Um arquivo de recursos, como um JSON ou um arquivo .properties. Os arquivos separam as chaves das strings por padrão; uma exportação de banco de dados não faz isso, portanto, todo esforço de localização começa decidindo, coluna por coluna, o que é conteúdo e o que são dados.
Valores dinâmicos incorporados no texto — mensagens como "Obrigado, o número do seu pedido é 56783" ou "Você tem 4 itens no seu carrinho" são geradas combinando um modelo com um valor. Enviado para tradução tal como está, cada variante é uma nova string; as regras de correspondência de padrões do Smartling existem especificamente para que o texto estático seja traduzido uma vez e o número passe como um marcador de posição, como {0}.
Decisões de esquema que não são escaláveis — adicionar uma coluna description_fr, description_de, description_ja por idioma funciona para três localidades, mas falha com vinte. Uma tabela de tradução separada, indexada por ID da entidade e código de localidade, escala linearmente, mas adaptá-la a um esquema em produção é uma migração, não uma configuração.
Conteúdo que muda continuamente — um catálogo, uma central de ajuda ou uma tabela de conteúdo gerado pelo usuário — é atualizado diariamente. Uma operação única de exportação e importação ignora tudo o que foi adicionado após a exportação, portanto, o fluxo de trabalho precisa detectar as alterações e encaminhar apenas as linhas novas ou modificadas para tradução.
Tipos de conteúdo mistos e ausência de contexto visual — uma única coluna de texto pode conter texto simples em uma linha e HTML na seguinte, e os tradutores que trabalham a partir de uma exportação não veem nenhuma parte da interface onde a string aparece. Ambos geram erros de qualidade: marcação incorreta e traduções que não se adequam ao botão, rótulo ou campo para o qual foram escritas.

Existe um desafio separado sob a mesma frase. Se "localizar dados para vários países" significa manter dados pessoais ou regulamentados dentro das fronteiras de cada país — o requisito de conformidade sob leis como a PIPL da China ou a 242-FZ da Rússia — isso é residência de dados, não tradução, e os requisitos são abordados integralmente em soberania de dados versus residência de dados versus localização de dados.

Como posso localizar efetivamente um banco de dados para diferentes regiões?

A localização eficaz de bancos de dados divide o problema em cinco camadas, cada uma com um responsável diferente: esquema, extração, tradução, entrega e formatação. As equipes que tentam resolver todos os cinco problemas dentro do banco de dados — armazenando datas formatadas, codificando colunas de idioma diretamente, traduzindo manualmente em uma planilha — acabam com um esquema que não permite adicionar uma localidade sem uma migração.

Camada de esquema: uma tabela de tradução indexada por localidade — armazena o texto traduzível em uma tabela indexada pelo ID da entidade mais um código de localidade usando as tags IETF BCP 47 (en-US, fr-CA, zh-Hans) e mantém a linha do idioma de origem como alternativa. Defina o conjunto de caracteres para UTF-8 (utf8mb4 no MySQL, UTF8 no PostgreSQL) para que scripts CJK, caracteres acentuados e emojis sejam preservados durante o armazenamento e a exportação. Isso transforma "adicionar japonês" de uma alteração de esquema em uma inserção.
Camada de extração: uma transferência repetível, não uma exportação única — decida como as linhas traduzíveis chegam à plataforma de tradução. Os dois padrões são uma exportação agendada para um arquivo estruturado (JSON, CSV ou XLSX, todos aceitos pelo Smartling com diretivas em nível de arquivo de até 10 MB por arquivo) ou um envio direto via API das strings de origem. De qualquer forma, a transferência deve associar cada string ao seu ID de entidade e localidade, para que o valor traduzido possa ser gravado de volta na linha correta sem necessidade de correspondência manual.
Camada de tradução: memória, terminologia e marcadores de posição — encaminhar strings por meio de uma memória de tradução para que uma descrição que aparece em 400 linhas de produtos seja traduzida apenas uma vez; aplicar um glossário para nomes de produtos e termos que não devem ser traduzidos; e mascarar valores dinâmicos como marcadores de posição para que os tradutores vejam Welcome, {First Name} em vez de dez mil variantes personalizadas. Esta camada é onde o custo é controlado; a camada de esquema apenas determina se o custo pode ser controlado.
Camada de entrega: write-back com fallback — as linhas traduzidas retornam à tabela de tradução e o aplicativo lê a localidade solicitada com uma cadeia de fallback (fr-CA → fr → en) para tudo o que ainda não foi traduzido. Para aplicações que não podem esperar por um ciclo de processamento em lote, uma API de entrega de baixa latência que retorna a tradução sob demanda, ou o texto original quando este ainda não existe, substitui completamente a etapa de gravação de retorno.
Camada de formatação: regras de localidade no momento da renderização, nunca na linha — datas, moedas, separadores de números e formas plurais são funções da localidade, não do conteúdo, e pertencem à camada de apresentação usando dados Unicode CLDR por meio de uma biblioteca como a ICU. Armazenando "€1.234,56" Uma string em um banco de dados fixa o formato de uma localidade em todos os leitores daquela linha.

Localização de banco de dados: principais dados da documentação pública da Smartling

Figura	Valor	Por que isso é importante para o conteúdo do banco de dados?
Tipos de conteúdo aceitos pela API de Entrega de Tradução da Smartling	HTML, JSON, XML, JavaScript, and mixed payloads (JSON+HTML, XML+HTML)	Uma exportação de banco de dados serializada em JSON pode ser enviada diretamente, incluindo linhas cujos campos de texto contenham HTML.
Cópias de uma string armazenadas pela API Translation Delivery, independentemente de quantas cargas úteis a contenham.	1	Uma descrição repetida em milhares de linhas é processada e traduzida uma única vez, e cada linha recebe a mesma tradução.
Tamanho máximo de arquivo para uploads em JSON, CSV, XML, XLIFF e XLSX para o Smartling.	10 MB por arquivo	Exportações de tabelas grandes precisam ser divididas por tabela, categoria ou intervalo de datas de modificação, em vez de serem exportadas como um único arquivo.
Chegou a hora de uma nova tradução publicada ser enviada para o arquivo de tradução do Suporte a Conteúdo Dinâmico.	Até 20 minutos	Define a expectativa de rapidez com que uma página da web traduzida e baseada em banco de dados é atualizada sem a necessidade de implantação.
Projetos GDN com suporte a conteúdo dinâmico ativado por padrão.	Todos os projetos criados após agosto de 2023	Projetos GDN mais antigos que renderizam conteúdo de banco de dados por meio de frameworks JavaScript precisam de um plano de migração para obter a mesma cobertura.
Período de inatividade após o qual uma regra de correspondência de padrões é desativada automaticamente.	6 meses sem uma nova string correspondente	Regras de espaço reservado para números de pedidos, nomes e contagens precisam ser revisadas periodicamente em locais com baixo tráfego.

Como é um fluxo de trabalho de localização de banco de dados passo a passo?

Um fluxo de trabalho de localização de banco de dados que sobrevive a mudanças contínuas de conteúdo funciona como um ciclo de cinco etapas, em vez de uma migração única.

Inventariar e classificar colunas — listar todas as tabelas com texto visível ao usuário e marcar cada coluna como conteúdo traduzível, identificador ou variável. As descrições dos produtos e os nomes das categorias são conteúdo; SKUs, slugs e chaves estrangeiras são identificadores; preços, quantidades e datas são variáveis a serem formatadas no momento da renderização, não traduzidas.
Normalize o esquema e a codificação — mova as colunas traduzíveis para uma tabela de tradução com chave de localidade (ou confirme se a existente usa códigos de localidade BCP 47 e UTF-8) e registre explicitamente a localidade de origem para que a lógica de fallback tenha um ponto de partida definido.
Extrair linhas alteradas de acordo com um agendamento ou no momento da gravação — consultar linhas criadas ou modificadas desde a última execução e serializá-las como JSON (ou CSV/XLSX) indexadas pelo ID da entidade, ou enviá-las para uma API de entrega no momento em que forem gravadas. Mascare os valores dinâmicos como marcadores de posição antes que o texto saia do banco de dados.
Traduza com memória, glossário e revisão — primeiro, passe as sequências extraídas pela memória de tradução para que o texto repetido não represente um custo adicional; em seguida, aplique o glossário aos termos de produto e marca; e, por fim, encaminhe o restante para tradução automática, revisão humana ou ambas, dependendo da visibilidade do conteúdo.
Escreva de volta, verifique e use como alternativa — insira os valores traduzidos na tabela de tradução com o ID da entidade e a localidade corretos, execute uma verificação automática para garantir que os espaços reservados e a marcação tenham permanecido intactos e forneça o idioma de origem para qualquer localidade ainda em andamento, em vez de um campo vazio.

Um fluxo de trabalho dedicado à localização de banco de dados é ideal para equipes que...

Armazene textos voltados para o usuário — catálogos, listas, conteúdo de ajuda, notificações — em tabelas de banco de dados, em vez de em arquivos de recursos ou em um CMS com seu próprio conector de tradução.
Atender a mais do que um punhado de localidades, ou pelo menos esperar fazê-lo, não é viável continuar adicionando uma coluna de idioma para cada mercado.
O conteúdo é adicionado ou alterado diariamente, portanto, uma exportação única ficaria desatualizada antes que as traduções fossem concluídas.
Gere texto a partir de modelos com variáveis (confirmações de pedidos, saudações personalizadas, contagens) e utilize marcadores de posição para manter o volume de traduções constante.
Execute aplicativos web ou móveis que precisam exibir novas traduções sem um ciclo de compilação ou implantação.

Quando a localização do banco de dados pode não ser a prioridade correta

O requisito é a localização de dados no sentido jurídico — manter dados pessoais ou regulamentados dentro das fronteiras de um país. Essa é uma decisão relacionada à hospedagem, ao mecanismo de transferência e à governança do fornecedor, abordada no tópico soberania de dados versus residência de dados, e nenhum fluxo de trabalho de tradução a altera.
O texto traduzível reside em um CMS ou plataforma de comércio eletrônico com um conector de tradução nativo (Contentful, Salesforce Commerce Cloud e similares). A tradução feita através do conector preserva o modelo de conteúdo da plataforma; a exportação do banco de dados subjacente o ignora.
O texto é a interface do usuário do aplicativo — botões, menus, mensagens de erro — já externalizada em JSON, .properties, iOS .strings, ou XML do Android. A localização de arquivos de recursos é o caminho estabelecido para esse conteúdo, e movê-lo para um banco de dados adiciona uma camada sem trazer benefícios.
Os dados são textos de marketing para a web voltados para o público, renderizados no servidor. Um serviço de tradução proxy, como o Global Delivery Network da Smartling, traduz o conteúdo em trânsito, incluindo conteúdo baseado em banco de dados, sem alterar o esquema original.

Quais são as melhores ferramentas para localização de banco de dados e como você as avalia?

As melhores ferramentas para localização de bancos de dados são plataformas de tradução que podem ingerir conteúdo do banco de dados programaticamente — como exportações de arquivos estruturados ou como strings enviadas por meio de uma API —, remover textos repetidos, preservar marcadores de posição e retornar traduções vinculadas à linha original. Avalie qualquer candidato, incluindo o Smartling, com base nessas perguntas.

É possível aceitar os formatos de exportação gerados pelo banco de dados?
JSON, CSV e XLSX são os formatos de serialização mais comuns para exportação de tabelas. Uma ferramenta deve analisá-los com diretivas que marquem colunas-chave, colunas de origem e campos contendo HTML, em vez de tratar cada célula como texto simples.

É possível receber strings diretamente por meio de uma API, sem um arquivo?
Aplicações que escrevem conteúdo continuamente se beneficiam ao enviar as strings no momento da escrita e ao ler as traduções no momento da solicitação. A API de Entrega de Traduções da Smartling é um endpoint único que recebe o conteúdo original e retorna qualquer tradução disponível na mesma resposta; suas APIs de Arquivos e Strings abrangem o padrão assíncrono de upload e posterior download.

Armazena uma única cópia de uma sequência repetida?
O conteúdo do banco de dados é repetitivo por natureza. Uma ferramenta que processa uma string apenas uma vez, independentemente do número de linhas ou payloads que a contenham, mantém o volume de tradução atrelado ao texto único, e não à contagem de linhas.

Como ele lida com valores dinâmicos dentro do texto?
Procure por suporte de marcador de posição e regras de correspondência de padrões que mascaram números de pedidos, nomes e contagens para que "Página 3 de 10" seja traduzido uma vez como "Página {0} de {1}". Sem isso, cada variante é faturada como uma nova string.

Aplica automaticamente memória de tradução e glossário?
Uma memória de tradução retorna segmentos traduzidos anteriormente sem custo adicional; um glossário impõe nomes de produtos e termos que não devem ser traduzidos em todas as tabelas. Ambos são mais importantes para catálogos do que para textos de marketing, porque o texto do catálogo se repete.

É possível gravar as traduções de volta, referenciando a linha de origem, com uma opção de fallback?
A tradução retornada deve conter o ID da entidade e a localidade à qual pertence, e a ferramenta ou integração deve retornar o texto original quando ainda não houver tradução, para que o aplicativo nunca exiba um campo vazio.

A localização de dados pode melhorar o desempenho da minha aplicação?
No sentido de infraestrutura — armazenar dados em uma região próxima aos seus usuários — sim, porque caminhos de rede mais curtos reduzem a latência; essa é uma decisão de hospedagem e residência, abordada em soberania de dados versus residência de dados. A localização de banco de dados, no sentido de tradução, afeta o desempenho de maneira diferente: uma tabela de tradução lida a cada solicitação adiciona uma junção, portanto, aplicativos com alto tráfego normalmente armazenam as traduções em cache ou as buscam em um pacote de tradução hospedado em uma CDN, em vez de acessar o banco de dados a cada visualização de página.

Como a Smartling localiza o conteúdo do banco de dados?

A Smartling localiza o conteúdo do banco de dados por meio de três caminhos documentados, escolhidos de acordo com a forma como o aplicativo expõe seus dados: uma API de entrega de baixa latência para conteúdo enviado pelo código, uploads de arquivos estruturados para exportações agendadas e um proxy de tradução para sites baseados em banco de dados que não devem ser modificados.

API de Entrega de Tradução para conteúdo publicado a partir do aplicativo — A API de Entrega de Tradução (TD) da Smartling é um endpoint de alta disponibilidade e não bloqueante que aceita conteúdo de origem no corpo da solicitação — HTML, JSON, XML, JavaScript ou payloads mistos — e retorna imediatamente quaisquer traduções disponíveis; quando nenhuma existe, retorna o texto de origem e o utiliza para tradução. A documentação da Smartling descreve a plataforma atuando como um banco de dados de tradução nesse modo, armazenando uma cópia de cada string, independentemente de quantas cargas úteis a contenham; assim, uma descrição de produto repetida em milhares de linhas é traduzida apenas uma vez. Alguns clientes usam a API da TD para gerar um pacote de tradução atualizado e implantá-lo em uma CDN, permitindo que aplicativos móveis e da web leiam as novas traduções sem a necessidade de compilação ou implantação. A API TD é um produto pago, requer um projeto GDN para sua configuração e oferece suporte a namespaces, variantes, espaços reservados e contexto visual.
API de arquivos e diretivas para exportações agendadas — para equipes que exportam tabelas de forma programada, o Smartling aceita arquivos JSON, CSV, XLSX e XML de até 10 MB cada, com diretivas em nível de arquivo que identificam colunas-chave, colunas de origem, instruções de tradução e campos que devem ser analisados como HTML. Os arquivos traduzidos são retornados na mesma estrutura para gravação, e as mesmas strings percorrem a memória de tradução e o glossário do Smartling como qualquer outro conteúdo.
Suporte a Rede de Distribuição Global e Conteúdo Dinâmico para sites baseados em banco de dados — para aplicações web, o proxy de tradução da Rede de Distribuição Global (GDN) da Smartling captura o conteúdo em trânsito para o navegador, incluindo o conteúdo buscado no banco de dados, e insere as traduções sem qualquer alteração no esquema. O suporte a conteúdo dinâmico, ativado por padrão em projetos da Rede de Display do Google (GDN) criados após agosto de 2023, estende essa funcionalidade ao texto renderizado no navegador por frameworks JavaScript como o React, e as novas traduções chegam à página em cerca de 20 minutos após a publicação. As regras de correspondência de padrões mascaram valores dinâmicos — números de pedidos, nomes, contagens de itens — então "Obrigado, o número do seu pedido é 56783" é armazenado uma vez como "Obrigado, o número do seu pedido é {0}", que é o mecanismo que impede que o texto gerado pelo banco de dados aumente o volume de tradução.

A implicação prática para uma equipe que precisa escolher entre as três opções é a seguinte: a API TD é adequada para aplicativos que já possuem um gateway de API e desejam traduções no momento da solicitação; as exportações de arquivos são adequadas para catálogos em lote e conteúdo de back-office; e a GDN é adequada para sites públicos onde o caminho mais rápido é deixar o banco de dados intacto. Os três escrevem na mesma memória de tradução, portanto, um termo traduzido para o site é reutilizado quando a mesma string chega de uma exportação do banco de dados.