Como fazer um site multilingue

Algum corpo pode me dizer como fazer um site multilíngüe dynamic em PHP e MySQL? Não tenho idéia sobre isso. Procurei no Google e não encontrei nenhuma boa solução.

Alguém pode me fornecer um guia passo a passo? Se possível, faça uma demonstração para um site multilíngüe. Ou me encaminhe para qualquer link onde ele explica os detalhes sobre isso.

Resposta curta: não há uma resposta curta, pois há muitas variables ​​a serem consideradas e muito trabalho a ser feito. Assim…

Resposta longa: vou desmoronar o máximo possível, mas não há uma resposta “boa para todos” para uma pergunta tão ampla quanto a sua.

Primeiro, variables ​​da tarefa em questão:

  1. Lista de idiomas: seu site estará em um conjunto predefinido de idiomas, ou será variado / heterogêneo? Por exemplo, um site pode ser inteiramente bilingue em dois idiomas bem definidos (ou, para colocar outro exemplo, eu dirijo um site inglês / catalão / espanhol); ou diferentes seções podem estar disponíveis em diferentes conjuntos de idiomas (para um exemplo, veja os sites do MS: eles são principalmente homogêneos, mas coisas como blogs, artigos da KB e alguns documentos estão disponíveis apenas em um subconjunto dos idiomas supostamente suportados).

  2. Origem das traduções: o conteúdo é fornecido em cada idioma relevante por você ou algum colaborador? Ou algumas versões são executadas através de software de tradução de um único idioma “base”? A primeira abordagem leva muito trabalho extra para produzir os conteúdos, mas produz resultados de maior qualidade do que o segundo.

  3. Idiomas próprios: uma vez que você tenha 1) e 2), você precisará estar ciente de quais idiomas você está trabalhando. Note-se que, no caso de você include dialetos (ex: inglês dos EUA + inglês do Reino Unido ou espanhol da Argentina + espanhol espanhol), você pode encontrar alguns problemas de “conteúdo duplicado” com os mecanismos de pesquisa, mas os detalhes sobre isso são muito fora do tópico aqui (apenas mencionando que você está ciente dos problemas potenciais).

  4. Você está segmentando idiomas em resumo (por exemplo, meu site oferece os três idiomas sem cuidar de onde o visitante é: é o que eu tenho, então escolha o que você prefere); ou melhor, segmentar diferentes regiões / países? No caso posterior, as coisas podem se tornar mais complexas, pois talvez seja necessário se preocupar com outras coisas além de idiomas (como por exemplo, horários, moedas ou convenções de formato de data e hora, para citar alguns), mas você obtém o benefício de poder usar TLDs específicos do país.

Depois de ter o acima definido bem, vamos começar a trabalhar. Estas são as tarefas mais proeminentes que você precisa fazer para lidar com:

  1. Detecção de idioma: a abordagem mais razoável é usar um parâmetro GET (algo como? Lang = en-us no URL). Além disso, você pode usar alguma geolocalização de cookies e / ou IP para recuar quando um URL sem argumento de idioma for solicitado. Além disso, se você tem os meios, considere o tópico de embelezamento de URL (o que parece melhor: example.com/index.php?lang=en-us ou example.com/en-us/home ?). Pessoalmente, adoro o poder que o ModRewrite concede ao meu arquivo .htaccess, mas isso só funcionará em servidores com Apache.

  2. Gerenciamento de conteúdo: independentemente de você estar obtendo conteúdo de um database (como o conteúdo do artigo), include arquivos (típicos para navegação, menus, headers no site, etc.) ou qualquer outro meio, você precisará de alguma maneira para separar cada versão (idioma) do conteúdo. Aqui estão alguns exemplos de como isso pode ser feito:

    • Para o conteúdo de DB, o meu melhor conselho é criar um padrão de nomeação de campo sólido e cumpri-lo. Por exemplo, eu _es _en , _es ou _ca a todos os campos dependentes do idioma do meu DB. Desta forma, eu posso acessar o conteúdo certo com expressões como $row["title_$lang"] .
    • Para include arquivos, novamente uma convenção de nomeação de arquivo é a abordagem mais segura. No meu caso, eu tenho nomes de arquivos que terminam com .en.php , .ca.htm , etc. As minhas chamadas de inclusão, em seguida, parecem include("some-filename.$lang.php) .
    • De vez em quando, você estará cuspindo pequenos pedaços de texto diretamente do seu código PHP (por exemplo, ao rotular os títulos de uma tabela). Você pode usar um arquivo de inclusão por idioma que define uma matriz de “pedaços” com as mesmas chaves, ou uma tabela de database, como a sugerida por Geert. A abordagem anterior leva menos trabalho para desenvolver, o último deve levar menos trabalho para manter (especialmente se você não está trabalhando sozinho).
  3. Selecção de idioma: bastante essencial, você deve fornecer aos seus usuários uma maneira de escolher seu próprio idioma, além de ajustar os argumentos GET no próprio URL. Para poucas línguas, as “bandeiras” geralmente funcionam bem, pois elas podem ser compreendidas, mesmo que a página tenha retornado inicialmente a um idioma que o usuário não conheça. Para mais idiomas, um menu suspenso parece mais eficiente (em termos de espaço para exibição), mas você deve ter certeza de adicionar algumas dicas visuais (ou seja, não-textuais). Alguns sites o obrigam a escolher um idioma ao entrar, e apenas tem links para a página inicial em cada idioma. Pessoalmente, eu tenho as minhas três bandeiras em destaque no menu do meu site, cada uma apontando para o endereço atual com apenas o argumento do idioma alterado. Um código como este pode funcionar bastante bem:


 function translatedURI($new_lang) { return str_replace("lang=$lang", "lang=$new_lang", "http://" . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"]; } 

  1. Correção do CMS: se o seu site (ou parte dele) estiver usando algum tipo de CMS, fórum de discussão, etc., as coisas podem ficar bastante confusas. Falando da minha própria experiência, eu tenho um fórum phpBB no meu site dividido em três categorias principais (um por idioma), de forma que eles se parecem com três fóruns independentes (mas os usuários só precisam fazer o login / registrar em um deles para Obter access a todas as línguas, uma vez que são apenas categorias do mesmo quadro). Os ajustes que eu tive que fazer para que isso funcione suavemente ameaçam os últimos remanescentes de sanidade que eu ainda mantenho: S. Para esses casos, aconselho pesquisar os documentos e resources de suporte do software específico que você está usando.

Bem, é tudo o que posso sair por agora. Eu acho que você deveria ter o suficiente para puxar as mangas e começar a trabalhar. Então, se você acertar algum muro em seu caminho, volte com perguntas específicas e estou confiante de que você obterá respostas mais específicas.

Espero que isto ajude.

Dê uma olhada nessas perguntas:

  • Como você transformaria um aplicativo web preexistente em um multilingue?
  • Considerações de design para internacionalização

E dê uma olhada na class Zend_Translate do Zend Framework.

A solução que eu sempre uso é criar uma tabela de database, com todas as mensagens possíveis. Para cada mensagem, uso um código (abreviatura) para procurar. Então, por exemplo:

 lang id message en login Login en lostpass Lost your password? de login Anmelden de lostpass Paswort vergessen? nl login Aanmelden nl lostpass Wachtwoord vergeten? 

etc. Procurando as traduções geralmente é suficientemente rápido usando uma consulta MySQL, mas também pode colocar todas as mensagens em uma matriz e carregá-la na memory quando o script é carregado. Os usuários sempre devem ser capazes de configurar o idioma que preferem, não dependem de forma cega no header do idioma definido pelo navegador da Web.

Você pode usar o idioma mais fácil PHP Multi Language Class – LangQuery

Você pode salvar seus dados de idioma em arquivos .ini do que apenas chamá-lo por

 include("LangQuery.php"); $L=new LangQuery(); // Write Hello World echo($L('hello_world')); // Write Hello World Easier - In-line Echo Feature // You don't have to write echo. Just add '>' $L('>hello_world'); // Use in Strings echo("Hello Universe. {$L('hello_world')} Hello Europe"); // Write my age with parameter $L(">my_age",25); // Write my name and age with parameters $L(">my_name_age","Recep",25); 

Agora estou projetando um CMS muito pequeno que deve ser multilíngue.

Uma das características que mais me preocupa é que o cliente pode espontaneamente decidir adicionar ou remover um idioma.

Por esse motivo, não estou visando o design de adicionar sufixos às tabelas do database, não posso (e quero não) modificar os nomes das tabelas ou acessá-los usando nomes dynamics, nem adicionar ou remover campos cada vez que um idioma é definido ou removido .

Eu também não usaria arquivos, só porque eu gosto de bancos de dados e eles são fáceis de manter.

E, por fim, penso em dois tipos de tradução:

  1. O texto da web.
  2. O texto do conteúdo.

Portanto, meu projeto visa:

  • linguajes Uma tabela com as línguas definidas.
  • traduções Uma única tabela que terá todas as mensagens, da seguinte forma:
    • [pk] table_name o nome da tabela cujo conteúdo será traduzido.
    • [pk] field_name o nome do campo cujo conteúdo será traduzido.
    • [pk] row_id o identificador de linha para o item que será traduzido.
    • [pk] idioma o idioma que o texto é traduzido.
    • Texto do texto traduzido.

Isso significa que as tabelas que os campos terão conteúdo em um cenário de linguagem única, agora terão seu conteúdo vazio, porque sempre estará na tabela de traduções.

Isso aumentará a complexidade sql querys, mas isso me permite desenvolver ferramentas para manter as traduções de forma fácil. Além disso, a complexidade do sql só existirá uma vez, apenas ao implementar a solução. Se essa implementação for devidamente projetada, a manutenção / extensibilidade do site não precisa ser um grande problema.

Editar :

Depois de uma conversa com os amigos do desenvolvedor, acho que a solução que eu aproximei aqui tem muita carga em uma única mesa.

Outra abordagem que vou estudar a partir de agora é criar uma tabela extra para cada “tabela traduzível” da seguinte maneira:

  • any_translatable_table: a tabela que precisa traduzir qualquer um dos seus campos
  • any_translatable_table_translations: a tabela onde as traduções serão armazenadas.
    • [pk] field_name o nome do campo cujo conteúdo será traduzido.
    • [pk] row_id o identificador de linha para o item que será traduzido.
    • [pk] idioma o idioma que o texto é traduzido.
    • Texto do texto traduzido.

Este esquema herda os conceitos do primeiro, mas separa o conteúdo por tabela. Esta solução alternativa pode aumentar o desempenho e isolar os problemas (como problemas de índices).

A tabela de tradução extra por “tabela traduzível” será criada ao mesmo tempo que a original.

E sobre o sql querys, a complexidade ainda é a mesma: a primeira abordagem precisa do nome da tabela para pesquisar na tabela de traduções, mas o segundo apenas adiciona o sufixo “_translations” no nome da tabela.