Collaborative translation

One of the ideas to promote the translation of scientific articles is to create a collaborative translation tool. Producing a good translation needs a several skills, it needs skill in two languages and knowledge about the topic. Such a combination is easier to find in a team and working in a team motivates. People regularly make partial translations and stop when they know enough for themselves. It would be great if others could finish the job.

Existing translation tools

There are already many translation tools, but none really fit this use case. There is machine translation; for many language pairs this works quite well nowadays, but for scientific texts the system may trip up and accuracy is very important. So a machine translation is at best a first draft an expert should have a look at. When this quality is good enough, people will not need a collaborative translation tool, nor a translation published in a repository and findable via our translations database.

There are computer aided translation packages to help (team of) professional translators. These systems work with office file formats and HTML and tend to be proprietary and thus cannot be improved to fit our use case. The break the text up in segments (paragraphs) to be translated piece by piece. They do have many tricks that would be worthwhile to implement in a collaborative system as well, such a databases with phrases to ensure they are consistently translated. Also the data formats can be used as inspiration. The only exception to this rule seems to be OmegaT, a FOSS project coded in Java. A remaining problem could be that such systems are intended for professionals and may have a steep learning curve.

Tools for the translation of software packages (their user interface and documentation) is often collaborative, tends to be easy to use and sometimes even somewhat gamified. In addition these systems are often free software and could thus be improved. This may thus come closest to a collaborative tool for scientific articles, but these tools only work with nicely structured text files for in- and output, while scientific articles will have equations, tables, references, and figures and will often not even be available in a text format, but some sort of PDF file.

Putting it all together

So a collaborative translation tool would live on the internet and combine features of the computer aided translation packages and the software translation packages, while having additional tools to parse article PDFs into a text format and afterwards put the translated article together.

In future Single Source Publishing will make input and output easier and some journals already provide scientific articles in HTML or XML formats, but for now we will also need tools to work with PDFs. For old articles we will even have to work with PDFs that are just scans of paper articles and need OCR.

An internet tool that does this is PaperToHTML. On the Open Science Feed someone mentioned several tools that may work.[1] There is Grobid, which converts the PDF to a very detailed XML format, but may not preserve formatting such as italics. Allen AI, the team behind Semantic Scholar, build on Grobid to create their own tool, which may be easier to use. Also CrossRef has a tool to convert PDFs into JSON called pdfextract. A further option is Cermine. There are also Python tools to extract text from PDFs.

Both for input and output the Swiss knife of document conversions pandoc can be helpful. The same developer has build a scientific MarkDown tool on top of pandoc called Zettlr. Scientific markdown could be a good option as the translation format because it is text, so would work well with existing software for code, while it can handle equations, tables, figures and references natively. There is a also already a collaborative scientific markdown pad.

The collaborative tool should allow for communication between translators in general (for coordination of the work and community building) and discussions on specific translated sentences. Preferably this communication would work for two people as well as for entire classes jointly translating an article. It should be able to upload partial translations and have a page showing partial translations where people can help out.

It would save a lot of time for many translations to have a first draft translated by machine learning tools. This should be checked by humans from accuracy, but a scientific article does not have to be beautiful prose, but clear. The user feedback in interactive machine translations can be used to improve the system and make it better at translating scientific works. The latter would require running the machine translation ourselves. It was suggested that this may require considerable resources, memory, computer power and bandwidth; maybe this could be obtained by collaborating with the European Open Science Cloud.

Points to ponder

Coming from the academic tradition, I would expect that translators would like to be named. However, we have seen with Wikipedia that many people are willing to work on big projects without getting personal credit, or at least without it being easily noticed. Not connecting your name and reputation to a translation can also lower the barrier to participate. One could try both system, but I expect that most translators will be academics (which is an assumption we should check) and would like credit. Still it is a good idea to implement this in a way that it is easy to opt out of being named.

Another design question is whether to use pure text for the translate or markdown. Using pure text would mean that words which are printed bold or italic would not have this markup in the translation (or this would have to be added in the post-processing after the system gives out an office, LaTex, XML or markdown file). In case of equations, tables and figures this would mean that the reader of the translation would need to use the original as well and only have translation support for captions, axis labels, legends and so on as descriptive text. The advantage is that pure text is much easier for the translator to handle.

Using MarkDown would tempt the translator to also recreate the equations and tables. The figures would still be like in the original with the translator describing the axis and legends, etc. Making equations and tables is quite involved and costs time even for someone well versed in markdown. Maybe we can set up the system in a way that translators would normally not try to do this by copying equations, tables and figures into the translation unchanged and ask for a description. The use of Markdown for italics and bold is quite easy to learn and if present in the original important to reproduce.