Extension:Translate/Mass migration tools/pt-br

Esboço do projeto

A extensão do MediaWiki Translate tem um recurso de tradução de páginas, que permite a tradução estruturada das páginas wiki. Isso torna a tarefa de tradução mais fácil, fornecendo uma interface amigável que consiste em cadeias de texto divididas em unidades de tradução. Conteúdo não-traduzível (por exemplo, imagens) é excluído do processo de tradução. Embora isso torna o trabalho mais fácil com um rico editor que suporta vários idiomas, um grande esforço é necessário para preparar a página para tradução, ou seja, a página em questão em primeiro lugar precisa ser convertida para um formato que seria reconhecido pela extensão Translate. O processo de preparação da página para tradução precisa levar em consideração diversas marcações, o que acaba se tornando uma tarefa tediosa quando feito manualmente. Além disso, wikis têm uma grande quantidade de conteúdo legado que ainda precisa ser preparada para tradução.

Assim, com essa motivação, o projeto tem como objetivo facilitar a conversão e, assim, economizar tempo manual e esforço. A ferramenta desenvolvida, portanto, tornaria a página traduzível, e uma vez que isso é feito, importaria as traduções (que estavam presentes antes de a página se tornar traduzível) para a extensão Translate. Assim, todo o processo de importação de traduções, que envolveu uma quantidade significativa de esforço manual fica automatizada por este projeto.

Bug no Bugzilla

• Questão geral: Bug #46645
• Tickets para o projeto: [1] (por prioridade)
• Ajude com os testes e forneça um feedback
  • Use http://pagemigration.wmflabs.org
  • Reporte um bug: [2]
  • Vigie esta página e comente na página de discussão

Tópico na lista de discussão

Anúncio no Wikitech-l

Participação

O IRC tem sido sempre a minha primeira opção sempre que eu estou preso em alguma coisa. Nunca hesite em fazer perguntas, no entanto, elas podem ser tolas. Eu estaria disponível no IRC com o apelido BPositive em canais como #mediawiki, #mediawiki-i18n, #wikimedia-dev. Também estou inscrito em listas de endereços diferentes, tais como wikitech-l, mediawiki-i18n, translators-l, Mediawiki-India e eu gostaria de receber todas as discussões relacionadas com o meu projeto a ser desenvolvido nos canais de IRC acima mencionados e listas de discussão.

Tenho um blog onde posso atualizar todo o progresso do meu projeto proposto. Também gostaria de escrever relatórios semanais/mensais no próprio MediaWiki para manter a comunidade atualizada sobre o projeto.

Abordagem

O projeto visa a criação de uma ferramenta que irá funcionar essencialmente como segue:

Passo 1: Deixe a página traduzível: Isso envolve

1. A obtenção o texto de origem bruto da página em questão. Isto pode ser feito utilizando a API de análise
2. A remoção da predefinição {{Languages}}, se presente, e a adição da tag <languages/> no topo da página
3. A adição das tags <translate>.....</translate>
4. A conversão dos vários elementos em seus equivalentes traduzíveis como por exemplos de marcação. (Basicamente, para abreviar, este passo da ferramenta converteria o manual de documentos em código, de acordo com o meu entendimento)
5. A adição de {{Langcat}} para todas as Categorias
6. Uma vez que todas as mudanças necessárias foram feitas, a página em questão seria salva com o texto atualizado, após a confirmação do usuário.

A página agora está pronta para tradução. O usuário pode marcar a página para a tradução agora, após o qual a extensão Translate irá realizar o seu trabalho de dividi-la em unidades de tradução.

Passo 2: Importe as traduções: Isso envolve

1. A obtenção da lista de idiomas nos quais existe a tradução para a página em questão
2. Para cada um dos idiomas:
   1. Pegue a versão mais recente da página antes da edição do bot FuzzyBot
   2. Copie as traduções presentes naquela versão, unidade por unidade, para a extensão Translate. Isso pode ser feito através da comparação dos comprimentos, verificando se a string contém links que apontam para a mesma página. Isso indicaria uma correspondência e uma série de caixas de seleção e/ou slides de correspondência mapeamento podem ser fornecidos ao usuário. Outra maneira de fazer isso seria a de traduzir o texto em Inglês usando uma interface de tradução automática fornecido pela extensão Content Translation e compará-lo com a versão traduzida que temos. Desempenho, precisão e facilidade de uso serão os fatores decisivos. Veja também /Design/.
   3. Crie a página correspondente do formato Translations:Page/<translation unit identifier>/<language code> e salve-a.

Ao final desta etapa, as traduções foram importadas para a extensão Translate.

Cada uma destas sub-etapas implicaria considerar várias possibilidades e casos de restrições, que seriam tratadas no decorrer do projeto.

Entregas

Ainda mais refinado em /Requirements/

• Usuário do sistema: Administrador de tradução

1. The Migration Tool: A ferramenta faria o trabalho de backend, como já mencionado na seção 'Abordagem'. Isto pode ser implementado -
   1. Como um script PHP do lado do servidor: Se implementado como um script PHP, a ferramenta seria chamado como o "MigrationBot ', e todas as edições seriam salvas sob o nome do bot. O script seria uma parte da base de código da extensão Translate. Isto tem a vantagem de melhor acesso aos dados, mas ao mesmo tempo tem os inconvenientes da dificuldade de implantação e atraso no teste.
   2. Como um gadget JavaScript: Se desenvolvido como um gadget JS, as edições seriam feitas na conta do usuário. Isto tem a vantagem de fácil acesso aos dados. A implantação e os testes seriam mais rápidos em comparação com o primeiro método.
2. Uma interface de usuário pedindo confirmação, mostrando as mudanças feitas na "Etapa 1 - Preparação da página para a tradução". Isto pode ser realizado por:
   1. Simplica em re-oferecer a janela de edição para o usuário. O usuário iria rever as alterações feitas e salvar o texto utilizando o botão "Salvar página"
   2. Oferecendo a janela de edição integrada com algum editor que tenha destaque de sintaxe, como o CodeEditor. Isso faria o trabalho de um administrador de tradução mais fácil, com destaque para as alterações feitas pelos dois
   3. Uma série de janelas de confirmação mostrando cada passo realizado pela ferramenta. Embora isso tornaria mais fácil para o usuário analisar as alterações, ele pode ficar chato, às vezes. Além disso, verificar cada uma das sub-tarefas executadas e, em seguida, combinar, tornaria a tarefa de outra forma simples mais complicada.
3. Uma interface de usuário pedindo confirmação para as traduções importadas no "Passo 2". A interface visaria eliminar a guia de comutação + tarefa copiar e colar e, assim, teria o texto do idioma de origem e o texto do idioma de destino, além de um ao outro com botões "Sim" e "Não".
   1. Ao selecionar "Sim", a tradução importada seria salva, criando a página correspondente
   2. Ao selecionar "Não", os blocos do lado direito seriam autorizados a dividir ou arrastar e soltar para coincidir com os blocos correspondentes.

Casos de Uso

Uma captura de tela mostrando o link "Preparar para Tradução" em Ferramentas.

Uma tela que permite ao usuário confirmar as modificações feitas pela ferramenta de migração. As mudanças feitas pela ferramenta estão sublinhadas em azul.

Um design de maquete mostrando o texto original e as traduções importadas para o idioma selecionado. O usuário pode confirmar as importações ou reprova-las.

Os seguintes eventos poderiam ocorrem durante a migração da página:

1. The tool would be invoked in one of the following ways:
   1. Placing a link under the "Tools" section in the left hand side panel
   2. Providing a button in the editing window
2. Confirmation screens for step 1 would be shown
3. The user would confirm the changes made in the text and then mark the page for translation
4. The Translate extension would split it into translatable units
5. Upon confirming the splitted units clicking the "Save page" button, one of the following will occur:
   1. The step 2 would be triggered and imports will commence
   2. A dialog box saying something like, "It seems this page already had some translations. Do you want to import them to this system now?" would be shown. If 'Yes', the imports will commence and if 'No', a link under Tools would be added for access in the future (or a message at the top of the page in).
6. Confirmation screen(s) for step 2 would be shown

The same has been depicted in the sequence diagram below:

If time permits

If things go as planned and I still have some time, I would be completing one or more of the following task(s):

1. Implementing an automatic feedback system for the second part of the project. A database would be created, which would store user feedback on how they think the tool should have detected the unit correctly. This feedback would help in tweaking the detection algorithm for step 2.
2. Allow the imported translations to be corrected in the confirmation screen itself by making them editable. This would help to complete the process in the confirmation screen itself rather than going to Special:Translate.

Project Schedule

From-To Date	Timeline
Until Apr 22	Thoroughly reading the existing documentation related to Translate extension, learning the coding conventions and setting up the coding environment
Apr 23 to Apr 25	Gathering of requirements from end users and documenting them
Apr 28 to May 2	Designing the algorithm for the Migration Tool
May 3 to May 5	UI Designing for the confirmation screens
May 6	Development of a module to access the raw source text of a wiki page
May 7 to May 28	Coding of the confirmation and publishing screens related to Step 2, with basic initial import of old text
May 29 to June 7	Coding rest of Migration Tool - Step 2, particularly a better initial alignment of the units
June 8 to June 22	Coding of the Migration Tool - Step 1, taking into consideration all possibilities and corner-cases
June 23 to June 24	Midterm Evaluation
June 25 to July 7	Coding of the Confirmation screens related to Step 1
July 7 to July 12	UI Enhancements
July 12 to July 19	Documenting the code completely, writing unit tests
July 19 to July 26	Unit testing of the code and gathering bugs/errors
July 26 onwards	Bug fixing and improving the documentation
August 11	Pencils Down
August 22	Submitting code samples to Google

Notes:

1. During the Requirement Gathering Phase, I will keep working on the next task in parallel
2. After July 7, I might have reduced working hours (30 hours per week), as I will be moving to a new city. I will be working after my office hours, but I ensure that the tasks planned will be completed on time. The project schedule has been planned accordingly.
3. I plan to write the documentation and unit tests as the project goes along.

Personal information

Identificação

Nome: Pratik Lahoti
Email: pr4tiklahoti@gmail.com
Título do projeto: Tools for mass migration of legacy translated wiki content

Contato/informações de trabalho

Fuso horário: UTC+5:30 (IST - India)
Typical working hours: 10:00 to 14:00 (IST) and 20:00 to 2:00 (IST) (however, can adjust and go beyond if required)
IRC or IM networks/handle(s): BPositive (freenode)
I have a stable internet connection at home without any proxy issues. So, connectivity won't be an issue at any point of time

Mentores

Niklas Laxström e Federico Leva são meus mentores neste projeto.

Sobre mim

I am Pratik Lahoti, from Pune, India. I am a final year Information Technology student from College of Engineering, Pune. I am known on all wikis as BPositive, and that's the attitude I carry with me! :) My journey on Wikipedia started as an editor. I was later selected as the Campus Ambassador for Wikipedia's India Education Program. I have also coordinated the WikiProject Indian Collaboration of the month whereby I carried out collaborations with editors from all over India. Owing to my contributions, I was fortunate to be a featured Wikimedian for the month of April 2012 on Wikimedia India. Contributing to FOSS projects, attending seminars, and involving more and more people in the movement has always been my passion!

I have met and worked with the WMF Language Engineering Team at hackathons held at Gnunify and their enthusiasm has been infectious! Hence, I would like to work with them.

Past Open Source Experience

I have been a promoter of FOSS in my college. I have conducted workshops for my juniors on subjects like "Introduction to FOSS", "Introduction to Vim", "Getting started with Git". I am also an active member of Google Developers Group Pune and have participated in a couple of hackathons and also attended several workshops. I have been attending Gnunify for the past four consecutive years and have interacted with many people from the Open Source community. I have also participated in the Translation sprint held by the WMF Language Engineering Team at Gnunify'13 and carried out translations for Marathi (mr) language on translatewiki.net.

Acknowledgment

I would like to thank my mentors, Niklas Laxström and Federico Leva for their valuable assistance in drafting this proposal and their time to time suggestions. I would also like to thank Sumana and Quim for helping me polish this proposal and ensuring that I complete the tasks on time. Finally, I would like to thank all the community members who provided help/feedback on the discussion page as well as on IRC.

Any other info

Microtasks performed

• Solved some bugs related to the Translate extension
• Wrote a UserScript which returns the revision before FuzzyBot's edit on the page, if at all it exists. This would be the first step of the second part of the project - importing translations.
• Manually migrated wiki pages (and will be doing more before project starts)

Project Experience

• Participated in Google Cloud Developer Challenge 2013 and one of the developers of Direct2Drive
• Internship at Eaton Corporation - Developed a time tracking application for the employees of Eaton
• Personalized News Reader, a web application which uses Facebook page likes and Twitter followers to generate relevant news for the user. Also, I used Neo4j - a graph database for this project.

Emergency plan

I am positive about the project getting over by the end of the program but due to some unavoidable circumstances, if I am not able to do so, I will unconditionally work on it after the program gets over and complete it.

Post GSoC plans

I hereby announce that once the project is over, I would like to take the responsibility of the tool developed and thereby maintain it, address bugs and any other concerns from the community.