GPS Humano » wikipedia

Início das actividades da Wikimedia Portugal

ntavares — Sun, 24 Jan 2010 23:48:04 +0000

Este post já deveria ter chegado há muito mais tempo. Mas o tempo não o permitiu…

Não deve ser novidade que a Wikimedia Portugal (WMP) já arrancou o Plano de Actividades para 2010-11. A primeira actividade oficial foi uma apresentação num seminário no Instituto Superior Técnico promovido pela Presidência do Departamento de Engenharia Informática, a convite do prof. José Borbinha, que gostámos muito de conhecer e a quem agradecemos o apoio e disponibilidade que demonstrou para connosco.

A Susana fez uma exposição da Wikimedia Foundation, do nosso contexto WMP, do processo editorial, da estrutura interna dos projectos (utilizadores, categorias, etc), da manutenção, licenciamento, etc.

A apresentação está aqui:
http://wikimedia.pt/download/Wikimedia_Slideshow.pps

Eu juntei-me à festa, atendendo a um público de informática, e apresentei brevemente a plataforma da WMF (servidores, software, arquitectura) mas o grosso da minha mini-apresentação foi para falar de predefinições, dados estruturados e seus benefícios na Wikipédia e, por fim, divaguei um bocadinho até à Web Semântica, conceito para o qual a Wikipédia está a ser bastante utilizada (os tópicos estão resumidos em 2 posts que já tinha feito no blog [1][2]).

A apresentação está aqui:
http://wikimedia.pt/download/Wikimedia_Web_Semantica.pps

Actualização das páginas órfãs

ntavares — Sun, 18 Oct 2009 03:45:13 +0000

A pedido do Lijealso, aqui vai uma actualização das estatísticas incompletas da Wikipédia lusófona para o caso das páginas órfãs.

Constatou-se que o dump utilizado anteriormente era insuficiente, pelo que se descarregou a tabela pagelinks, desta vez do dump de 20091015. Para se excluir os redireccionamentos, importou-se também a tabela redirect.

Fartei-me entretanto de alternar entre o que estava a fazer e a lista de códigos de domínios, pelo que criei uma pequena tabela auxiliar:

PLAIN TEXT

MySQL:

mysql> CREATE TABLE _namespaces ( id TINYINT NOT NULL, namespace VARCHAR(50), PRIMARY KEY (id) );
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO _namespaces VALUES (-2,'Media'),(-1,'Especial'),(0,''),(1,'Discussão'),(2,'Usuário'),(3,'Usuário Discussão'),(4,'Wikipedia'),(5,'Wikipedia Discussão'),(6,'Ficheiro'),(7,'Ficheiro Discussão'),(8,'MediaWiki'),(9,'MediaWiki Discussão'),(10,'Predefinição'),(11,'Predefinição Discussão'),(12,'Ajuda'),(13,'Ajuda Discussão'),(14,'Categoria'),(15,'Categoria Discussão'),(100,'Portal'),(101,'Portal Discussão'),(102,'Anexo'),(103,'Anexo Discussão');
Query OK, 22 rows affected (0.00 sec)
Records: 22 Duplicates: 0 WARNINGS: 0

O resultado deu-me um incrível total de 769854 páginas órfãs, pelo que decidi separá-las por namespace para permitir prioritizar a análise:

PLAIN TEXT

MySQL:

mysql> SELECT p.page_namespace,count(1) FROM page p
-> LEFT JOIN redirect r
-> ON p.page_id = r.rd_from
->
-> LEFT JOIN pagelinks pl
-> on pl.pl_namespace = p.page_namespace
-> and pl.pl_title = p.page_title
->
-> WHERE r.rd_from IS NULL
-> AND pl.pl_from IS NULL
->
-> GROUP BY p.page_namespace;
+----------------+----------+
| page_namespace | count(1) |
+----------------+----------+
| 0 | 12958 |
| 1 | 103645 |
| 2 | 16592 |
| 3 | 568675 |
| 4 | 1954 |
| 5 | 856 |
| 8 | 773 |
| 9 | 17 |
| 10 | 7522 |
| 11 | 1014 |
| 12 | 3 |
| 13 | 27 |
| 14 | 51735 |
| 15 | 1315 |
| 100 | 1190 |
| 101 | 117 |
| 102 | 173 |
| 103 | 1288 |
+----------------+----------+
18 rows in SET (20.90 sec)

O resultado do cruzamento das duas tabelas foi afixado aqui, com uma listagem de 15M para os 12958 artigos no domínio principal. Na verdade, esta listagem foi feita para colar numa página wiki, no entanto tenham em atenção que são 15M, pelo que não recomendo fazê-lo. Têm outras listas (como a mais simples, em formato pageid,namespace,title) nessa directoria.

Revisita aos dumps da Wikipédia

ntavares — Tue, 06 Oct 2009 00:44:59 +0000

Desta vez em português, decidi dar [alguma] continuidade ao que comecei há uns dias com a importação dos dumps da Wikipédia. Graças à dica do Rei-artur foi fácil extrair a lista de robôs, para excluir das estatísticas.

PLAIN TEXT

CODE:

[myself@speedy ~]# wget 'http://pt.wikipedia.org/w/api.php?action=query&list=allusers&aufrom=A&augroup=bot&aulimit=500&format=txt' -q -O - > bots.tmp
[myself@speedy ~]# cat bots.tmp | grep '\[name\]' | sed 's,^.*\[name\] => ,,' > /tmp/bots.txt

Aproveitei e repesquei os user_id para simplificar as pesquisas sem fazer alterações na tabela user.

PLAIN TEXT

MySQL:

mysql> CREATE TABLE user_bots ( bot_name VARCHAR(25) );
Query OK, 0 rows affected (0.01 sec)
mysql> LOAD DATA INFILE '/tmp/bots.txt' INTO table user_bots;
Query OK, 136 rows affected (0.00 sec)
Records: 136 Deleted: 0 Skipped: 0 WARNINGS: 0
mysql> ALTER TABLE user_bots add COLUMN bot_user_id INT;
Query OK, 136 rows affected (0.01 sec)
Records: 136 Duplicates: 0 WARNINGS: 0
mysql> ALTER TABLE user add index idx_t ( user_name );
Query OK, 119134 rows affected (2.63 sec)
Records: 119134 Duplicates: 0 WARNINGS: 0
mysql> UPDATE user_bots ub JOIN user u on user_name = bot_name SET ub.bot_user_id = u.user_id;
Query OK, 134 rows affected (0.00 sec)
Rows matched: 134 Changed: 134 WARNINGS: 0
mysql> ALTER TABLE user_bots add PRIMARY KEY (bot_user_id);
Query OK, 136 rows affected, 1 warning (0.00 sec)
Records: 136 Duplicates: 0 WARNINGS: 1
mysql> SHOW WARNINGS;
+---------+------+---------------------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------------------+
| Warning | 1265 | Data truncated for COLUMN 'bot_user_id' at row 71 |
+---------+------+---------------------------------------------------+
1 row in SET (0.00 sec)
mysql> UPDATE user_bots SET bot_user_id = -1 WHERE bot_user_id = 0;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 WARNINGS: 0

Não tinha reparado que havia um utilizador/robô com o nome "MediaWiki default" mas, bem, depois de criar a Primary Key ficou com o bot_user_id=0 e, para evitar que coincidisse com o agregado para anonymous, dei-lhe o bot_user_id=-1.

Então agora já estamos prontos a completar a query onde ficámos no último dia (número de edições em artigos distintos em cada namespace por utilizador):

PLAIN TEXT

MySQL:

mysql> EXPLAIN SELECT epn.user_name,epn.page_namespace,epn.edits
-> FROM edits_per_namespace epn
-> LEFT JOIN user_bots ub ON epn.user_id = ub.bot_user_id
-> WHERE ub.bot_user_id IS NULL
-> AND epn.user_id <> 0
-> ORDER BY edits desc limit 20;
+----+-------------+-------+--------+---------------+---------+---------+----------------------+--------+--------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+----------------------+--------+--------------------------------------+
| 1 | SIMPLE | epn | ALL | NULL | NULL | NULL | NULL | 187624 | USING WHERE; USING filesort |
| 1 | SIMPLE | ub | eq_ref | PRIMARY | PRIMARY | 4 | ntavares.epn.user_id | 1 | USING WHERE; USING index; NOT EXISTS |
+----+-------------+-------+--------+---------------+---------+---------+----------------------+--------+--------------------------------------+
2 rows in SET (0.00 sec)
mysql> SELECT epn.user_name,epn.page_namespace,epn.edits
-> FROM edits_per_namespace epn
-> LEFT JOIN user_bots ub ON epn.user_id = ub.bot_user_id
-> WHERE ub.bot_user_id IS NULL
-> AND epn.user_id <> 0
-> ORDER BY edits desc limit 10;
+----------------+----------------+-------+
| user_name | page_namespace | edits |
+----------------+----------------+-------+
| EMP,Nice poa | 0 | 58138 |
| Dantadd | 0 | 44767 |
| João Carvalho | 3 | 44533 |
| OS2Warp | 0 | 43396 |
| Yanguas,Sonlui | 0 | 37020 |
| Lijealso | 0 | 34157 |
| Rei-artur | 0 | 33863 |
| Tumnus | 3 | 33213 |
| Nuno Tavares | 0 | 31910 |
| Bisbis | 0 | 29886 |
+----------------+----------------+-------+
10 rows in SET (0.76 sec)

Os resultados completos estão aqui.

Já agora, para finalizar, a tão afamada lista de wikipedistas por número de edições:

PLAIN TEXT

MySQL:

mysql> CREATE TABLE edits_per_user SELECT rev_user,count(1) as counter FROM revision GROUP BY rev_user;
Query OK, 119134 rows affected (12.61 sec)
Records: 119134 Duplicates: 0 WARNINGS: 0
mysql> SELECT u.user_name,epu.counter
-> FROM edits_per_user epu
-> LEFT JOIN user_bots ub on ub.bot_user_id = epu.rev_user
-> JOIN user u on epu.rev_user = u.user_id
-> WHERE ub.bot_user_id IS NULL ORDER BY counter desc limit 10;
+----------------+---------+
| user_name | counter |
+----------------+---------+
| anonymous | 3119758 |
| EMP,Nice poa | 176338 |
| OS2Warp | 163751 |
| Dantadd | 105657 |
| Lijealso | 90025 |
| Yanguas,Sonlui | 89152 |
| Rei-artur | 83662 |
| Mschlindwein | 75680 |
| Bisbis | 75361 |
| Nuno Tavares | 73141 |
+----------------+---------+
10 rows in SET (0.05 sec)

Os resultados completos estão aqui.

Revisita aos dados estruturados

ntavares — Sat, 03 Oct 2009 14:36:47 +0000

Há alguns dias num mergulho profundo sobre a utilização de wikis em campos específicos deparei-me com uma "foto" da Wikipédia muito interessante, aqui, que ilustra, entre outras coisas, a actividade na Wikipédia, a vários níveis: Visualizing Science & Tech Activity in Wikipedia:

Fonte: A Beatiful WWW

O website, A Beatiful WWW, dedica-se à extracção e representação dos volumes de informação distintos que conhecemos hoje. Eu já tinha falado nisto e descobri, entretanto, que o Google disponibiliza uma API de representação de dados estruturados.

Consigo pensar numa série de brincadeiras para isto Imaginem, por exemplo, juntar isto tudo, logo agora que a Wikimedia vai estar empenhada em manter os conteúdos disponíveis no Amazon Public Data Sets!..

Olhem aqui um exemplo do que pode ser feito, desta vez com Hadoop e Hive: Hot Wikipedia Topics, Served Fresh Daily.

Importing wikimedia dumps

ntavares — Mon, 28 Sep 2009 01:48:26 +0000

We are trying to gather some particular statistics about portuguese wikipedia usage.
I proposed myself for import the ptwiki-20090926-stub-meta-history dump, which is a XML file, and we'll be running very heavy queries (it's my task to optimize them, somehow).

What I'd like to mention is that the importing mechanism seems to be tremendously simplified. I remember testing a couple of tools in the past, without much success (or robustness). However, I gave a try to mwdumper this time, and it seems it does it. Note however that there were schema changes from the last mwdumper release, so you should have a look at WMF Bug #18328: mwdumper java.lang.IllegalArgumentException: Invalid contributor which releases a proposed fix which seems to work well. Special note to its memory efficiency: RAM is barely touched!

The xml.gz file is ~550MB, and was converted to a ~499MB sql.gz:

1,992,543 pages (3,458.297/sec), 15,713,915 revs (27,273.384/sec)

I've copied the schema from a running (updated!) mediawiki to spare some time. The tables seem to be InnoDB default, so let's simplify I/O a bit (I'm on my laptop). This will also allow to speed up loading times a lot:

PLAIN TEXT

MySQL:

mysql> ALTER TABLE `TEXT` ENGINE=Blackhole;
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 WARNINGS: 0
mysql> ALTER TABLE page DROP INDEX page_random, DROP INDEX page_len;
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 WARNINGS: 0
mysql> ALTER TABLE revision DROP INDEX rev_timestamp, DROP INDEX page_timestamp, DROP INDEX user_timestamp, DROP INDEX usertext_timestamp;
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 WARNINGS: 0

The important here is to avoid the larger I/O if you don't need it at all. Table text has page/revision content which I'm not interested at all. As regarding MySQL's configuration (and as a personal note, anyway), the following configuration will give you great InnoDB speeds:

PLAIN TEXT

CODE:

key_buffer = 512K
sort_buffer_size = 16K
read_buffer_size = 2M
read_rnd_buffer_size = 1M
myisam_sort_buffer_size = 512K
query_cache_size = 0
query_cache_type = 0
bulk_insert_buffer_size = 2M
innodb_file_per_table
transaction-isolation = READ-COMMITTED
innodb_buffer_pool_size = 2700M
innodb_additional_mem_pool_size = 20M
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 0
innodb_doublewrite = 0
skip-innodb-checksum
innodb_locks_unsafe_for_binlog=1
innodb_log_file_size=128M
innodb_log_buffer_size=8388608
innodb_support_xa=0
innodb_autoextend_increment=16

Now I'd recommend uncompress the dump so it's easier to trace the whole process if it's taking too long:

PLAIN TEXT

CODE:

[myself@speedy ~]$ gunzip ptwiki-20090926-stub-meta-history.sql.gz
[myself@speedy ~]$ cat ptwiki-20090926-stub-meta-history.sql | mysql wmfdumps

After some minutes on a Dual Quad Core Xeon 2.0GHz and 2.4 GB of datafiles we are ready to rock! I will probably also need later the user table, which Wikimedia doesn't distribute, so I'll rebuild it now:

PLAIN TEXT

MySQL:

mysql> ALTER TABLE user modify COLUMN user_id INT(10) UNSIGNED NOT NULL;
Query OK, 0 rows affected (0.12 sec)
Records: 0 Duplicates: 0 WARNINGS: 0
mysql> ALTER TABLE user DROP INDEX user_email_token, DROP INDEX user_name;
Query OK, 0 rows affected (0.03 sec)
Records: 0 Duplicates: 0 WARNINGS: 0
mysql> INSERT INTO user(user_id,user_name) SELECT DISTINCT rev_user,rev_user_text FROM revision WHERE rev_user <> 0;
Query OK, 119140 rows affected, 4 WARNINGS (2 min 4.45 sec)
Records: 119140 Duplicates: 0 WARNINGS: 0
mysql> ALTER TABLE user DROP PRIMARY KEY;
Query OK, 0 rows affected (0.13 sec)
Records: 0 Duplicates: 0 WARNINGS: 0
mysql> INSERT INTO user(user_id,user_name) VALUES(0,'anonymous');
Query OK, 1 row affected, 4 WARNINGS (0.00 sec)

It's preferable to join on INT's rather than VARCHAR(255) that's why I reconstructed the user table. I actually removed the PRIMARY KEY but I set it after the process. What happens is that there are users that have been renamed and thus they appear with same id, different user_name. The query to list them all is this:

PLAIN TEXT

MySQL:

mysql> SELECT a.user_id,a.user_name FROM user a JOIN (SELECT user_id,count(1) as counter FROM user GROUP BY user_id HAVING counter > 1 ORDER BY counter desc) as b on a.user_id = b.user_id ORDER BY user_id DESC;
....
14 rows in SET (0.34 sec)
mysql> UPDATE user a JOIN (SELECT user_id,GROUP_CONCAT(user_name) as user_name,count(1) as counter FROM user GROUP BY user_id HAVING counter > 1) as b SET a.user_name = b.user_name WHERE a.user_id = b.user_id;
Query OK, 14 rows affected (2.49 sec)
Rows matched: 14 Changed: 14 WARNINGS: 0

The duplicates were removed manually (they're just 7). Now, let's start to go deeper. I'm not concerned about optimizing for now. What I wanted to run right away was the query I asked on Toolserver more than a month ago:

PLAIN TEXT

MySQL:

mysql> CREATE TABLE `teste` (
-> `rev_user` INT(10) UNSIGNED NOT NULL DEFAULT '0',
-> `page_namespace` INT(11) NOT NULL,
-> `rev_page` INT(10) UNSIGNED NOT NULL,
-> `edits` INT(1) UNSIGNED NOT NULL,
-> PRIMARY KEY (`rev_user`,`page_namespace`,`rev_page`)
-> ) ENGINE=INNODB DEFAULT CHARSET=latin1 ;
Query OK, 0 rows affected (0.04 sec)
mysql> INSERT INTO teste SELECT r.rev_user, p.page_namespace, r.rev_page, count(1) AS edits FROM revision r JOIN page p ON r.rev_page = p.page_id GROUP BY r.rev_user,p.page_namespace,r.rev_page;
Query OK, 7444039 rows affected (8 min 28.98 sec)
Records: 7444039 Duplicates: 0 WARNINGS: 0
mysql> CREATE TABLE edits_per_namespace SELECT STRAIGHT_JOIN u.user_id,u.user_name, page_namespace,count(1) as edits FROM teste JOIN user u on u.user_id = rev_user GROUP BY rev_user,page_namespace;
Query OK, 187624 rows affected (3.65 sec)
Records: 187624 Duplicates: 0 WARNINGS: 0
mysql> SELECT * FROM edits_per_namespace ORDER BY edits desc limit 5;
+---------+---------------+----------------+--------+
| user_id | user_name | page_namespace | edits |
+---------+---------------+----------------+--------+
| 76240 | Rei-bot | 0 | 365800 |
| 0 | anonymous | 0 | 253238 |
| 76240 | Rei-bot | 3 | 219085 |
| 1740 | LeonardoRob0t | 0 | 145418 |
| 170627 | SieBot | 0 | 121647 |
+---------+---------------+----------------+--------+
5 rows in SET (0.09 sec)

Well, that's funny Rei-artur's bot beats all summed anonymous edits on the main namespace I still need to setup a way of discarding the bots, they usually don't count on stats. I'll probably set a flag on the user table myself, but this is enough to get us started..

A importância da Wikipédia enquanto fonte de dados e não [tanto] de informação

ntavares — Mon, 10 Aug 2009 02:08:02 +0000

Tão cedo comecei a ganhar destreza na Wikipédia, não pude evitar lamentar-me com o desperdício, em termos de esforço, da criação de artigos em texto corrido a partir de dados na forma bruta - não havia, aparentemente, grande forma de contornar. Com efeito, os artigos da Wikipédia são pautados por relações intrínsecas de dados sobre determinado assunto, e digeridos numa determinada língua para que nos sejam facultados na forma de informação, o que faz com que se tornem mais ou menos eloquentes, menos brutos, mas menos isolados, menos reutilizáveis. Por exemplo, IIRC Jorge, um dos pioneiros da Wikipédia lusófona, teve um esforço imenso em criar as Freguesias e Municípios de Portugal, em pequenos, sucintos, artigos com tanto português quanto se poderia gerar a partir de alguns dados do INE. O problema é que os anos iriam passar, e não haveria forma de actualizar esta informação a não ser fazendo-o manualmente um a um, porque entretanto alguém mudaria o formato do português. Mais tarde, no projecto da criação dos municípios brasileiros, orientado IIRC pelo E2m, alguém se terá apercebido desta dificuldade, e surgiram então os artigos com horríveis marcações (exemplo), provavelmente para alimentar bots que fariam parsing dos dados e fariam a substituição. Mas neste caso, como alguém barafustou meses mais tarde, a edição tornava-se terrível especialmente para os novatos, que se a medo editavam, então quando viam aquelas marcações fugiam!

Demorar-me-ia apenas 6 meses a aprender a trabalhar com bots e a perceber a utilidade das predefinições - a tal ponto que era conhecido pelo maluquinho das predefinições [desculpem não facultar referências, mas teria que procurá-las nos primórdios dos meus milhares de edições...] - para convencer-me que "já que perdemos tempo a fazer isto, faça-mo-lo de forma estruturada, aproximando-nos da linguagem das máquinas, sem prejuízo para a edição, e lancei-me no esforço de fazer isso mesmo: ressuscitando as freguesias e municípios com dados estrutrados.

Terminada esta tarefa, foi altura de iniciar a criação de artigos com base na informação estruturada, mantendo-a siponível (na verdade, houve séries de artigos que foram mesmo feitos com predefinições e, com uma passagem final, foram instanciados com subst:). Mas a informação estruturada iria agora manter-se, e mesmo que não constasse no texto corrido, seria sempre acessível (e facilmente actualizável) nos quadros informativos - basta correr um bot com um simples search & replace por dados actualizados.

Creio que hoje, quiçá por estar mais normalizado em termos de estética (o pessoal, sem querer, foi-se habituando a estes quadros informativos) do que pelos benefícios tecnológicos, já poucos ousam fazer qualquer artigo deste género (do género que se baseia em dados estruturados para constituir informação) sem uma predefinição: temos as Cidades, os Animais (sempre difíceis devido às várias formas de classificação, mas enfim..), os Asteróides, etc.

Mas isto porquê? Porque hoje descobri um projecto interessantíssimo: a DBpedia que, segundo a visão do Tim Berners-Lee, o autor da World Wide Web, é o primeiro passo para aquilo que ele chama de Linked Data: chegámos a um ponto em que as interrelações de informação estão mais do que estabelecidas - mas e as interrelações de dados? O engraçado é que somos vários a pensar assim: OK, uma página web tem, de facto, informação, mas como é que podemos usá-la fora do contexto dessa página - e em grandes quantidades? Será que esses dados - e o esforço de publicá-los - estão condenados a serem só aquilo: inúteis para terceiros? É que extrair informação de páginas de múltiplas fontes não-estruturadas é virtualmente impossível (pode bastar mudar uma vírgula ou uma cor de texto para que o parsing falhe) e obrigar cada pessoa que deseje usar a informação a ter que construir mecanismos que extraia essa informação parece-me um gigantesco desperdício de recursos.. aliás, uma das aplicações que se projectava para o XML/XSL é que ele substituísse o HTML mais tarde ou mais cedo, mas parece que isso nunca vai acontecer.

Então o que Tim Berners-Lee propõe é que a disseminação da informação seja complementada com os dados em bruto que a gerou - ou disponibilizada de forma a que estes possam ser reutilizáveis. E isto é particularmente importante num momento em que há imensas comunidades a gerar conteúdo - é curioso como do trabalho humano passámos para o PC e evoluímos para arquitecturas distribuídas e de escala, e destas evoluímos para plataformas distribuídas em que o factor humano pode ser também (novamente) gerador de substância a uma escala muito, muito maior... mas isto é outro post, noutro dia..

Deixo-vos este artigo interessante sobre a Web semântica, onde se expõem várias formas de relacionamento de dados que se podem obter da web, de forma semântica, e como eles estão (ou podem vir) a ser utilizados:

Vale a pena ver, especialmente para quem, como eu, acha que vivemos numa era dos diabos em que tudo pode acontecer, inclusivé uma

Web [in which computers] become capable of analyzing all the data on the Web

Tim Berners-Lee, 1999

Google Translator Toolkit

ntavares — Fri, 07 Aug 2009 18:55:25 +0000

Traduzir artigos de outras Wikipédias para a Wikipédia da Língua Portuguesa é uma forma corrente de, pelo menos, dar um arranque aos artigos com conteúdo. Tomei agora conhecimento do Google Translator Toolkit que, muito embora proponha traduções simplistas, decerto irá ao encontro de muitos editores: torna possível rever e retocar a tradução — que é como sabemos — em dual view, para além de integrar um dicionário de acesso rápido.

Mas o que é fantástico é que a Google propõe aproveitar as correcções para melhorar o seu próprio motor de tradução. Mais um brilhante exemplo de como as comunidades podem gerar mais-valias para os projectos, ao contrário da visão tradicional. Aqui fica o vídeo de demonstração.

Ainda não testei, mas está na calha