Como internacionalizar as mensagens nas views do Code Igniter

Estive fazendo um job junto com o @gserrano usando o Code Igniter, e tivemos a necessidade de fazer a view com mensagens internacionalizadas, uma vez que o site terá versão em espanhol e português. Mais uma vez, o framework facilitou muito a nossa vida.

Vamos lá, é simples:

  • dentro da pasta application, há uma chamada language
  • dentro de language, deve haver uma pasta para cada um dos seus idiomas
  • crie em cada uma dessas pasta um arquivo chamado {nomedocliente}_lang.php (claro, {nomedocliente} pode ser trocado por qualquer coisa. No exemplo a seguir, usarei meujob_lang.php)
  • o conteúdo do arquivo deve seguir a estrutura:
    $lang["chave1]    = "mensagem 1";
    $lang["chave2]    = "mensagem 2";
    $lang["chave3]    = "mensagem 3";
    ?>

    Ou seja, é um arquivo que conterá chaves (usadas na view) e os valores. As chaves serão sempre iguais nos diversos arquivos de internacionalização, e as mensagens, serão as mesmas, traduzidas para o idioma em questão
  • antes de usar na view essas mensagens, você deve adicionar as mesmas no controller.
    Imagine que você tenha o seguinte método em um controller:
    public function formulario() {
       $this->load->view('passo1');
    }
    O que você precisa é, antes de carregar a view, adicionar o idioma que será usado. No caso abaixo, o que fiz é carregar a view dependendo do terceiro parâmetro vindo na url (por exemplo: /meucontroller/formulario/pt_BR)
    public function formulario() {
       $this->lang->load('meujob', $this->uri->segment(3));
       $this->load->view('passo1');
    }
    Note que (1) falta uma validação do terceiro parâmetro e (2) meujob é o nome do arquivo criado lá no terceiro passo.
  • na view, basta você chamar lang->line("chave1"); ?> por exemplo, que será printada na tela a mensagem referente a chave1 do arquivo de mensagens correto.

Refefência: http://codeigniter.com/user_guide/libraries/language.html

Configurando o PHP para exibir erros

Por questões de segurança normalmente servidores configuram o php.ini para inibir a exibição de erros (se um usuário consegue identificar um erro e tem informações sobre ele fica mais fácil explorar o problema).

Configurando pelo php.ini

No php.ini você deve ter uma chave display_errors, que provavelmente está asssim:

display_errors = Off

Para configurar pelo php.ini é só trocar o valor Off por On e todas as páginas em PHP no servidor irão printar os erros – não faça isso em produção, pelo motivo de segurança que citei acima.

 

Configurando pelo código

Considero esta a melhor opção, manter sempre o php.ini configurado para não exibir erros e configurar isso em cada aplicação em que for necessário, pois alterar o php.ini modifica o funcionamento de todos os projetos que estiverem no servidor.

Na última versão do Code Igniter (2.0) ele vem com uma variável de configuração para definir em qual ambiente o projeto está rodando: dev, homologação, produção, e isso define se os erros serão ou não exibidos.

Para configurar no código a exibição de erros e log de erros, adicione o bloco abaixo no teu código:

ini_set('display_errors', 1);
ini_set('log_errors', 1);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');
error_reporting(E_ALL);

E não se esqueça de omitir os erros quando a aplicação for para ambiente de produção! 🙂

Terminal SSH no Windows

O And After roda em um Ubuntu Server, administrado por SSH – no linux eu fazia essa conexão pelo terminal SSH, mas como também uso Windows fui pesquisar softwares que permitissem um terminal SSH no Windows.

O mais simples que encontrei foi o PuTTy, que é gratuito. Você pode fazer o download dele aqui.

Não precisa instalação nenhuma e a tela do programa é assim:

PuTTy - SSH para Windows

A única configuração necessária é digitar o local do servidor em "Hostname / IP" e clicar em Open, o PuTTy vai abrir o terminal para você logar no servidor.

Esse é um programa útil para ter no seu celular ou pendrive de estimação (aquele que você leva no bolso), caso você precise em algum lugar qualquer dar manutenção em algum servidor Linux… 🙂

MySQL – innoDB e MyISAM

Quando nós viramos a nova versão do And After 2011 sofremos algun dias com problemas de performance – o MySQL que rodava no servidor funcionava normalmente por algum tempo (aleatório) e o consumo de processamento subia loucamente, o site parava de responder e logo o servidor morria. Um reset, e o ciclo voltava a acontecer…

Testei alguns métodos de cache: geração de html, cache de query mas nada foi muito satisfatório – ou quando resolvia o problema prejudicava um pouco a navegação e usabilidade do site (login, publicação de comentários, etc.).

O @fefurst e um pessoal do Twitter falou para eu verificar como estavam configuradas as tabelas do meu banco e falaram para eu tentar converter para MyISAM (o atual padrão de tabelas do mysql) – mas elas já estavam neste formato.

Alterei tudo para innoDB e o problema de performance acabou – o MySQL parou de derrubar o processador e o tempo de resposta voltou ao normal, ouf!

Principais diferenças entre innoDB e MyISAM

InnoDB usa proteção por registro (row locking) enquanto MyISAM usa proteção por tabelas (table locking), por isso em tabelas que são constantemente alteradas (é o caso de algumas tabelas do And After, com as tabelas de logs, comentários, etc) o InnoDB apresenta uma melhor performance do que o MyISAM – que em outros casos é melhor que InnoDB pois não funciona com transações.

Para tabelas usadas essencialmente para consultas (como tabela de localidades, ou de usuários de um sistema fechado) o MyISAM é o mais recomendado.

Dicas de performance com MySQL

Cache

Outra dica para performance – que o Chrisimplementou aqui no And After – é verificar a existência de querys complexas na sua aplicação e pensar em alguma forma de cache para estas querys. Usamos isso na tagcloud, acompanhem a lógica para confirmar a tagcloud:

  1. Percorrer todas as tags do banco
  2. Verificar quantos posts estão associados a cada tag
  3. Ordenar as tags de acordo com o número de posts que utilizam

Essa query é um pouco lenta, tem alguns innerjoins malucos e não é legal ter ela em quase todas as telas. Uma opção é configurar o cache do próprio MySQL, outra opção (que foi o que fizemos) é transformar esta query em uma rotina e criar uma segunda tabela para a tagcloud OU adicionar uma coluna na tabela de tags que representa a relevância daquela tag (no exemplo, o número de posts que a utilizam).

Indexação de buscas

Esta aí algo que eu não posso falar muito pois ainda não tenho familiaridade: sistemas de indexação de busca. Só conheço o Lucene – sei que funciona com o Zend (EN)  e tem como fazer isso funcionar com o Code Igniter (EN) – mas para aplicações com muita informação é uma opção que deve ser considerada com carinho.

Antes de sair por aí alterando coisas em produção verifique se está tudo certo com o agendamento de backup do seu MySQL.

Referências