Estou lutando com essa questão há alguns meses, mas não estava em uma situação em que precisava explorar todas as opções possíveis antes. No momento, sinto que é hora de conhecer as possibilidades e criar minha própria preferência pessoal para usar nos meus próximos projetos.
Deixe-me primeiro esboçar a situação que estou procurando
Estou prestes a atualizar / reconstruir um sistema de gerenciamento de conteúdo que já uso há bastante tempo. No entanto, sinto que a linguagem multilíngue é uma grande melhoria para este sistema. Antes eu não usava nenhuma estrutura, mas vou usar o Laraval4 para o próximo projeto. O Laravel parece ser a melhor escolha de uma maneira mais limpa de codificar PHP. Sidenote: Laraval4 should be no factor in your answer
. Estou procurando maneiras gerais de tradução que sejam independentes de plataforma / estrutura.
O que deve ser traduzido
Como o sistema que estou procurando precisa ser o mais amigável possível, o método de gerenciamento da tradução deve estar dentro do CMS. Não deve haver necessidade de iniciar uma conexão FTP para modificar arquivos de tradução ou quaisquer modelos analisados em html / php.
Além disso, estou procurando a maneira mais fácil de traduzir várias tabelas de banco de dados, talvez sem a necessidade de criar tabelas adicionais.
O que eu vim comigo mesmo
Como eu tenho procurado, lendo e experimentando as coisas já. Existem algumas opções que tenho. Mas ainda não sinto que cheguei a um método de melhores práticas para o que realmente estou procurando. No momento, é isso que eu criei, mas esse método também tem efeitos colaterais.
- Modelos Analisados em PHP: o sistema de modelos deve ser analisado pelo PHP. Dessa forma, sou capaz de inserir os parâmetros traduzidos no HTML sem precisar abrir os modelos e modificá-los. Além disso, os modelos analisados pelo PHP me dão a capacidade de ter 1 modelo para o site completo, em vez de ter uma subpasta para cada idioma (que eu já tinha antes). O método para atingir esse objetivo pode ser Smarty, TemplatePower, Laravel's Blade ou qualquer outro analisador de modelos. Como eu disse, isso deve ser independente da solução escrita.
- Orientado a banco de dados : talvez eu não precise mencionar isso novamente. Mas a solução deve ser orientada por banco de dados. O CMS tem como objetivo ser orientado a objetos e MVC, então eu precisaria pensar em uma estrutura de dados lógica para as strings. Como meus modelos seria estruturada: templates / Controller / view.php talvez esta estrutura faria mais sentido:
Controller.View.parameter
. A tabela do banco de dados teria esses campos por muito tempo com umvalue
campo. Dentro dos modelos, poderíamos usar algum método de classificação comoecho __('Controller.View.welcome', array('name', 'Joshua'))
e o parâmetro contémWelcome, :name
. Assim sendo o resultadoWelcome, Joshua
. Essa parece ser uma boa maneira de fazer isso, porque os parâmetros como: name são fáceis de entender pelo editor. - Baixa carga de banco de dados : é claro que o sistema acima causaria cargas de banco de dados se essas cadeias estivessem sendo carregadas em movimento. Portanto, eu precisaria de um sistema de cache que renderize novamente os arquivos de idioma assim que forem editados / salvos no ambiente de administração. Como os arquivos são gerados, também é necessário um bom layout do sistema de arquivos. Acho que podemos ir com
languages/en_EN/Controller/View.php
ou .ini, o que melhor lhe convier. Talvez um .ini seja analisado mais rapidamente no final. Isso deve conter os dados no arquivoformat parameter=value;
. Eu acho que essa é a melhor maneira de fazer isso, pois cada View renderizada pode incluir seu próprio arquivo de idioma, se existir. Os parâmetros de idioma devem ser carregados em uma visualização específica e não em um escopo global para impedir que os parâmetros se substituam. - Tradução da tabela de banco de dados : é com isso que estou mais preocupado. Estou procurando uma maneira de criar traduções de Notícias / Páginas / etc. o mais rápido possível. Ter duas tabelas para cada módulo (por exemplo
News
eNews_translations
) é uma opção, mas parece muito trabalho para obter um bom sistema. Uma das coisas que eu vim com é baseado em umdata versioning
sistema de I escreveu: existe um nome de tabela de banco de dadosTranslations
, esta tabela tem uma combinação única delanguage
,tablename
eprimarykey
. Por exemplo: en_En / News / 1 (referindo-se à versão em inglês do item de Notícias com ID = 1). Mas existem duas grandes desvantagens nesse método: primeiro, essa tabela tende a ficar bastante longa com muitos dados no banco de dados e, em segundo lugar, seria um trabalho muito bom usar essa configuração para pesquisar na tabela. Por exemplo, pesquisar a lesma de SEO do item seria uma pesquisa de texto completo, o que é bastante idiota. Mas, por outro lado: é uma maneira rápida de criar conteúdo traduzível em todas as tabelas muito rapidamente, mas não acredito que esse profissional supere os contras. - Trabalho de front-end : também o front-end precisaria de algumas reflexões. É claro que armazenaríamos os idiomas disponíveis em um banco de dados e (de) ativamos os que precisamos. Dessa forma, o script pode gerar uma lista suspensa para selecionar um idioma e o back-end pode decidir automaticamente quais traduções podem ser feitas usando o CMS. O idioma escolhido (por exemplo, en_EN) seria usado ao obter o arquivo de idioma para uma visualização ou obter a tradução correta para um item de conteúdo no site.
Então, lá estão eles. Minhas idéias até agora. Eles ainda nem incluem opções de localização para datas, etc., mas como meu servidor suporta PHP5.3.2 +, a melhor opção é usar a extensão intl conforme explicado aqui: http://devzone.zend.com/1500/internationalization-in -php-53 / - mas isso seria útil em qualquer estádio de desenvolvimento posterior. Por enquanto, a questão principal é como ter as melhores práticas de tradução do conteúdo em um site.
Além de tudo que expliquei aqui, ainda tenho outra coisa que ainda não decidi, parece uma pergunta simples, mas na verdade está me dando dores de cabeça:
Tradução de URL? Devemos fazer isso ou não? e de que maneira?
Então .. se eu tiver esse URL: http://www.domain.com/about-us
e inglês é o meu idioma padrão. Esse URL deve ser traduzido para http://www.domain.com/over-ons
quando eu escolher o holandês como meu idioma? Ou devemos seguir o caminho mais fácil e simplesmente alterar o conteúdo da página visível em /about
. A última coisa que parece não ser uma opção válida, porque isso geraria várias versões do mesmo URL; a indexação do conteúdo falhará da maneira correta.
Outra opção está sendo usada http://www.domain.com/nl/about-us
. Isso gera pelo menos um URL exclusivo para cada conteúdo. Também seria mais fácil ir para outro idioma, por exemplo, http://www.domain.com/en/about-us
e o URL fornecido é mais fácil de entender para os visitantes do Google e Humanos. Usando esta opção, o que fazemos com os idiomas padrão? O idioma padrão deve remover o idioma selecionado por padrão? Então, redirecionando http://www.domain.com/en/about-us
para http://www.domain.com/about-us
... A meu ver, essa é a melhor solução, porque quando o CMS é configurado para apenas um idioma, não é necessário ter essa identificação no URL.
E uma terceira opção é uma combinação das duas opções: usar o "idioma-identificação-menos" -URL ( http://www.domain.com/about-us
) para o idioma principal. E use um URL com uma lesma de SEO traduzida para sub-idiomas: http://www.domain.com/nl/over-ons
&http://www.domain.com/de/uber-uns
Espero que minha pergunta faça sua cabeça rachar, eles racharam a minha com certeza! Já me ajudou a resolver as coisas como uma pergunta aqui. Deu-me a possibilidade de revisar os métodos que usei antes e a idéia que estou tendo para o meu próximo CMS.
Eu gostaria de agradecer a você por ler esse monte de texto!
// Edit #1
:
Esqueci de mencionar: a função __ () é um alias para traduzir uma determinada string. Nesse método, obviamente deve haver algum tipo de método de fallback em que o texto padrão é carregado quando ainda não há traduções disponíveis. Se a tradução estiver ausente, ela deve ser inserida ou o arquivo de tradução deve ser regenerado.