VisualEditor/Roadmap/Update 2016-06-23/pt-br

A todos,

Pensei que seria bom enviar uma atualização sobre o software de edição. Já se foi um ano desde a última atualização, e coisas mudam (e muitos estão sem saber o que já mudou). Definimos objetivos importantes sobre edição no plano anual da Fundação Wikimedia para o próximo ano fiscal. Esta atualização detalhará mais um pouco essa definição, com ênfase particularmente na equipe diretamente trabalhando nas ferramentas de edição de conteúdo. Há um roteiro mais breve e direto disponível no MediaWiki.org caso tenham interesse.

Situação
Nós, da equipe de Edição, estamos continuando a trabalhar com nosso compromisso da estratégia comunitária de 2010 para criar um editor visual em que o(a) usuário(a) possa editar todo o conteúdo sem ter de saber usar wikitexto, bem como para publicar nosso fluxo de trabalho para interessados. Nosso editor está em progresso; assim como todas as nossas melhorias ao software, nunca as “concluiremos”, e esperamos que vocês notem melhorias com o tempo. Toda semana, novos recursos, melhorias e correções são lançadas, geralmente guiadas, alteradas ou apoiadas por nossos desenvolvedores voluntários e pioneiros da comunidade; meus agradecimentos a vocês.

Estamos agora há aproximadamente cinco anos trabalhando nesse editor visual, e fizemos um bom progresso na entrega de um editor de conteúdo com credibilidade para ajudar no fluxo de trabalho de vários usuários, fazendo com que editores passem mais tempo em o que estão editando ao invés de como. Em primeiro lugar, não precisar pensar no capricho com o wikitexto e sim enfocar no conteúdo a ser trabalhado é algo que muitos voluntários, novos ou experientes, mencionaram que queriam. A ferramenta de citações automáticas faz com que a adição de novas referências a sites ou a DOIs seja muito mais rápida e completa, melhorando a qualidade do conteúdo. Já a ferramenta de pesquisa visual de mídias simplifica o encontro e inserção de ótimas imagens ou outras mídias no Commons. A edição visual de tabelas faz com que modificações em tabelas, como mover colunas ou outras partes, serem muito mais fáceis do que com wikitexto, economizando o tempo de nossos voluntários para que foquem em seus trabalhos, melhorando nossas wikis.

O editor visual é compatível com vários (mas nem todos) idiomas, e graças ao auxílio e engajamento da comunidade, o editor está disponível por padrão em 235 Wikipédias (e como editor alternativo nas 55 restantes), incluindo quase todas as nossas maiores Wikipédias. Ele está disponível por padrão para usuários não autenticados e para novas contas em 233, e disponível para novas contas (não para usuários não autenticados) em duas, a inglesa e a espanhola. Nessa semana, foram incluídos representantes para cada língua do grupo “CJK”, com quatro escritas chinesas diferentes (clássico, cantonês, wu, e min do sul), japonês e coreano. No momento estamos trabalhando com as comunidades restantes, perguntando-as se já podemos ativar o editor visual como padrão lá; os próximos grupos serão treze Wikipédias com escritas árabes diferentes e vinte e três Wikipédias hindis. Veja detalhes mais específicos na grade de lançamentos.

Recentemente estivemos trabalhando com os projetos irmãos da Wikipédia. Como você pode imaginar, cada projeto tem necessidades, trabalhos e interesses diferentes, portanto é importante garantirmos que nossas ferramentas fornecidas estejam ajustadas para auxiliar (e não comprometer) os requisitos na medida em que a demanda justifica-os. Por solicitação da comunidade, o editor visual já esta disponível para todos os usuários dos mais variados projetos irmãos, porém achamos que há mais a ser feito antes que disponibilizemos em outras áreas. Recentemente estivemos trabalhando com as comunidades dos Wikivoyages, que têm necessidades quase iguais às Wikipédias; agradecemos a paciência e assistência dos usuários do Wikivoyage. Estamos também trabalhando com Tpt e outros voluntários que criam e mantêm o software usado pelos Wikisources para fazer com que o editor visual trabalhe com outros recursos; nossos agradecimentos a eles e aos usuários dos Wikisources.

Trabalho central e de manutenção
Apesar do progresso, ainda há várias áreas nas quais a função principal do software de edição precisa de extensões, melhorias e correções. Em muitos lugares do editor visual tivemos que trabalhar acerca de bugs, recursos faltantes e particularidades nos navegadores. Contudo, não há coisa mais problemática que digitação, “cursorização” e compatibilidade com idiomas diferentes. Infelizmente, ainda existem alguns erros sérios relacionados ao que foi mencionado, mas continuamos fazendo parcerias com fornecedores e experts de navegadores para que possamos desenvolver soluções e melhorias.

Outra área importante relacionada à compatibilidade de idiomas estará vindo com uma solução para nove línguas da família Wikimedia que usam variantes de idioma, como o chinês, que nos dá alguns desafios difíceis, já que é fundamentalmente incompatível com o método de edição visual. Se você tem interesse em discutir sobre como isso pode funcionar, estaríamos muito felizes de discutirmos com você quais possíveis opções poderiam funcionar de acordo com a sua opinião, e estaríamos mais felizes ainda se você quisesse nos ajudar a trabalhar na compatibilidade para tal.

A performance do software ainda não é como desejávamos que fosse em termos de agilidade, uso da rede e carregamento nos navegadores. Esse problema afeta a todos os usuários, ainda mais em dispositivos de baixa potência (como computadores antigos) ou em dispositivos com limite de recursos (como a maioria dos celulares e os tablets), onde em alguns casos nosso editor torna-se inútil, não só desrespeitando o tempo útil dos voluntários como proibindo e excluindo membros da comunidade de poderem voluntariar-se em seus tempos úteis. Temos várias estratégias para acabar com esses problemas, partindo de editar apenas algumas partes do documento por vez - também chamada de “edição frasal” - até carregar pequenas partes do editor primeiro e então as maiores e menos usadas, mantendo uma interface consistente, sem mudanças nela que possam parecer confusas. Amplamente falando, permitindo que o software inclua à comunidade o máximo número de voluntários possível, solucionará nossos problemas de acessibilidade de todas as formas, uma vez que editores com deficiência de aprender ou com deficiências físicas serão auxiliados o máximo possível.

Muitas de nossas comunidades deram um esforço significativo nos últimos quinze anos na apresentação de fluxos de trabalho especializados para suas wikis. Algumas vezes, tais esforços envolveram extensões e gadgets complicados, como o uso do botão “inputbox” para iniciar um novo artigo baseado numa predefinição, como usado em várias wikis. Outros forneceram ferramentas adicionais dentro do editor de wikitexto, como a ferramenta da Wikipédia inglesa para automaticamente criar referências baseadas em ligações, algumas das quais hoje são fornecidas dentro do editor visual. Porém, várias dessas ferramentas ainda não estão disponíveis no editor visual, e nem sempre conseguimos fornecer atenção individualmente para cada uma das centenas de wikis. Para que o editor visual obtenha sucesso, seja agradável e não confuso, é vital que ajudemos as comunidades no fornecimento de gadgets apropriados e que dupliquemos ou aumentemos a integração com os vários outros editores. Estamos ansiosos em ajudar você a ajudar outros.

Uma grande mudança que estamos esperando torná-la possível ainda esse ano (uma vez que já foi incluída no plano anual) é fazer uma engenharia reversa de como o MediaWiki lida com seu conteúdo. Queremos permitir que múltiplas “partes” do conteúdo sejam armazenadas como revisões das páginas. Este recurso já é muito esperado, mais ainda com páginas de arquivos - cada histórico de carregamento de um arquivo é mostrado separadamente de sua página de descrição, assim como as legendas dos vídeos são armazenadas noutro espaço nominal, ao invés de serem na mesma página. Esse problema também afeta outras áreas, tornando o fluxo de trabalho mais complicado, como as subpáginas de documentação comum das predefinições, ao invés de haver uma combinação entre a página da predefinição e a da documentação, tirando a necessidade de duas edições para melhorar uma predefinição e sua documentação. O trabalho da Wikimedia Alemanha em mover os metadados dos arquivos para uma estrutura própria vinculada ao Wikidata mostrou-nos que nossa mudança é possível. Estamos ansiosos em avançar com a discussão técnica e com a implementação das revisões com conteúdos de múltiplas partes no back-end, e temos algumas esperanças sobre como elas poderão ser usadas para fazer novas coisas, que discutiremos abaixo.

Agora, de volta ao nosso trabalho principal, a nossa intenção desde o início do nosso trabalho com o editor visual era fazê-lo operar em qualquer tipo de edição no MediaWiki, e não ser apenas outro editor. Dependendo de quais você considera, há atualmente, sem contar o editor visual, seis softwares de edição instalados na maioria das nossas wikis, que nos resulta em seis interfaces diferentes para confundir os usuários, seis conjuntos de bugs para resolver e seis lugares diferentes onde os recursos podem interagir de maneiras inesperadas. Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform. This has already been done for example in Flow, where it uses the visual editor for rich content editing rather than re-inventing its down, and we are planning to work with our colleagues in the Language Engineering team to do the same for the Content Translation tool. We are experimenting with providing a more modern wikitext editor which can provide a consistent experience between the visual and wikitext editors, and between desktop and mobile; there's a video of our work to date on this, still incomplete, which some of you may have seen. Naturally, any new wikitext editor would have to be not just change for its own sake but better for users to be worth switching, so we're cautious about how quickly we would introduce this; certainly, a beta feature test of the initial version for the intrepid will be necessary before we make any plans as to wider availability.

Feature work
As well as our core work, it is important to us that we also spend some of our time to explore ways in which new features can improve the experience of the site for users, helping them improve quality, breadth and depth of content more effectively and efficiently. Not all of the ideas below are ones on which we're actively working right now, but we should have some progress this coming year on at least most of them.

An idea I'm quite excited about in terms of possibilities is providing a system in the visual and wikitext editors that can prompt users as they edit. The range of different kinds of edit, from copy editing and improving references to a full up re-working of whole sets of pages, means that newbies can get lost in knowing where to start. There are lots of different kinds of improvements that we could provide, from simple static ones like "this article isn't illustrated yet" to very complex and specific ones like "this article's main wikiproject is about the USA, so wants you to write in American English". This work is aimed at reducing the burden on experienced users when they review new editors' changes, letting each wiki configure hints appropriate to that community. We also intend for these experiments to improve the "on-boarding" experience for new users, helping them learn what is wanted and valued by their wiki's community, and what makes for more constructive edits.

Once we have multi-part content streams (which I mentioned above as core work), there are several possible feature areas we think are worth considering.

A big one is that we think that there's a lot of potential in storing edits in HTML DOM as well as in wikitext. Firstly, this should allow us to help MediaWiki understand changes in edits more like the way that humans do. This would allow us to provide neat features like visual diffs and animated histories of pages. Showing clearly who wrote which parts of an article, or what parts of the article have been changed most recently, is not a new idea but hasn't been practical to implement at scale. It would be fascinating to see if this tool could assist in deepening the richness of understanding for readers of the staleness or volatility of articles in practice.

More importantly, it should allow much better automatic handling of edit conflict situations, and so reduce the occurrence of edit conflicts that need manual correction. Theoretically, it could let us remove edit conflicts entirely, though this would mean making some decisions about how edits work which we may decide are worse long-term than having manual resolution of edit conflicts; we're not planning to make a decision on that until we know more.

Storing pages in DOM could also allow smart partial document saving, splitting up your bigger edits into different chunks, each of which you can save as you go. Making smaller, simpler edits. This could also let us reduce edit conflicts by prompting people to save bits as they edit, and pushing those new versions "live" into the editor of others also editing at the same time.

The final thing I'll mention that DOM edits could do is allow DOM-based annotations to pages. With this, citations could be 'applied' to bits of the article showing which statements are (and aren't) backed up with a reference. Discussions could refer to a specific image, sentence or word choice to let editors have deeper, faster conversations, and understand when they're editing a potentially divisive section. Illustrations like diagrams and maps could highlight an area.

Another thing we're keen to explore with content streams is improving how page meta-data is edited, centralising the data about a page's name, protection level, whether it should show a table of contents, what pages redirect to it, and so on. Each of these examples is currently edited in a different place and with a different tool. We think it could help a lot to provide these controls together, editing a new "part" of the page alongside the wikitext block. Note that we're not planning on removing the existing mechanisms, which each work well enough – this would be an additional tool, at least at first.

A final item worth mentioning, because it comes up a lot as a technical/editor wishlist item from some editors and developers alike, is real-time collaborative editing. I wrote some details a couple of years ago about how this, especially the "full-throttle" collaboration system (like Etherpad or Google Docs, where there can be multiple users at the same time each with their own cursor) is a huge problem, not just a technical one but critically a social one. Despite this, I do hear quite often from people about how this would be very helpful, for mentoring new users and those doing something with which they're unfamiliar, and for content editing collaborating, like for edit-a-thons, breaking news articles where lots of changes are wanted at the same time, and themed collaborations of the day or similar. I'm keeping an open mind as to whether we will ever do this, but it's not something we're worrying about right now.

Sumário
As you can see if you have made it this far, there's a lot of different things we're working on in the department. I'm hopeful that the improvements we make have already made, and will continue to make, the editing lives of those reading this a bit easier.

I'm thankful for all the support we get from across the communities, be it in the form of clear suggestions, complaints and proposals, technical advice and volunteering, or anything else. If you're technical, and a current or prospective volunteer developer interested in working on some of these areas, we would love to help you.

I'll be at Wikimania this year. As always, I'll be happy to talk about anything in this update — or missing from it — in person there, online on Phabricator or IRC, on-wiki, or wherever else. Your thoughts and responses are what guide us, and what makes it worth doing. Hope this was interesting!

Ligações
"Original:"