ATENÇÃO: Embora o blog tenha uma licença Creative Commons, esse post é licenciado sobre a GNU FDL, pois boa parte dele foi retirado do Wiki do Archlinux no verbete Grub.

Uma das coisas chatas do Archlinux que eu não sabia configurar direito é o Framebuffer. Nunca conseguia fazer do jeito que eu queria e sempre dava alguns erros meio inexplicáveis e por isso me conformava. Com a nova versão do Arch, vi um link muito interessante no arquivo /boot/grub/menu.lst , esse link apontava para uma sessão do verbete do Grub no Wiki oficial. E lá vi uma coisa muito procurada por mim: um programa que me passava uma configuração correta para o framebuffer!

Aqui vai então o tutorial traduzido:

Como root, instale o lrmi:

 
pacman -S lrmi
 

Vá para um console (Ctrl+Alt+F1 (pode ser tecla de F1 a F6)) e digite o seguinte comando (como root):

 
pacman -S lrmi
 

Ainda como root, execute o seguinte comando:

 
vbetest
 

Deverá aparecer algo como isso:

Os números entre colchetes estão relacionados com o framebuffer que seu computador tem suporte. Agora teste a configuração desejada: escolha um dos números e digite o seguinte comando (ainda como root, substituindo XXX pelo número):

 
vbetest -m XXX
 

Na minha detecção, eu testei com o seguinte parâmetro:

 
vbetest -m 354
 

Deverá aparecer uma tela quadriculada, de um gradiente indo do azul para o verde. Esse é o teste. Ficou feliz? Agora é só colocar no /boot/grub/menu.lst. Para isso você terá que somar 512 ao número (vou chamar essa soma de YYY).

Como sou cauteloso, o que eu fiz foi o seguinte: copiei uma entrada do grub funcionando, chamei ela de Arch Linux Framebuffer (é só alterar o title) e adicionei no final da linha kernel vga=YYY. No meu caso eu coloquei vga=866. Agora é só reiniciar e correr pro abraço

Espero que essa dica tenha sido útil.

Uma coisa que tenho feito nos últimos tempos é traduzir software livre e uma lista razoável destes: Pidgin, Mono, Anjuta, pacman entre outros. Então, pretendo nesta série de posts dar alguma dicas e dizer como é o processo de tradução, ferramentas extras que uso e como preparo meu ambiente para fazer uma tradução.

Neste primeiro post vou falar sobre o processo de tradução. O processo de revisão virá em outro post. O processo de tradução é bem complexo: tradutores automáticos normalmente não traduzem direito e nada melhor que um cérebro humano para fazer um bom trabalho.

Softwares livres escritos em C/C++ e outras linguagens populares normalmente utilizam o software livre GNU Gettext que permite que você faça programas em mais de um idioma. E o mais interessante: dependendo da variável LANG, o programa é automaticamente iniciado no idioma correto. Obviamente, se o programa não possuir uma tradução o programa será carregado no seu idioma original (que normalmente é o inglês). Porém, se o programa estiver com a tradução incompleta, o que não foi traduzido aparecerá no idioma original e o resto aparecerá traduzido. Como normalmente traduzo usando um editor de texto (vim rlz!), eu explicarei como funciona a tradução em um editor de texto. Para os softwares que editam arquivos po (por exemplo o poedit)

Traduzindo um arquivo do zero

Antes de traduzir algo do zero, veja se não tem ninguém traduzindo perguntando na lista de discussão. Isso pode evitar que você trabalhe a toa.

O Gettext gera um arquivo .pot que é um arquivo com todas as frases que devem ser traduzidas mas sem nenhuma tradução. Se você for começar a traduzir um software que não possui tradução em português do (verifique se existe algum pt-BR.po na pasta po/). Este arquivo deve conter um monte de coisas parecidas com estas:

 
# arquivoteste.c:231
msgid "The book is on the table"
msgstr ""
 

Em um arquivo po, comentários começam com #, normalmente eles indicam onde está aquela frase no código fonte. O msgid é a frase original, que existe no programa. No msgstr você deverá colocar a tradução. Então ficaria assim:

# arquivoteste.c:231
msgid "The book is on the table"
msgstr "O livro está sobre a mesa"

Pronto. Você traduziu a frase. Algumas frases utilizam o conteúdo de variáveis, um exemplo (retirado do .po do Pidgin) é esse:

#: ../libpurple/protocols/msn/error.c:243
#: ../libpurple/protocols/msnp9/error.c:249
#, c-format
msgid "Unknown Error Code %d"
msgstr "Código de erro desconhecido: %d"

Esse %d é um "símbolo" da linguagem C (que também pode ser usado em C++) que nos informa que o conteúdo de uma variável será impresso (certamente se você vascular o código fonte do programa você verá que variável que é). Obviamente, a tradução deverá também conter esse "símbolo".

Atualizando uma tradução já existente

Muitas vezes você não começa uma tradução já existente, mas sim atualiza um arquivo .po existente. Neste caso você encontrará frases já traduzidas, frases não traduzidas e um terceiro status: fuzzies!

As traduzidas você não precisa mexer (mas sempre vale a pena você dar um lida para encontrar eventuais erros ou se acostumar com o vocabulário do programa). As não traduzidas você traduz como explicado na seção anterior. Mas e as fuzzies?

# teste.c: 192
#, fuzzy
msgid "The book is on the chair"
msgstr "O livro está sobre a mesa"

A primeira vista pode parecer que alguém traduziu errado, mas o que aconteceu foi que a tradução foi atualizada e o programa que fez a intercalação do arquivo .pot (o arquivo que é gerado com as frases) e o arquivo .po achou que a tradução fosse a mesma pelas frases serem parecidas, mas como ele não é um oráculo, ele marcou a frase como fuzzy (que significa incerta, confusa) para um ser humano verificar se a frase está correta (algumas vezes é necessário mudar uma coisinha, algumas vezes é necessário reescrever a frase).

Vendo se uma tradução funciona

Existem dois comandos importantes para tradutores: um deles é o msgfmt (que gerá arquivos po "compilados") o outro é o pofilter (que é mais utilizado na revisão e falarei dele no post sobre revisão). Se você está apenas traduzindo um software não será necessário "compilar" a tradução, porém seria interessante você ver se algum erro aconteceu na "compilação" da tradução (traduções que não compilam normalmente são rejeitadas por projetos).

msgfmt -cvo /dev/null arquivo.po

Esse comando "compila" o arquivo .po propriamente dito porém ele joga a saída (com o argumento -o) no buraco negro do sistema (aka /dev/null). O argumento -c significa que irá ser feito uma verificação (check), o -v aumenta a verbosidade. Se houver algum erro ele irá avisar onde está o problema, se não houver ele lhe dirá quantas frases estão traduzidas, incertas e não traduzidas.

"Lugares" úteis

Dois sites são "obrigatórios" se você quiser traduzir um software livre: o vocabulário padrão (a.k.a. VP) e o open-tran.

O vocabulário padrão é utilizado para garantir a consistência: delete por exemplo pode ser traduzido para remover, apagar, deltar e excluir. E o que garante que todos os tradutores usem o mesmo termo ? O VP. Ele é atualizado por alguns membros da LDP-BR (Linux-Documentation-Project) após o termo ser discutido na lista do LDP (falarei sobre ela em breve). Vocẽ pode pesquisar por um termo lá. Sugestões/reclamações/relatórios de erros podem ser feitos na própria lista do LDP. Claro que o VP não possui todos os termos: alguns deles tem uma tradução diferente dependendo do contexto. Cabe a você escolher a melhor (ou pedir ajuda )

O Open-Tran tem um propósito parecido, mas ele não é atualizado por membros mas sim automaticamente. Se você pesquisar por exemplo "checkbox" ele lhe mostrará vários exemplos de frases traduzidas com este termo junto com o logo do projeto que traduziu aquela frase. Você também pode ver a frase original + o software que tem aquela frase simplesmente clicando na frase.

A lista do LDP-BR é povoada por muitos tradutores de Software Livre que podem te ajudar no caso de alguma dúvida de termo ou do processo de tradução. Lá também vocẽ pode ver as discussões sobre termos novos do VP assim como sugerir termos novos.

Também existe um canal de IRC #tradutores no freenode onde você pode tirar uma dúvida em tempo real.

Imagine que uma doença começasse a cegar as pessoas. Primeiramente atingiria uma pessoa e depois se espalharia como uma epidemia. O que você faria ? Isto mudaria sua vida? As pessoas continuariam sendo como elas são?

Este livro, escrito pelo escritor português ganhador do prêmio Nobel José Saramago, fala sobre uma epidemia de cegueira branca que começa em um homem dirigindo um carro e vai se espalhando para diversas pessoas que são mantidas em quarentena em um antigo manicômio e são obrigadas a construir uma sociedade lá dentro.

O estilo de escrita de Saramago é muito peculiar: os diálogos estão no meio das frases e não me lembro de um personagem ter um nome. Há um personagem chamado pelo narrador de médico, o que foi o primeiro a cegar é chamado de "o primeiro cego", outra personagem é a mulher do óculos escuro. Há também cenas fortes no livro e que deixam o leitor bastante impressionado.

Acho que o principal do livro é discutir o caráter humano em momentos de profundo desespero. Você acha que seria capaz de cometer algo que a sociedade considera crime, apenas para sobreviver?

Há também um filme, dirigido por Fernando Meirelles que é bastante semelhante ao livro e por isso é também recomendado.

É com muito orgulho que anuncio que o guia de instalação da versão 2009.02 do Archlinux está quase lançado! O guia foi feito com a contribuição de cinco pessoas: Eu, Hugo Dória (que contribuiu escrevendo muitas seções), Corvolino (que fez a revisão do guia), Daniel Balieiro (que fez muitos screenshots) e Farid Abdelnour (que arrumou as bordas das fotos)!

E ai vem a pergunta: por que "quase" lançado? Estamos ouvindo feedbacks e sugestões de usuários. Você acha que deveríamos falar de alguma coisa extra? Este é o momento para você dar seu feedback, seu comentário, sua sugestão ou sua crítica.