Database
 sql >> Base de Dados >  >> RDS >> Database

Como projetar um sistema pronto para localização


Nesta era de globalização, as empresas – incluindo desenvolvedores de software – estão sempre interessadas em expandir para novos mercados. Isso geralmente significa localizar seus produtos para diferentes áreas. Neste artigo, explicaremos algumas abordagens para projetar seu modelo de dados para localização – especificamente, para gerenciar conteúdo em vários idiomas.

O que é localização?


A localização é o processo de adaptação de um produto a vários mercados. É um fator de destaque para alcançar a máxima participação de mercado em termos de vendas de produtos. Quando a localização é feita corretamente, os usuários sentirão que o produto foi produzido para seu idioma, cultura e necessidades.

Em lugares onde o inglês não é a primeira língua comum, pesquisas provaram que os idiomas locais são muito preferidos para um produto de software. Este artigo do MediaPost contém alguns números interessantes sobre a necessidade de outros idiomas além do inglês quando se trata de vendas internacionais.

O que você pode perder quando não localiza?


Vamos considerar um exemplo infeliz de não localização. Para conveniência dos clientes, um portal de comércio eletrônico permitiu que os clientes agrupassem compras individuais em um grupo de quatro. Infelizmente, a pronúncia da palavra “quatro” em japonês soa como a palavra para “morte”. Os japoneses normalmente evitam todas as coisas associadas a esse número porque é considerado azar. Escusado será dizer que as vendas desses produtos não foram bem no mercado japonês.

Portanto, em resposta à pergunta acima, você pode perder muito se não planejar cuidadosamente o seu mercado-alvo.

Tradução de conteúdo como localização


Quando pensamos em localização, a tradução de conteúdo geralmente é o primeiro pensamento que vem à nossa mente. O segundo pensamento é “Precisamos de um modelo de banco de dados robusto e eficiente para armazenar conteúdo traduzido em vários idiomas”.

Suponha que somos solicitados a projetar um modelo de dados para um aplicativo de comércio eletrônico multilíngue. Precisaríamos armazenar campos de texto como product_name e a descrição dos produtos em vários idiomas. Também precisaríamos armazenar campos de texto em outras tabelas, como customer tabela, em todas essas línguas.

Para entender como projetar nosso modelo de dados com a tradução de conteúdo em mente, examinaremos diferentes abordagens usando essas duas tabelas. Cada uma dessas abordagens tem prós e contras. As abordagens demonstradas abaixo podem ser estendidas para outras tabelas em seu modelo de dados. Claro, a abordagem exata que você escolher será baseada em seus próprios requisitos.

Abordagem 1 – Adição de colunas de idioma separadas para cada campo pretendido


Esta é a abordagem mais simples em termos de desenvolvimento. Ele pode ser implementado adicionando uma coluna de idioma para cada campo.



Prós

  • É muito fácil de implementar.

  • Não há complexidade em escrever SQL para buscar os dados subjacentes em qualquer linguagem. Suponha que eu queira escrever uma consulta para recuperar detalhes do produto e do cliente para um pedido específico no idioma francês. O código ficaria assim:

    Selecione p.product_name_FR, p.description_FR, p.price, c.name_FR, c.address_FR, c.contact_name de order_line o, product p, customer c Onde o.product_id =p.id e o.customer_id =c .id E id =;

Contras

  • Não há escalabilidade:sempre que um novo idioma é adicionado, dezenas de colunas adicionais precisam ser adicionadas nas tabelas.
  • Pode ser demorado, especialmente se muitos campos precisarem ter vários idiomas.

  • Os desenvolvedores acabam escrevendo a consulta mostrada abaixo para gerenciar todos os idiomas existentes. Portanto, todos os SQLs em seu aplicativo devem ser alterados quando um novo idioma é introduzido. (Observação: @in_language significa o idioma atual do aplicativo; esse parâmetro vem do front-end do aplicativo, enquanto o back-end está recuperando registros.) 

    SELECT CASE @in_language QUANDO 'FR' THEN p.product_name_FR QUANDO 'DE' THEN p.product_name_DE DEFAULT THEN p.product_name_EN, p.price, CASE @in_language QUANDO 'FR' THEN c.name_FR QUANDO 'DE' THEN c .name_DE DEFAULT THEN c.name_EN, c.contact_nameFROM order_line o, product p, customer c WHERE o.product_id =p.id AND o.customer_id =c.id AND id =;

Abordagem 2 – Criando uma tabela separada para texto traduzido


Nesta abordagem, uma tabela separada é usada para armazenar o texto traduzido; no exemplo abaixo, chamamos essa tabela de translation . Ele contém uma coluna para cada idioma. Os valores que foram traduzidos de valores de campo para todos os idiomas aplicáveis ​​são armazenados como registros. Em vez de armazenar o texto traduzido real em tabelas subjacentes, armazenamos sua referência à translation tabela. Essa implementação nos permite fazer um repositório comum de texto traduzido sem fazer muitas alterações no modelo de dados existente.



Prós

  • É uma boa abordagem se a localização for implementada em um modelo de dados existente.
  • Uma única coluna adicional na translation table é a única alteração necessária quando um novo idioma é introduzido.
  • Quando o texto original é o mesmo nas tabelas, não há texto traduzido redundante. Por exemplo:suponha que um nome de cliente e um nome de produto sejam idênticos. Neste caso, apenas um registro será inserido na tabela de tradução, e o mesmo registro é referenciado tanto no customer e product tabelas.

Contras

  • Ainda requer uma mudança no modelo de dados.
  • Pode haver NULLs desnecessários na tabela. Se 1.000 campos forem necessários para apenas um idioma compatível, você acabará criando 1.000 registros e muitos NULLs.

  • A complexidade de escrever SQL aumenta à medida que o número de junções aumenta. E quando há muitos registros na translation tabela, os tempos de recuperação são mais lentos.

    Vamos escrever um SQL para a declaração do problema de gerenciamento de linguagem novamente:

    SELECT CASE @in_language QUANDO 'FR' THEN tp.text_FR QUANDO 'DE' THEN tp.text_DE DEFAULT THEN p.product_name_EN, p.price, CASE @in_language QUANDO 'FR' THEN tc.text_FR QUANDO 'DE' THEN tc .text_DE DEFAULT THEN c.name_EN, c.contact_nameFROM order_line o, product p, customer c, translation tp, translation tc ONDE o.product_id =p.id AND o.customer_id =c.id AND p.name_translation_id =tp.id AND c.name_translation_id =tc.id AND id =;


Uma variante da abordagem da tabela de tradução

Para obter um melhor desempenho quando o texto traduzido estiver sendo recuperado, podemos dividir a translation tabela em várias tabelas. Podemos agrupar os registros com base no domínio, ou seja, uma tabela para customer , outro para product , etc



Abordagem 3 - Uma tabela de tradução com linhas para cada idioma


Essa implementação é bastante semelhante à segunda abordagem, mas armazena os valores do texto traduzido em linhas em vez de colunas. Aqui, a translation O ID da tabela permanece o mesmo para um valor de campo em qualquer idioma traduzido. Uma chave primária composta {id , language_id } é armazenado na tabela de tradução e armazena o mesmo translation_id para cada campo em vários language_id .



Prós

  • Esta implementação permite que os desenvolvedores escrevam SQLs de recuperação de dados com bastante facilidade.
  • Também é fácil escrever OEM para este modelo.
  • Nenhuma alteração no modelo de dados é necessária quando você adiciona um novo idioma; basta inserir os registros para o novo idioma.
  • Não há consumo desnecessário de memória quando um conjunto de campos não é aplicável a um idioma.

  • A complexidade dos SQLs de recuperação de dados é reduzida. Veja o exemplo abaixo:

    SELECT tp.text, p.price, tc.text, c.contact_nameFROM order_line o, product p, customer c, translation tp, translation tc, language l WHERE o.product_id =p.id AND o.customer_id =c .id AND p.name_translation_id =tp.id AND c.name_translation_id =tc.id AND tp.language_id =l.id AND tc.language_id =l.id AND l.name =@in_language AND id =;

Contras

  • É necessário um número relativamente alto de junções para recuperar dados traduzidos.
  • Com o tempo, um grande número de registros pode ser potencialmente armazenado na translation tabela. Como há apenas uma tabela de tradução, todo o texto traduzido será despejado nela. Quando você tem milhões de campos a serem traduzidos e seu aplicativo oferece suporte a um grande número de idiomas, consultar uma tabela para uma tradução seria uma atividade demorada. No entanto, você pode dividir a tabela de tradução com base em idiomas ou áreas de assunto, conforme apontamos na conclusão da segunda abordagem.

E se combinarmos as abordagens 2 e 3?

Especificamente, combinaremos a variante da Abordagem 2 – dividir a translation table – com a ideia de usar linhas em uma tabela. Podemos facilmente superar a desvantagem de ter registros enormes na translation table criando várias tabelas com base em um domínio, como fizemos na variante do Approach 2. Se houver um número considerável de registros na tabela de conversão baseada em domínio, podemos dividir ainda mais as tabelas com base em campos individuais.



Abordagem nº 4 – Criando camadas de entidade para campos traduzidos e campos não traduzidos


Nesta solução, as tabelas de entidades que contêm um ou mais campos traduzidos são divididas em duas camadas:uma para campos traduzidos e outra para campos não traduzidos. Dessa forma, criamos camadas separadas para cada uma.



Prós

  • Não há necessidade de unir tabelas de tradução se apenas os campos não traduzidos estiverem em causa. Portanto, os campos não traduzidos obtêm melhor desempenho.
  • É necessário um número relativamente menor de junções para recuperar textos traduzidos.
  • É fácil escrever OEM.
  • Os SQLs para recuperar o texto traduzido são simples.
  • Esta é uma abordagem comprovada para incorporar vários idiomas entre entidades.

Para demonstrar o ponto, aqui está um exemplo de consulta que recuperará o texto traduzido:

SELECT pt.product_name, pt.description, p.priceFROM order_line o, product p, product_translation pt, language l WHERE o.product_id =p.id AND AND p.id =pt.product_non_trans_id AND pt.language_id =l. id AND l.name =@in_language AND id =;

Localização – Indo além da tradução de conteúdo


Localização não é apenas traduzir o conteúdo do seu aplicativo para outro idioma. Existem parâmetros culturais e funcionais que também precisam de atenção. Por exemplo, um valor de data é formatado como 'MM/DD/AAAA' na América do Norte, mas na maior parte da Ásia é escrito como 'DD/MM/AAAA'.

Outro exemplo tem a ver com a exibição de nomes no cabeçalho do aplicativo. Nos EUA, chamar alguém pelo primeiro nome é aceitável ou até mesmo preferido; nessa cultura, o primeiro nome do cliente é exibido no cabeçalho assim que o cliente faz login. No Japão, porém, as coisas são inversas:chamar alguém pelo primeiro nome é indelicado ou até mesmo um insulto. A localização levaria isso em consideração e evitaria o uso de nomes próprios para o público japonês do aplicativo.

Os parâmetros de localização podem precisar ser armazenados no back-end do aplicativo. Este é o caso quando você precisa projetar alguma lógica de programa em torno da localização. Provavelmente podemos categorizar todos esses parâmetros em categorias culturais e funcionais e construir o modelo de dados em torno deles.

Mais uma reflexão sobre localização


A localização é necessária quando uma marca global penetra nos mercados locais. Para localizar um aplicativo, observe o quadro geral. A localização é mais do que apenas um desempenho tecnicamente perfeito. Significa também ter domínio das culturas locais, comportamentos e até mesmo formas de pensar e viver.

O que mais pode ser feito para tornar um aplicativo localmente adaptável? Deixe-nos saber seus pensamentos nos comentários.