O cenário
Você é o proprietário de uma loja online, localizada na Polônia. A maioria de seus clientes são da Polônia e falam polonês. Mas você também quer vender seus produtos no exterior e seus clientes internacionais falam principalmente inglês. Portanto, você deseja que sua loja on-line esteja disponível em polonês e inglês . Você também espera que seus produtos vendam bem na França, então prevê que terá que preparar um francês versão da loja também (e talvez espanhol também, porque não?).
Você deseja que seus usuários possam mudar da versão polonesa
para a versão em inglês e vice-versa.
E obviamente você quer que os detalhes do produto mudem de polonês para inglês.
Como você cria um aplicativo da Web em vários idiomas?
Existem dois tipos de texto em seu aplicativo. Um é estático dados:rótulos de botão, cabeçalhos de tabela, gráficos (que geralmente contêm texto). O outro é o definido pelo usuário dados, como nome do produto, preço do produto, descrição do produto e assim por diante. Os dados são normalmente retirados do banco de dados.
Os dados estáticos são o que você gostaria de escrever como uma string literal em sua saída. Os dados definidos pelo usuário são dados que você obtém de seu banco de dados.
Não vou falar sobre dados estáticos hoje. Qualquer estrutura da Web razoável lidará com a internacionalização dos dados estáticos. Consulte a documentação de sua estrutura de aplicativo da Web para obter detalhes. Procure palavras-chave como “internacionalização”, “i18n”, “localização” ou “traduções”.
Hoje falarei sobre qual estrutura de banco de dados costumamos usar aqui no e-point para lidar com dados em vários idiomas. No banco de dados da sua loja, você provavelmente tem o product tabela que armazena informações sobre todos os produtos disponíveis na loja.
O product tabela tem colunas como name , description , e price . Ao traduzir as informações do produto para outros idiomas, você só precisa traduzir algumas colunas. Aqui você traduziria apenas o name e description , mas o price não muda quando você muda de idioma.
Quando adicionamos suporte para vários idiomas, adicionamos uma nova tabela chamada language_version , que armazena todas as versões de idioma disponíveis na loja. Geralmente adicionamos uma coluna chamada code e um chamado is_default (com uma restrição apropriada:apenas uma versão pode ser o padrão).
Em seguida, dividimos o product tabela em duas tabelas:tabela product e tabela product_lv . Para cada produto, haverá uma linha no product tabela e várias linhas no product_lv tabela; uma linha para cada versão de idioma. A tabela product_lv contém apenas colunas que precisam ser traduzidas:name e description . As colunas que são independentes de idioma (como price , porque você vende pelo mesmo preço, não importa se seu cliente fala inglês ou polonês) permaneça na tabela product .
Fazemos o mesmo para cada tabela que contém dados traduzidos. Os dados traduzidos vão para o table_lv tabela, os dados independentes de idioma permanecem na tabela principal.
Prós e contras
Uma desvantagem óbvia é que todas as operações de criação, recuperação, atualização ou exclusão (CRUD) ficam um pouco mais complicadas. Você sempre tem que se juntar com uma tabela de versão de idioma adicional para obter a descrição correta.
A vantagem desse design é que você não precisa alterar o esquema do banco de dados ao adicionar uma nova versão de idioma. Não estou dizendo que adicionar uma nova versão de idioma é fácil. Afinal, você tem que traduzir TODAS as descrições dos produtos. Este é um desafio organizacional, mas do ponto de vista do banco de dados é bastante fácil:muitas inserções.
Como você projeta seus bancos de dados multilíngues?
