O período do FISL deste ano foi bem divertido, aqui vão alguns apontamentos do FISL e de correlacionados:

• Foi legal conhecer alguns usuários do Arch e alguns membros do time de desenvolvimento do Arch-br (como foi o caso do Gilfran, Kalib, Farid, Nilo, Morgana e Tiago) . Acho que isso é o mais legal do FISL: poder conhecer pessoas que você só conhece via IRC/E-mail. Foi também legal rever quem eu já conhecia conhecia (como foi o caso do Hugo, Douglas e Kessia )
• O pessoal do GNOME deu uma palestra show: o GNOME 3 realmente promete muitas novidades e tentarei bastante fazer um esforço para poder programar um pouco para ele. Conheci também algumas pessoas que não conhecia: Jorge Pereira, Vinicius Depizzol e a Krix Apolinário. Também revi o John Wendell que me respondeu algumas dúvidas sobre como desenvolver para o GNOME.
• Churrasco demais. Comi churrasco demais e durante vários dias que até enjoei.
• Quanto mais eu vou em eventos de Software Livre, mais eu percebo o pólo de desenvolvimento de Software Livre que é a região nordeste do Brasil. Conheço pessoas do Ceará, Alagoas, Pernambuco, Sergipe e Bahia. além do mais sempre acompanho remotamente os eventos que acontecem por lá. Seria o nordeste a região mais hacker do Brasil ? Vejo muito poucas coisas parecidas aqui em Sampa.
• A gastronomia de Porto Alegre também é bem deliciosa. Um bom destaque é o Atelier Das Massas. A segunda melhor massa que comi em toda minha vida. Só perde para a da minha avó.

Mas como nem tudo é perfeito...

• A presença do nosso presidente realmente alavanca em muito o evento, mas a mancada com o participante que as vezes gasta muito e enfrenta jornadas para vir para o FISL foi muito triste. Acho que a organização deveria ou organizar melhor o evento de modo a não fechá-lo, ou recusar a vinda do presidente até que sua vinda não atrapalhasse tanto o evento. O FISL é ao meu ver um evento feito para a comunidade de software e cultura livre e não para fazer políticos aparecerem. Se estes quiserem vir, que venham e serão muito bem recebidos, como são bem recebidos todos os participantes do FISL, mas que não "fechem" o evento por causa disso. Sei que na questão de um presidente é caso de segurança nacional e o procedimento não podia ser diferente. Mas que foi desconfortável, isso foi.
• A data do evento também foi bem ruim. Sei da dificuldade que é organizar um evento do porte do FISL e que nem sempre as coisas são como se desejam, mas nossa caravana, que ano passado juntou 80 pessoas para o FISL, esse ano só juntou 24. Alguns amigos me disseram que não iriam exatamente por que a data do evento era em época de prova e trabalhos finais. Se fosse ao menos no meio de julho ou em qualquer outro mês, talvez o nosso quórum fosse maior.

Mesmo com os problemas, acho que o evento deixa um bom saldo positivo. O desenvolvimento de Software Livre no Brasil se fortalece muito em eventos como esse.

Esse post será simultaneamente publicado no blog trezentos no qual também estou fazendo parte.

Na quarta feira (dia 24/04) aconteceu o I encontro de usuários brasileiros do Archlinux no FISL. O encontro contou com 4 palestras:

• "Introdução ao Archlinux" por mim mesmo;
• "From * import Arch" pela Kessia "even" Pinheiro;
• "Archlinux Brasil - O que somos seremos e fomos" por Douglas Soares de Andrade
• "Construindo pacotes para o Archlinux" por Hugo Dória

Nosso objetivo principal foi apresentar nossa comunidade e nossa distribuição, falando dos principais motivos que nos fazem usar o archlinux e sobre o início da sua comunidade. Também fizemos uma palestra mais técnica para ensinar sobre os pacote

Meus slides estão disponíveis para download no meu site aqui. Se você quiser dar uma palestra parecida, fique a vontade para usar meus slides (só coloque meus devidos créditos ).

Um dos blogs que mais gosto é o Efetividade.net, nele se fala muito sobre como otimizar sua vida profissional e pessoal a partir de idéias na maioria das vezes simples. Seguindo essa linha vou dar dicas de como otimizar sua tradução de software livre.

Traduza aos poucos

O que costumo fazer ao traduzir algo é estabelecer metas diárias pequenas. Se eu consigo traduzir com qualidade 50 strings por dia, não vou me atrever a fazer 100 por dia, já que o resultado terá uma qualidade mais baixa. Então tento manter no máximo essa meta todo dia.

Anotações

Outra coisa bastante importante são anotações. Você não ficou satisfeito com alguma string ou termo que traduziu? Gostaria de pedir feedback para outros tradutores sobre suas dúvidas? Algum termo você não achou o significado? Faça anotações para te relembrar de tudo isso após terminar! Isso pode ser feito tanto usando um simples arquivo texto ou usando uma ferramenta de "post-its" virtuais (como o Tomboy). Se alguma dúvida não foi esclarecida, coloque-a como comentário para o revisor de sua tradução. Isso ajudará muito no processo .

Faça um bom trabalho

Uma das coisas menos produtivas é ver seu trabalho sendo rejeitado. E embora projetos de software livre sejam (em boa parte) feitos de trabalho voluntário isso não significa que não há a busca por padrões altos de qualidade, tanto de código, como de tradução. Então, se você fizer um trabalho mal feito, quase que com certeza um revisor não vai ter paciência de praticamente refazê-lo e você correrá o risco de ter sua tradução rejeitada. Não é muito díficil não correr esse risco: basta observar os padrões estabelecidos no seu projeto (que pode usar o vocabulário padrão), fazer a verificação de "compilação" (via $ msgfmt -cvo /dev/null arquivo.po), sempre tirar dúvidas com um membro mais experiente quando você não souber o que fazer e evitar erros de português (no caso de dúvidas faça um google fight entre as duas opções e veja a que mais aparece ou busque o termo em algum dicionário online).

Esse post tem a intenção de sugerir melhorias no trabalho de tradução de software livre. Se você é tradutor e tem mais alguma sugestão, por favor coloque-a no comentário .

Depois de falar de tradução, vem o que devemos fazer depois: a revisão da tradução. Além de corrigir pequenos erros de digitação e ortografia que todos eventualmente cometemos também é necessário ver se a frase como um todo traduzida faz sentido e isso também é um papel da revisão.

Alguns erros mais básicos podem ser corrigidos com um programa chamado pofilter (para instalá-lo procure por translate-toolkit no seu gerenciador de pacotes preferido) que lê todo o arquivo po e verifica alguns tipos de erros básicos como espaços a mais ou pontuação diferente no final da frase traduzida. Ele possui 46 filtros (que você pode ver com a opção -l) diferentes que podem ser ativados ou desativados. Uma opção de desativação que uso muito é a de mostrar frases não traduzidas: como eu executo o pofilter a cada N frases traduzidas, eu já sei que haverão muitas mensagens não traduzidas, então nessas verificações intermediárias eu desativo este filtro. Há também opções como --gnome, --kde, --mozilla e outros semelhantes que fazem as verificações padrões para estes projetos. O pofilter também te dá a opção de corrigir automaticamente sua tradução, mas não sou muito fã dessa opção pois ele ás vezes te dá muitos falsos positivos e como somos mais inteligentes que computadores, podemos decidir e corrigir a tradução pessoalmente (e fazendo isso, diminuimos a chance de cometer esses mesmos erros no futuro).

Com os erros mais básicos corrigidos com o pofilter, devemos ler o arquivo todo para verificar inconsistências (termos traduzidos de duas maneiras diferentes quando se referem as mesmas coisas), erros bobos de digitação incorreta e erros de concordância e regência que garantem uma boa qualidade da tradução. Uma outra alternativa mais simples é pegar um diff (com a opção -u) do que você traduziu e rever somente o que você fez (já que você já revisou enquanto traduzia o resto).  E nas frases mais longas sempre leia a frase novamente para ver se está fazendo sentido.

Próximo capítulo desta série é: traduzindo com efetividade . Nele pretendo dar algumas dicas de como traduzir um software livre com efetividade.

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.

Após adicionar o pacote conduit no repositório da comunidade brasileiro do archlinux, foi relatado que este software estava com problemas no seu modo gráfico.

Após tentar alguns work-arounds descobri (com a ajuda do Jorge Pereira (btw valew!))  aonde estava o erro: a biblioteca pygoocanvas (uma das dependências) estava terminando inesperadamente como resultado de um Segmentation Fault.  E o problema parecia ser ainda maior: o pygoocanvas baixado do repositório do gnome rodando no archlinux estava dando Segmentation Fault. Depois de um bug report, o pacote foi atualizado para uma versão mais antiga (vulgo downgrade) pelo DSA (btw valeu!) e agora o pacote está compilando e funcionando.

Ao comunicar isso na entrada do Conduit no AUR, o mantenedor anterior me ofereceu a adoção do pacote e agora sou o mantenedor deste pacote.Por isso, se você utilizar esse pacote no archlinux, você já tem para quem reclamar .

Pois é, me chamaram para um meme. Então aqui vai o meme infância.

• Colocar as regras expostas no post
• Colocar 9 imagens que marcaram a sua infância, pode ser programa de televisão, passatempos, recreações tudo que demonstre sua infância.
• Explicar cada imagem
• Indicar 5 pessoas para fazer esse meme

1. Tom e Jerry: o gato perseguia o rato. E o rato fugia do gato. O gato preparava armadilhas. O rato fazia as coisas de um jeito que o gato caia em suas próprias armadilhas. E assim era Tom e Jerry. Um dos desenhos mais assistidos do início da década de 90.
2. Prince of Persia: Quem tem PC a muito tempo conhece esse joguinho. Numa época que não existia caixas de som o som vinha do PC Speaker. Nunca acabei Prince, mas me divertia muito saltando de um lado pro outro, pulando lanças e precipicios.
3. TV Cultura: Rá-Tim-Bum, Mundo da Lua, Glub-Glub,  As Aventuras de Tin-Tin, o Castelo Rá-Tim-Bum e X-Tudo. Quando era pequeno assisti muito esses programas da cultura. Tin-Tin era a única produção não nacional, os outros todos eram da TV Cultura. Que época boa!
4. Cavaleiros do Zodíaco: Todos os dias as 18:30 na extinta TV Manchete. Foram anos assistindo e perdendo os episódios de terça e quinta, pois eu tinha inglês no horário.
5. Copa de 94: Quem não se lembra dos gols do Stoichkov, das fechadas de gol do Preud'Homme, da genialidade de Maradona e Caniggia, das trancinhas de Roberto Baggio e da estrela do Romário? Essa copa foi a melhor de todas.
6. Pica Pau: Podia ser o Zeca Urubu, o Leôncio ou com o Zé Jacaré, esse pássaro aprontava muito com todos esses inimigos, que algumas vezes queriam comer o pobre passaro, mas outras vezes queriam apenas conselhos.
7. Jaspion: Ele e seu Robô Daileon salvavam o mundo de monstros galáticos. Primeiro seriado de herói japonês que eu assisti.  Depois tiveram Changeman, Flashman e por aí vai.
8. Chaves e Chapolim: Essa é da infância de muita gente. Seja 10 anos mais velhos ou 10 anos mais novos que eu. Quem não se divertia com o super herói atrapalhado ou a nturma do cortiço do menino pobre que atire a primeira pedra.
9. Turma da Mônica: e não era só no gibi não. Eu tenho as fitas de vídeo das aventuras, ia no parque da Mônica, tive até o microscópio da Mônica.

Agora convido para participar desse Meme o Og Maciel, Hugo Doria, pessoal do Vidageek.net, Adorilson e o Karlisson (que talvez fale sobre a infância do Nerdson ).