Advisory Panel Report

The original aims of the MOLTO project were to use the GF approach to provide high quality translations of texts in limited domains in real time, enabling an author to simultaneously produce versions of a text in multiple languages. These aims also included expansion to cover new languages, to enhance lexical and other resources, and to develop frameworks and training to simplify and make more productive the tasks of grammar development. Other aims included an investigation of the role of controlled languages in interaction with ontologies and other types of reasoning and knowledge representation systems, and to explore hybrid approaches to machine translation - to combine the precision of GF based translation with the coverage and robustness of statistical machine translation methods. The project also hoped via its industrial partners to demonstrate that GF applications could be of commercial value. Three case studies were envisaged: mathematical exercises (using the Sage framework) in 15 languages, patent data in at least 3 languages, and museum object descriptions in 15 languages.

Over the course of the MOLTO project much progress has been made in achieving the above goals. One of the challenges to building and maintaining hand-built grammar systems is managing the grammar development. The MOLTO project delivers a new set of development tools ranging from the cloud-based grammar editor to an integrated development environment plugin (Eclipse). The Grammatical Framework summer school continues to train new members of the community in developing the grammars using these tools. The development of a new translation system takes a matter of days; adding a new language to a system takes hours (once the resource grammar for the language exists). The most labor intensive part of the work is developing a resource grammar, which takes on the order of 3 to 9 months; once completed it is easily exploited through the MOLTO tools and existing systems based on MOLTO technology can utilize the new language (for translation, generation, or information access).

In order to ease the development of multilingual grammars (and domain specific resource grammars) MOLTO delivers tools and techniques to expand the lexicons. One approach iis to utilize translations of wordnet which maintain links across the lexical entries. This allows the grammar developer to write sense-disambiguated translation lexicons.

In the final year of the project, a robust parser for the Grammatical Framework grammars was developed. This statistical parser bridges the gap between brittle hand-coded grammars and data-driven statistical parsers. The parser is capable of generating parse fragments even when a complete analysis is not available under the defined grammar. Performance is competitive with widely used systems like the Stanford parser.

MOLTO explored a variety of applications of the rich grammar formalism of GF along with the development tools. One focus was on the application to multilingual information access: the Ontotext ontologies, the Cultural Heritage retrieval and verbalization, and ACEWiki inference. While another focus was to expand the translation capabilities of GF by exploring the integration of GF and statistical machine translation techniques. Leveraging the strong syntactic typing from GF, the GF/SMT translation system was able to perform state-of-the-art translation for patents.

One of the industrial partners, beInformed, has successfully deployed systems based on MOLTO technologies to model their information and general customer-facing documents in multiple languages. The other industrial partner, OntoText, has detailed plans to include MOLTO technologies in its product line.

We were particularly impressed by the effort devoted to evaluation, particularly of translation, but also of other MOLTO applications such as business logic modelling. For translation, the original promise of the MOLTO project was to provide high quality precise translations, within limited domains. The various tests carried out with human judges largely seem to confirm that this goal has been achieved: whereas existing commercial systems provide wider coverage than the MOLTO tools, the quality of the results is not as high. Similarly, the comparison carried out by Be Informed of the MOLTO tools against their existing solution (Velocity) seems to confirm their superiority.

Overall we believe the project team are to be congratulated on what they have achieved over the course of the project: we regard the project as having successfully accomplished all of the goals it originally set for itself.

1. Project Objective

The EU project MOLTO - Multilingual Online Translation, started on March 1, 2010 and will run until June 2013.The Consortium, comprising the universities of Gothenburg, Helsinki and Polytechnical Barcelona together with the industrial Bulgarian partner OntoText, has been enlarged by the addition of University of Zurich and of the Dutch Be Informed.

MOLTO's multilingual translation tools use multilingual grammars based on semantic interlinguas and statistical machine translation to simplify the production of multilingual documents without sacrificing the quality. The interlinguas are designed to model domain semantics and are equipped with reversible generation functions: namely translation is obtained as a composition of parsing the source language and generating the target language.

An implementation of this technology is alread available in the Grammatical Framework, GF. As a result of the MOLTO project work, GF technologies are complemented by the use of ontologies, viewed as formalisms employed by the semantic web for capturing structural relations, and by methods of statistical machine translation (SMT) for improving robustness and extracting grammars from linguistic data.

MOLTO is committed to dealing with 15 languages, which includes 12 official languages of the European
Union - Bulgarian, Danish, Dutch, English, Finnish, French, German, Italian, Polish, Romanian, Spanish, and Swedish - and 3 other languages - Catalan, Norwegian, and Russian. In addition, there is constant on-going work on creating new resource grammars, in particular Arabic, Farsi, Hebrew, Hindi/Urdu, Icelandic, Japanese, Latvian, Maltese, Portuguese, and Swahili. The coverage and accuracy of the GF grammar library resource varies among the different languages and is documented on the web site of GF.

When comparing MOLTO to popular translation tools like Systran (Babelfish) and Google Translate, the main difference is the intended user of the tools: these tools target end-users of information whereas MOLTO targets producers of information.
By producers of information, MOLTO is able to handle well scenarios in which the language is constrained, as examples one may consider e-commerce sites, where products are often described with repeated linguistic expressions (e.g. Wikipedia articles, contracts, business letters, user manuals, and software localization), but even social networks often display usage of common phrases ("Happy birthday!" "I like it" "The hotel is located ...." "Your reservation is confirmed"). Ideally, MOLTO tools will enable publishers of websites to add multilinguality with little effort but most importantly with the certification that the meaning of the message conveyed stays unaltered across languages. MOLTO is also working on a multilingual semantic wiki .............

There is a well-known trade-off in machine translation: one cannot at the same time reach full coverage and full precision. In this trade-off, Systran and Google have opted for coverage whereas MOLTO opts for precision in domains with a well-understood codified language, either because it is of technical nature or because of common everyday usage.
The domains considered during the MOLTO project show a range of features of constrained natural languages: mathematical exercises and biomedical patents employ a technical and sophisticated jargon, whereas museum object descriptions use a language accessible to anybody.

2. Results

The expected final product of MOLTO is an open-source software suite of tools comprising a grammar development environment, an application programming interface and environment to assist the translators' workflow, and sample application grammar libraries for the domains of mathematical word problems, biomedical patents, and cultural artefacts.

Translation systems in MOLTO rely on multilingual grammars written in the GF programming language. Until now, the development environments available to GF grammarians consisted of a generic text editor, such as Emacs, used in combination with the GF interactive command shell, and the online GF documentation. This is a simple and effective environment for the experienced grammar developer. To better support less experienced grammar developers, one of the goals of the MOLTO project is to create an Integrated Development Environment for grammar development. The GF Simple Editor (by Thomas Hallgren), an initial prototype of a web-based grammar development environment that offers the same core functionality as the traditional environment is now available at http://www.grammaticalframework.org/demos/gfse. Its main features include grammar editing, grammar compilation, error detection, testing and visualization. Moreover, it enables the creation of web-based translation systems without installation of any software, as it is using web services to carry out compilation and interpretation tasks, and thus gives quick access to GF to novice and occasional users. Intended scenario for this editor is in supporting fast testing and prototyping of example grammars in tutorial settings, for instance during teaching and demonstrating GF.

A different, more sophisticated high-level integrated development environment is based on the Eclipse platform and specifically tailors GF grammar-writing. The GF Eclipse plugin (by John Camilleri) currently features real-time syntax checking, automatic code formatting, import-aware auto-complete suggestions, cross-reference resolution, inline contextual documentation, "New Module" wizards, external library browsing, launch shortcuts to the GF shell, and a visual tool for running treebank test suites. These new, powerful, time-saving development tools are aimed at both new users and GF veterans alike. It is available online at http://www.grammaticalframework.org/eclipse/ and at http://www.molto-project.eu/wiki/gf-eclipse-plugin.

Controlled natural languages are controlled subsets of natural languages, which are normally used in technical domains. The purpose of these languages is to reduce the complexity involved in natural languages, and to eliminate the ambiguity. The users of these languages are experts within their domain, and are trained to use these languages.

The MOLTO Phrasebook (by Aarne Ranta et al.) is one such controlled natural language, whose domain is that of touristic phrases. It covers greetings and travel phrases such as "this fish is delicious", "how far is the airport from the hotel" in 17 languages. The translations show the kind of quality that can be hoped for when using a GF grammar that can handle disambiguation in conveying gender and politeness, for instance from English to Italian. It is available both on the web from http://www.grammaticalframework.org/demos/phrasebook/ and as a stand-alone, offiline Android application, the PhraseDroid, from http://tinyurl.com/7tyzvfd. Screenshots of the mobile application are shown in the image on the side.

A different kind of controlled natural language is one that is used to command an interactive software system, for instance a computational engine such as Sage. The GFSage software application (by Jordi Saludes) shows a command-line tool able to take commands in natural language, have them executed by Sage, and have the answers rendered in natural language too. The image on the side shows the web interface of Sage augmented by the MOLTO natural language command module. Note that this application demonstrates how a MOLTO library can add multimodality to a system originally developed with keyboard input/output as user interface. In fact, by piping the results to a speech engine, one can have the results aurally thus increasing accessibility of the computational systems to the visually impaired. The natural language interface relies on the Mathematical Grammar Library that can be tested at http://www.grammaticalframework.org/demos/minibar/mathbar.html and documentation on the GFSage module is available as deliverable http://tinyurl.com/78bh4ap from the MOLTO wiki http://www.molto-project.eu/wiki/d62-prototype-comanding-cas.

To demonstrate the MOLTO Knowledge Reasoning Infrastructure, the Patent retrieval prototype (by Milen Chechev from Ontotext in collaboration with the UPC and the UGOT teams), at http://molto-patents.ontotext.com, shows examples of queries in natural language to a set of patents in the pharmaceutical domain. Users can ask question in French and English like 'what are the active ingredients of "AMPICILLIN"', 'que sont les formes posologiques de "AMPICILLIN"'. The system is still under development: at present the online interface allows to browse the retrieved patents and returns the semantic annotations that explain why any particular patent has matched the user's criteria. Similar technology for knowledge retrieval is being applied also in the case of cultural heritage, namely with descriptions of artefacts from the museum of Gothenburg, in order to allow multilingual query and retrieval. For this task, an ad-hoc ontology has been created and its preliminary GF application grammar can be tested by selecting "Painting.pgf" at http://www.grammaticalframework.org/demos/minibar/minibar.html.

The MOLTO translation environment is being developed (by UHEL with contributions of UGOT) as a customization the GlobalSight translation system (www.globalsight.com). The aim is to be able to embed MOLTO translation tools to a third-party translation platform. MOLTO tools are designed with a focus only on translation. GlobalSight is an open source translation management platform, which provides the infrastructure needed in a professional translation workflow. More specifically, a MOLTO translation editor will be available on the side of conventional editors and be characterized by the possibility of fetching terms from the FactForge ontology via the TermFactory database, allowing to import and export terms in TermFactory. Terminology work is also supported by OntoR, an ontology extraction system (by Seppo Nyrkkö) implemented as s semi-supervised machine learning process, where new term dictionary candidates may be found in given text, by finding "closest matches" in previously known _ontologies_ (i.e. hierarchical vocabulary, term structure, usually industry or domain specific). A corpus-harvested new term can be _aligned_ with its closest matches in an prior existing term ontology. New term's functional and semantic environment is analyzed, and the feature variables extracted are compared to values of previously known terms. The user is given the supervision control to decide the best alignment match and thus refine the ontology incrementally. These tools are not yet ready for distribution but a preview can be seen during the project meetings' open days.

3. Dissemination

The main dissemination venues for the results of MOLTO are the MOLTO website and the project meetings. The website at www.molto-project.eu makes available all the project’s results and advertises news, deliverables, and events organized by the partners. It also archives all MOLTO publications, both delivered at international meeting as well as at
internal workshops. The MOLTO news updates are posted as RSS feed suitable for aggregation by interested portals that is distributed by the MOLTO twitter feed and via the MOLTO LinkedIn group.

MOLTO sponsored the GF Summer School 2011, Frontiers of Multilingual Technologies during August 15-26, 2011 hosted by UPC in Barcelona, Spain. The two weeks program included lectures from "Getting started with GF", to "GF application development" and "Resource grammar development" and was attended by around 20 participants from around the world. The use case studies of MOLTO were amply presented by members of the Consortium. On August,1 2011 Aarne Ranta was invited to give a tutorial on GF during CADE-the 23rd International Conference on Automated Deduction, in Wroclaw, Poland. The lecturing material "Grammatical Framework: A Hands-On Introduction" is online. At the same meeting, Jordi Saludes has presented the Mathematical Grammar Library during the affiliated workshop THedu'11, Computer Theorem Proving Components for Educational Software. "A Framework for Improved Access to Museum Databases in the Semantic Web" was presented during the meeting Recent Advances in Natural Language Processing (RANLP 2011), in September 2011, at Hissar, Bulgaria. Similar work, "Reason-able View of Linked Data for Cultural Heritage" was presented during The Third International Conference on SOFTWARE, SERVICES & SEMANTIC TECHNOLOGIES, also in September, 2011 in Bourgas, Bulgaria. The MOLTO project was presented at Tsukuba University and during the meeting "Digitization and E-Inclusion in Mathematics and Science 2012" (DEIMS2012) in February 2012 in Tokyo Japan by Olga Caprotti.
Two demonstrations of MOLTO prototypes on query and retrieval in the cultural heritage and in the patent domains have been accepted for presentation at the European Track of the World Wide Web 2012 conference. A paper on GF, "Smart Paradigms and the Predictability and Complexity of Inflectional Morphology", will also be presented at the conference of the European Association for Computational Linguistics in April 2012.

The list of conference papers funded by MOLTO can be retrieved under Publication from the website.

Project meetings of MOLTO include always an open day with a program of presentations aimed at a general audience, the last MOLTO open days took place in Gothenburg on March 9, 2011 during the second project meeting, on September,2 2011 in Helsinki during the third project meeting, and on January,12 2012 in Gothenburg for the MOLTO-EEU kick off meeting.

4. Forthcoming

The project is looking forward to the final development phase especially with the addition of the new case studies, which will bring feedback to existing tools and ongoing work. In terms of events sponsored by MOLTO, the Third International Workshop on Free/Open-source Rule-based Machine Translation will take place in Gothenburg, Sweden, between 13-15 June 2012. Chair of the meeting is the MOLTO coordinator A. Ranta and local organization is managed by the MOLTO project manager. The fifth MOLTO project meeting will take place in September 2012 in The Netherlands in cooperation with the MONNET project. Stay tuned by subscribing to the MOLTO RSS feed or follow us on Twitter.

1. Final publishable summary report

This section must be of suitable quality to enable direct publication by the Commission and should preferably not exceed 40 pages. This report should address a wide audience, including the general public.

The publishable summary has to include 5 distinct parts described below:

• An executive summary (not exceeding 1 page).
• A summary description of project context and objectives (not exceeding 4 pages).
• A description of the main S&T results/foregrounds (not exceeding 25 pages),
• The potential impact (including the socio-economic impact and the wider societal implications of the project so far) and the main dissemination activities and exploitation of results (not exceeding 10 pages).
• The address of the project public website, if applicable as well as relevant contact details.

Furthermore, project logo, diagrams or photographs illustrating and promoting the work of the project (including videos, etc…), as well as the list of all beneficiaries with the corresponding contact names can be submitted without any restriction.

2. Use and dissemination of foreground

A plan for use and dissemination of foreground (including socio-economic impact and target groups for the results of the research) shall be established at the end of the project. It should, where appropriate, be an update of the initial plan in Annex I for use and dissemination of foreground and be consistent with the report on societal implications on the use and dissemination of foreground (section 4.3 – H). The plan should consist of:

• Section A

This section should describe the dissemination measures, including any scientific publications relating to foreground. Its content will be made available in the public domain thus demonstrating the added-value and positive impact of the project on the European Union.

• Section B

This section should specify the exploitable foreground and provide the plans for exploitation. All these data can be public or confidential; the report must clearly mark non-publishable (confidential) parts that will be treated as such by the Commission. Information under Section B that is not marked as confidential will be made available in the public domain thus demonstrating the added-value and positive impact of the project on the European Union.

3. Report on societal implications

Replies to the following questions will assist the Commission to obtain statistics and indicators on societal and socio-economic issues addressed by projects. The questions are arranged in a number of key themes. As well as producing certain statistics, the replies will also help identify those projects that have shown a real engagement with wider societal issues, and thereby identify interesting approaches to these issues and best practices. The replies for individual projects will not be made public.

WP1: Management

Detailed workplan for WP1

A number of management tasks are entitled to the coordinator: e.g. - collecting information from partners,
- reviewing and submitting information on the progress of the project as well as reports and other deliverables to EC; - preparation of meetings, - proposing the decisions and preparing the agenda of the SG, - chairing of the SG meetings and monitoring the implementation of decisions taken at the meetings; - presenting the results of the consortium and serving as the secretary in the meetings; - administering the EC financial contribution and fulfilling other financial tasks, - maintaining the project's website etc.

According to the Grant Agreement, Annex II, management of the consortium activities includes:

• maintenance of the consortium agreement, if it is obligatory,
• the overall legal, ethical, financial and administrative management including, for each of the beneficiaries, the obtaining of the certificates on the financial statements and on the methodology and costs relating to financial audits and technical reviews,
• implementation of competitive calls by the consortium for the participation of new beneficiaries, where required by Annex I of this grant agreement,
• any other management activities foreseen by the annexes, except coordination of research and technological development activities.

WP2: Grammar Developer’s Tools

The grammar developer's tools are divided to two kinds of tasks:

• GF grammar compiler API

• actual tools implemented by using the API

The workplan for the first six months concerns mostly the API, with the main actual tool being the GF Shell, which is a line-based grammar development tool. It is a powerful tool since it enables scripting, but it is not integrated with other working environments. The most important other environment will be web-based access to the grammar compiler.

Note that most discussions on GF are public at http://code.google.com/p/grammatical-framework/.

Here follows the work plan, with tasks assigned to sites and approximate months.

 cd GF/contrib/py-bindings
 make

 python -m doctest example.rst

% import gf

% pgf = gf.read_pgf("Query.pgf")

% pgf.languages()
[QueryEng, QuerySpa]

% pgf.startcat()
Question

% eng,spa = pgf.languages()

% type(eng) 
(type 'gf.lang')

% pgf.parse(eng, "is 42 prime") 
[Prime (Number 42)]

% t = pgf.parse(eng, "is 42 prime")
% pgf.linearize(spa, t[0])
'42 es primo'

% pgf.complete(eng, "")
['is']

% pgf.complete(eng, "is ")
[]

% pgf.complete(eng, "is")
['is']

% pgf.complete(eng, "is 42 ")
['even', 'odd', 'prime']

% pgf.complete(eng, "is 42 even ")
[]

% pgf.parse(eng, "is 42 even")
[Even (Number 42)]

% t = pgf.parse(eng, "is 42 even")[0]
% type(t)
(type 'gf.tree')

% t.unapply()
[Even, Number 42]

% map(type, _)
[(type 'gf.cid'), (type 'gf.expr')]

% t.unapply()[1]
Number 42

% t.unapply()[1].unapply()
[Number, 42]

% map(type, _)
[(type 'gf.cid'), (type 'gf.expr')]

% t.unapply()[1].unapply()[1].unapply()
42

% type(_)
(type 'int')

WP3: Translator's Tools

To be entered for M7 - M30.

WP4: Knowledge Engineering

M1-M6 plan

• all partners send informal answers of the questions above & anything additional that has been missed in the questions (questionnaire)[/node/896]
• decide on the best server location (on site / rented)
• Ontotext to provide a description of what is the planned initial infrastructure for KE
• Ontotext to describe more about the LOD data sets and give the LDSR link
• UHEL to indicate their ideas on the KE WP, data sets and participation
• provide examples of entity descriptions in WKB
• first attempts on NL queries based on the WKB; put examples of the entity description constructs and then decide next steps with UGOT/UHEL;
• discuss feasibility of creating a NL interface for SPARQL (or a subset)
• provide examples of entity descriptions in WKB
• KE infrastructure in place
• decide on initial data sets with the partners; consider one or many instances
• KE infrastructure loaded with initial data sets
• navigation and search web UI over KEI
• results of the first experiences on ontology to grammar interoperability
• M4.1 - Knowledge representation - Retrieval access provided infrastructure to the consortium
• report for M1-M6
• plan for M6-M12

M6-M12 plan

• analyze the needs of autocompletetion and implement scalable solution for it
• work on transformation from natural language to sparql
• report for M6-M12
• plan for M6-M12

M12-M18 plan

• experiment with different ontologies
• write D4.2
• work on verbalization of the results from the semantic repository search
• finalize the D4.3 prototype
• report for M12-M18
• plan for M12-M18

M18-M24 plan

• support the work on other workpakages in the sphere of grammar-ontology interoperability
• report for M18-M24

Process & General Considerations

• we'd like all info to be available on the wiki, incl. notes, decisions, status of the components, docs
• SVN
• consider a backlog for the entire project/ each WP
• consider periodic development/delivery cycles
• consider regular telecons/skype conferences - once a month at least
• make application ideas backlog at the wiki

WP5: Statistical and Robust Translation

here a better task description

WP6: Case Study Mathematics

Mathematical grammars developed using GF for the WebALT project (eContent 22253) allow us to generate multilingual simple drills for high school students and university freshmen. These grammars will be the starting point aiming at extending coverage to word problems, the ones that require the student to first model a situation and then to manipulate the mathematical model to obtain a solution.

The UPC team, being a main actor in the past developing of gf mathematical grammars and having ample experience in mathematics teaching, will be in charge of the tasks in this work package with help from UGOT on technical aspects of GF and possibly Ontotext on ontology representation and handling.

R + D = 100

2*D + 4*R = 260

WP7: Case Study Patents

The work will start with the provision of user requirements (WP9) and the preparation of a parallel patent corpus (EPO) to fuel the training of statistical MT (UPC). In parallel UGOT will work on grammars covering the domain and subsequently, together with UPC, apply the hybrid (WP2, WP5) MT on abstracts and claims. Ontotext will provide semantic infrastructure with loaded existing structured data sets (WP4) from the patent domain (IPC, patent ontology, bio-medical and pharmaceutical knowledge bases, e.g. LLD). Based on the use case requirements, Ontotext will build a prototype (D7.1, D7.2) exposing multiple cross-lingual retrieval paradigms and MT of patent sections. The accuracy will be regularly evaluated through both automatic (e.g. BLEU scoring) and human based (e.g. TAUS) means (WP9).

Task List

The work package is split into 9 major tasks as follows:

• Task 7.1 User Requirements and Scenarios (Task Lead: UPC)
• Task 7.2 Patent corpora (Task Lead: UPC)
• Task 7.3 Grammars for the patent domain (Task Lead: UGOT)
• Task 7.4 Ontologies and document indexation (Task Lead: Ontotext)
• Task 7.5 Prototype (Task Lead: Ontotext)
• Task 7.6 SMT and Hybrid MT (Task Lead: UPC)
• Task 7.7 Prototype (user interface) (Tas Lead by Ontotext)
• Task 7.8 Human evaluation (Task Lead: TBD)
• Task 7.9 Patent Case Study: Final Report (Task Lead: UPC)

Month 10-15 plan

• Task 7.2 starts in M10 and is due to provide a first set of corpora at the end of M16. Final revision depends on the availability of the EPO data.
• Task 7.3 starts in M10 and is due to provide a preliminary report at the end of M16.

Month 16-21 plan

• Task 7.1 starts at M15 and is due to provide a preliminar version at the beginning of M17.
• Task 7.3 will produce a more complete report by the beginning of M19.
• Task 7.4 starts at M16 and is due to provide a description of the type of queries at the end of M16.
• Task 7.5 starts at M16 and is due to provide a description of the Prototype architecture at the end of M16.
• Task 7.6 starts along with WP5 and will produce a SMT baseline for the Patents prototype.
• D7.1 deadline is M21.

WP8: Case Study: Cultural Heritage

The work is started by a study of the existing categorizations and metadata schemas adopted by the museum, as well as a corpus of texts in the current documentation which describe these objects (D8.1, UGOT and Ontotext). We will transform the CIDOC-CRM model into an ontology aligning it with the upper-level one in the base knowledge set (WP4) and modeling the museum object metadata as a domain specific knowledge base. Through the interoperability engine from WP4 and the IDE from WP2, we will semi-automatically create the translation grammar and further extend it (D8.2, UGOT, UHEL, UPC, Ontotext). The final result will be an online system enabling museum (virtual) visitors to use their language of preference to search for artefacts through semantic (structured) and natural language queries and examine information about them. We will also automatically generate a set of articles in the Wikipedia format describing museum artefacts in the 5 languages with extensive grammar coverage (D8.3, UGOT, Ontotext).

Links to Swedish museum databases who use the Carlotta system which is built upon the CIDOC-CRM model:

WP9: User Requirements and Evaluation

Requirements for work

The work will start with collecting user requirements for the grammar development IDE (WP2), translation tools (WP3), and the use cases (WP6-8).

We will define the evaluation criteria and schedule in synchrony with the WP plans (D9.1). We will define and collect corpora including diagnostic and evaluation sets, the former, to improve translation quality on the way, and the latter to evaluate final results.

Corpus definitions

• Each corpus available for MOLTO will be described by the providing project members.
• The corpora will be split for development, diagnostic and evaluation use.
• Contact persons will be named for questions and requests for each corpus.
• Storage places and access protocols to gain this specified corpus data will be defined.

Description of end-user workflow

Translator's new role (parallel to WP3: Translator's tools) will be designed and described in the D9.1 deliverable. Most current translator's workbench software treat the original text as read-only source. The tools to be developed within WP3 (+ 2) will lead towards more mutable role of source text. The translation process will resemble more like structured document editing or multilingual authoring than transformation from a fixed source to a number of target languages.

We will only provide a basic infrastructure API for external translation workbenches and keep an eye on the "new multilingual translator's workflow".

Introduction of WP liaison persons and other contacts

For each work package, the liaison contact information and work progress will be kept up-to-date on the MOLTO web site. Our liaison person Mirka Hyvärinen will be in contact with other project members.

Also possibility to access UHEL's internal working wiki "MOLTO kitwiki" will be granted upon request to other project members.

Evaluation of results

Evaluation aims at both quality and usability aspects. UHEL will develop usability tests for the end-user human translator. The MOLTO-based translation workflow may differ from the traditional translator's workflow. This will be discussed in the D9.1 evaluation plan.

To measure the quality of MOLTO translations, we compare them to (i) statistical and symbolic machine translation (Google, SYSTRAN); and (ii) human professional translation. We will use both automatic metrics (IQmt and BLEU; see section 1.2.8 for details) and TAUS quality criteria (Translation Automation Users Society). As MOLTO is focused on information-faithful grammatically correct translation in special domains, TAUS results will probably be more important.

Given MOLTO's symbolic, grammar-based interlingual approach, scalability, portability and usability are important quality criteria for the translation results. For the translator's tools, user-friendliness will be a major aspect of the evaluation. These criteria are quantified in (D9.1) and reported in the final evaluation (D9.2).

In addition to the WP deliverables, there will be continuous evaluation and monitoring with internal status reports according to the schedule defined in D9.1.

WP10: Dissemination and Exploitation

Define workplan here

• http://www.speaklike.com/products/ some examples of applications
• http://www.sherpa.ac.uk/romeo/ Publisher copyright policies & self-archiving

WP11: Multilingual semantic wiki - AceWiki

Introduction

The core of WP11 is an existing wiki system AceWiki which is going to be developed into a multilingual controlled natural language wiki system within the MOLTO project.

Important links

The AceWiki homepage (http://attempto.ifi.uzh.ch/acewiki/) contains:

• demo wikis
• list of related publications
• further links

AceWiki development is hosted on GitHub (https://github.com/AceWiki/AceWiki)

• Contributions to the AceWiki codebase can be made via GitHub pull requests (see http://help.github.com/send-pull-requests/)
• Bugs can be reported via the AceWiki Issues list (https://github.com/AceWiki/AceWiki/issues)
• Documentation and brainstorming pages are on the AceWiki project wiki (https://github.com/AceWiki/AceWiki/wiki)

Tasks

• Task 11.1: Make the AceWiki design multilingual and implement a small AceWiki engine for multilingual GF grammars
• Task 11.2: General refactoring of the AceWiki code

Meetings

• 13 December 2011

To do

Phase 1

AceWiki side:

• Refactor AceWiki to support different implementations of predictive parsers (at the moment, AceWiki's chartparser is hardwired) [done: Tobias]
• Extract from the package "aceowl" everything that should be reused in GFAceWiki into a new package (mostly OWL-related stuff) [done: Tobias]
• Connect AceWiki to GF (via JPGF) [done: Tobias]
• Change the AceWiki architecture to support multilinguality [done: Tobias]
• Implement a simple AceWiki language engine for multilingual GF grammars (as an alternative to the current ACE-OWL engine) [done: Tobias]

GF side:

• Check the following three options of getting a multilingual OWL-capable ACE-implementation in GF (there might be more options):
  • Start with the official GF implementation of ACE [assigned: Kaarel], see: https://github.com/Attempto/ACE-in-GF
  • Start with Normunds' GF implementation of ACE [assigned: Kaarel] (discontinued), see: https://github.com/Kaljurand/AceWiki/tree/normunds/grammars/aceowl/normunds
  • Create a GF implementation based on (parts of) the AceWiki grammar
• Create a stable multilingual OWL-capable ACE-implementation in GF

Phase 2

• Implement support for adding/changing/deleting words
• Implement more languages
• Choose application domain(s) and build exemplary knowledge base
• Perform user studies

Releases

Release notes: https://raw.github.com/AceWiki/AceWiki/master/CHANGES.txt

• 2012-01-05: v0.5.2

Unsorted

AceWiki as a webservice

See also https://github.com/yuchangyuan/AceWiki

See also the thread starting with: https://lists.ifi.uzh.ch/pipermail/attempto/2011-December/000818.html

• There could be potentially multiple front-ends
  • the current front-end
  • an existing GF front-end
  • Emacs
  • Unix commandline
  • ACE View
  • native Android/iOS app
  • ...
• REST API
  • allows to easily push content (existing lexicon, existing ACE text) into the wiki
  • should support GET as much as possible
• Make AceWiki easily deployable on hosting providers such as Google App Engine
  • reasons: speed, reliability, etc.
  • for that to work, AceWiki should be completely in Java (i.e. no using of APELocal), i.e. ape.exe would still have to be on a different host (because it is in Prolog)
  • would reasoning performance profit in a major way?

AceWiki more configurable

• [done: Changyuan/Kaarel] Support APESocket and APEWebservice in addition to APELocal. Configuration at the XML file level. See also: http://attempto.ifi.uzh.ch/site/docs/java/ch/uzh/ifi/attempto/ape/ACEPar...

1. Publishable Summary

This section must be of suitable quality to enable direct publication by the Commission and should preferably not exceed four pages.

In line with this, diagrams or photographs illustrating and promoting the work of the project, as well as relevant contact details or list of partners can be provided without restriction.

Project context and objectives

The project MOLTO - Multilingual Online Translation, started on March 1, 2010 and will run for 36 months. It promises to develop a set of tools for translating texts between multiple languages in real time with high quality. MOLTO will use multilingual grammars based on semantic interlinguas and statistical machine translation to simplify the production of multilingual documents without sacrificing the quality. The interlinguas are based on domain semantics and are equipped with reversible generation functions: namely translation is obtained as a composition of parsing the source language and generating the target language. An implementation of this technology is provided by GF, Grammatical Framework. GF technologies in MOLTO are complemented by the use of ontologies, such as used in the semantic web, and by methods of statistical machine translation (SMT) for improving robustness and extracting grammars from data.

MOLTO is committed to dealing with 15 languages, which includes 12 official languages of the European Union - Bulgarian, Danish, Dutch, English, Finnish, French, German, Italian, Polish, Romanian, Spanish, and Swedish - and 3 other languages - Catalan, Norwegian, and Russian. In addition, there is on-going work on at least Arabic, Farsi, Hebrew, Hindi/Urdu, Icelandic, Japanese, Latvian, Maltese, Portuguese, Swahili, Tswana, and Turkish.

Tools like Systran (Babelfish) and Google Translate are designed for consumers of information, but MOLTO will mainly target the producers of information. Hence, the quality of the MOLTO translations must be good enough for, say, an e-commerce site to use in translating their web pages automatically without the fear that the message will change. Third-party translation tools, possibly integrated in the browsers, let potential customers discover, in their preferred language, whether, for instance, an e-commerce page written in French offers something of interest. Customers understand that these translations are approximate and will filter out imprecisions. If, for instance, the system has translated a price of 100 Euros to 100 Swedish Crowns (which equals 10 Euros), they will not insist to buy the product for that price. But if a company had placed such a translation on its website, then it might be committed to it.

There is a well known trade-off in machine translation: one cannot at the same time reach full coverage and full precision. In this trade-off, Systran and Google have opted for coverage whereas MOLTO opts for precision in domains with a well understood language. Three such domains will be considered during the MOLTO project: mathematical exercises, biomedical patents, and museum object descriptions. The MOLTO tools however will be applicable to other domains as well. Examples of such domains could be e-commerce sites, Wikipedia articles, contracts, business letters, user manuals, and software localization.

Main results achieved so far

A few results have been already achieved during the first semester of the project's lifetime. Two applications of the MOLTO translation web services are online on the project web pages:

1. The travel phrasebook translates sentences to 14 different languages and shows some of the major end-user features available to MOLTO users: predictive typing and JavaScript-based GUI. Predictive typing prompts the user with the next available choices mandated by the underlying grammar and offers quasi-incremental translations of intermediate results from words or complete sentences. JavaScript-based GUI using off-the-shelf functions can be readily deployed on any device where a browser is available.
2. The MOLTO KRI, Knowledge Reasoning Infrastructure, demonstrates the possibility of adding a natural language query language to retrieve answers from an OWL database. In this way, a query like Give me information about all organizations located in Europe is interpreted as the machine understandable SPARQL statement: SELECT DISTINCT ?organization ?organization_label WHERE { ?organization
   . ?organization
   ?organizationloc. ?organizationloc "Europe". ?organization ?organization_label . }

On the more technical level, MOLTO released:

• first version of the Python plugin for GF (based on the planned C plugin). The plugin makes GF primitives available from the Natural Language Toolkit (http://www.nltk.org/), an open source collection of Python modules for research and development in natural language processing and text analytics, with distributions for Windows, Mac OSX and Linux.
• (version 3.2 of GF, which features updates of the pgf format, complete type checker for dependent types, exhaustive generation of ASTs via lambda prolog, support for probabilities in the abstract syntax, random generation and parse results guided by probability, and example based grammar generation.) DISCUSS WITH AR
• (Urdu resource grammar library and Turkish morphology) DISCUSS WITH AR

Expected final results and their potential impact and use

The expected final product of MOLTO is a software toolkit made available via the MOLTO website. It will consist in a family of open-source software products:

1. a grammar development tool, available as an IDE and an API, to enable the use as a plug-in to web browsers, translation tools, etc, for easy construction and improvement of translation systems and the integration of ontologies with grammars
2. a translator’s tool, available as an API and some interfaces in web browsers and translation tools
3. a grammar library for linguistic resources
4. a grammar library for the domains of mathematics, patents, and cultural heritage

These tools will be portable to different platforms as well as generally portable to new domains and languages. By the end of the project, MOLTO expects to have grammar resource libraries for 18 languages, whereas MOLTO use cases will target between 3 and 15 languages.

The main societal impact of MOLTO will be on contributing to a new perception for the possibilities of machine translation, moving away from the idea that domain-specific high-quality translation is expensive and cumbersome. MOLTO tools will change this view by radically lowering the effort needed to provide high-quality scoped translation for applications where the content has enough semantic structure.

Public website

The MOLTO website at http://www.molto-project.eu publishes the results, the news and all information related to the project. In addition, a Twitter feed is also available at http://twitter.com/moltoproject.

2. Core of the report

3. Deliverables and milestones tables

Deliverables for Period M1-M6

List of deliverables accessible to you.

The admin page is the administrative data related to this deliverable as was planned in the description of work. Use this page, as work package leader, to keep track of changes in the content, scope, or date of the deliverable.

The wiki page is the collaborative editing platform for the deliverable, when a report, or for the cover document, when a prototype. Please cut and paste the front matter as in sample deliverables when creating a new one.

The publication is the actual frozen deliverable: it can easily be produced from the wiki page using the print icon and save as pdf, directly from the browser. Unless a publication is linked to the administrative record of the deliverable, it will not appear in the quick listing http://www.molto-project.eu/view/biblio/deliverables.

ID	As planned (admin page)	Due date	Dissemination level	Nature	Publication	Wiki
D1.1	Workplan for MOLTO	1 April, 2010	Consortium	Report		D1.1 Work plan for MOLTO
D10.1	Dissemination plan, with monitoring and assessment	1 June, 2010	Consortium	Report	Dissemination Plan with Monitoring and Assessment	D10.1 Dissemination Plan with Monitoring and Assessment
D10.2	MOLTO web service, first version	1 June, 2010	Public	Prototype	MOLTO web service, first version	D10.2 MOLTO web service, first version
D9.1	MOLTO test criteria, methods and schedule	1 September, 2010	Public	Report	MOLTO test criteria, methods and schedule	D9.1 MOLTO test criteria, methods and schedule

Milestones for Period M1-M6

4. Use of the resources

Not available for midterm reporting.

5. Financial statements

Not available for midterm reporting.

1. Publishable summary

This section must be of suitable quality to enable direct publication by the Commission and should preferably not exceed four pages.

The publishable summary has to include all the distinct parts described below:

• A summary description of project context and objectives,
• A description of the work performed since the beginning of the project and the main results achieved so far ,
• The expected final results and their potential impact and use (including the socio-economic impact and the wider societal implications of the project so far),
• The address of the project public website, if applicable

In line with this, diagrams or photographs illustrating and promoting the work of the project, as well as relevant contact details or list of partners can be provided without restriction.

The publishable summary should be updated for each periodic report.

2. Core of the report for the period

3. Deliverables and milestones tables

Deliverables

The deliverables due in this reporting period, as indicated in Annex I to the Grant Agreement have to be uploaded by the responsible participants (as indicated in Annex I), and then approved and submitted by the Coordinator. Deliverables are of a nature other than periodic or final reports (ex: "prototypes", "demonstrators" or "others"). If the deliverables are not well explained in the periodic and/or final reports, then, a short descriptive report should be submitted, so that the Commission has a record of their existence.

If a deliverable has been cancelled or regrouped with another one, please indicate this in the column "Comments". If a new deliverable is proposed, please indicate this in the column "Comments".

This table is cumulative, that is, it should always show all deliverables from the beginning of the project.

Milestones

Please complete this table if milestones are specified in Annex I to the Grant Agreement. Milestones will be assessed against the specific criteria and performance indicators as defined in Annex I.

This table is cumulative, which means that it should always show all milestones from the beginning of the project.

4. Explanation of the use of the resources

Please provide an explanation of personnel costs, subcontracting and any major costs incurred by each beneficiary, such as the purchase of important equipment, travel costs, large consumable items, etc., linking them to work packages.

There is no standard definition of "major cost items". Beneficiaries may specify these, according to the relative importance of the item compared to the total budget of the beneficiary, or as regards the individual value of the item.

These can be listed in the following tables (one table by participant):

TABLE 3.1 PERSONNEL, SUBCONTRACTING AND OTHER MAJOR COST ITEMS FOR BENEFICIARY 1 FOR THE PERIOD

5. Financial statements – Form C and Summary financial report

Please submit a separate financial statement from each beneficiary (if Special Clause 10 applies to your Grant Agreement, please include a separate financial statement from each third party as well) together with a summary financial report which consolidates the claimed Community contribution of all the beneficiaries in an aggregate form, based on the information provided in Form C (Annex VI) by each beneficiary.

When applicable, certificates on financial statements shall be submitted by the concerned beneficiaries according to Article II.4.4 of the Grant Agreement.

Besides the electronic submission, Forms C as well as certificates (if applicable), have to be signed and sent in parallel by post.

A Web-based online tool for completing and submitting forms C is accessible via the Participant Portal: http://ec.europa.eu/research/participants/portal.

1. Publishable summary

2. Core of the report

3. Deliverables and milestones tables

Deliverables of MOLTO are listed and linked for download on the web page http://www.molto-project.eu/workplan/deliverables.

Below is a summary of deliverables due in the third semester.

The only milestone due for the period is MS3, the web-based translation tool, which has been interpreted as a online editor interface to a GF application grammar and made available at http://www.molto-project.eu/node/1063.

4. Use of the resources

Tables on the usage of resources are not available for midterm reporting, however we have a rough estimate of person's months by each node.

5. Financial statements

Not available for midterm reporting.

1. Publishable summary

2. Core of the report

This section describes the progress of each workpackage and discusses changes to the workplan, if necessary.

2.4. Deliverables and milestones tables

Deliverables of MOLTO are listed and linked for download on the web page http://www.molto-project.eu/workplan/deliverables.

Below is a summary of deliverables due until the fourth semester.

Number	Title	Attached files	Date Published
D 1.2	Progress Report	D1.2.pdf	11/2010
D 1.3A	D1.3A Advisory Board Report	D1.3A.pdf	03/2011
D 1.4	Periodic Management Report T18	D1.4.pdf	10/2011
D 2.1	GF Grammar Compiler API	D2.1.pdf	03/2011
D 2.2	Grammar IDE	D2.2.pdf	10/2011
D 3.1	The Translation Tools API	D3.1.pdf, d31.zip	09/2011
D 4.1	Knowledge Representation Infrastucture	D4.1.pdf, D4.1_reviewed.pdf	11/2010
D 4.2	Data models and alignments	D4.2.pdf	05/2011
D 4.3	Grammar ontology interoperability	D4.3.pdf, D4.3_edited.pdf	10/2011
D 5.1	Description of the final collection of corpora	D.5.1.pdf	09/2011
D 5.2	Description and evaluation of the combination prototypes	D52.pdf	03/2012
D 6.1	Simple drill grammar library	D6.1.pdf	10/2011
D 6.2	Prototype of comanding CAS	D6.2.pdf	03/2012
D 7.1	Patent MT and Retrieval Prototype Beta	D71_final.pdf	01/2012
D 8.1	Ontology and corpus study of the cultural heritage domain	D8-1.pdf	09/2011
D 8.2	Multilingual grammar for museum object descriptions	d8.2-grammars.tar.gz, D8.2.pdf	03/2012
D 9.1	MOLTO test criteria, methods and schedule	D9.1-final.pdf, d91-final_w_cover.odt	12/2010
D X.2	Annual Public Report M24	DX.2.pdf	03/2012
D 10.1	Dissemination Plan with Monitoring and Assessment	D10.1.pdf	06/2010
D 10.2	MOLTO web service, first version	D10.2.pdf	06/2010

The milestones until now have been achieved to a different degree of completion, either by a deliverable or by some online prototype. In particular, MS3, is the translation editor available at http://www.grammaticalframework.org:41296/editor/#translate and is being integrated in the Translator's Tools due next September 2012. The grammar-ontology-interoperability has been documented in D4.3 however is has been requested that more details be made explicit. Concerning MS7, the methods implemented by the hybrid combination prototypes have been evaluated on a specific test set as reported in D5.4.

ID	Title	Due date
MS1	15 Languages in RGL	1 September, 2010
MS2	Knowledge Representation Infrastructure	1 September, 2010
MS3	Web-based translation tool	1 March, 2011
MS4	Grammar-ontology interoperability	1 October, 2011
MS5	First prototypes of the cascade-based combination models	1 October, 2011
MS6	Grammar tool complete	1 March, 2012
MS7	First prototypes of hybrid combination models	1 March, 2012

3. Project management during M19-M24

The third semester of the project saw the enlargement of the Consortium by two new partners University of Zürich and Be Informed. While the original planned start of the MOLTO-EEU project enlargement was scheduled for September 2011, and accounted for synchronicity of the deliverables with ongoing workpackages, the actual kickoff only happened in January 2012. Consequently, the end date of the project is now shifted to 31 May 2013 and the main deliverable of Workpackage 2 has been shifted 3 months to take into account the feedback from the new use cases added by the enlargement.

The following inconsistencies have been noticed in the revised Annex:

• WP12, on pag. 33, starts M22 ends 33, while on pag. 48, starts M18 ends M33. Figures on pag. 48 hold.

However, due to the delay in start, both WP11 and WP12 will now be ongoing in the period M22-M37, as in the chart below. Notice also the changes affecting WP2 and WP8.

4. Use of the resources

Official tables on the usage of resources are available for yearly reporting in Forms C.

Here we have a rough estimate of person's months given by each node. Note that the figures listed previously do not include management months, hence totals may differ.

We found a typo in the table for WP7 in the new Annex I for MOLTO EEU. The person months must be the same as for the previous DoW (Version number: 3 Revision 1 (21/01/2011)): namely WP7 description, pag. 31, PMs: UGOT 12, UPC 15, and Ontotext 15 (and not Ontotext 0).

Declaration by the scientific representative of the project coordinator

I, as scientific representative of the coordinator of this project and in line with the obligations as stated in Article II.2.3 of the Grant Agreement declare that:

1. The attached periodic report represents an accurate description of the work carried out in this project for this reporting period;

2. The project (tick as appropriate):

3. The public website, if applicable:

4. To my best knowledge, the financial statements which are being submitted as part of this report are in line with the actual work carried out and are consistent with the report on the resources used for the project (section 3.4) and if applicable with the certificate on financial statement.

5. All beneficiaries, in particular non-profit public bodies, secondary and higher education establishments, research organisations and SMEs, have declared to have verified their legal status. Any changes have been reported under section 3.2.3 (Project Management) in accordance with Article II.3.f of the Grant Agreement.

Name of scientific representative of the Coordinator:

Aarne Ranta
....................................................................

Date: 26/4/2012

</hr/>

1. Publishable summary

The project MOLTO - Multilingual Online Translation, started on March 1, 2010 and will run until 31 May 2013 with the task to develop tools for translating texts between multiple languages in real time with high quality. MOLTO grounding technology is multilingual grammars based on semantic interlinguas and statistical machine translation to simplify production of multilingual documents without sacrificing the quality. The specific interlinguas are based on domain semantics and are equipped with reversible generation functions: namely translation is obtained as a composition of parsing the source language and generating the target language. An implementation of this technology is provided by GF, Grammatical Framework, which in MOLTO is furthermore complemented by the use of ontologies, as in the semantic web, and by methods of statistical machine translation (SMT) for improving robustness and extracting grammars from data. GF has been applied in several small-to-medium size domains, typically targeting up to ten languages but MOLTO will scale this up in terms of productivity and applicability.

A part of the scale-up is to increase the size of domains and the number of languages. A more substantial part is to make the technology accessible to domain experts without GF expertise and minimize the effort needed for building a translator. Ideally, the MOLTO tools will reduce the overall task to just extending a lexicon and writing a set of example sentences.

MOLTO is committed to dealing with 15 languages, which includes 12 official languages of the European Union - Bulgarian, Danish, Dutch, English, Finnish, French, German, Italian, Polish, Romanian, Spanish, and Swedish - and 3 other languages - Catalan, Norwegian, and Russian. In addition, there is on-going work on at least Arabic, Farsi, Hebrew, Hindi/Urdu, Icelandic, Japanese, Latvian, Maltese, Portuguese, Swahili, Tswana, and Turkish.

While tools like Systran (Babelfish) and Google Translate are designed for consumers of information, MOLTO will mainly target the producers of information. Hence, the quality of the MOLTO translations must be good enough for, say, an e-commerce site to use in translating their web pages automatically without the fear that the message will change. Third-party translation tools, possibly integrated in the browsers, let potential customers discover, in their preferred language, whether, for instance, an e-commerce page written in French offers something of interest. Customers understand that these translations are approximate and will filter out imprecision. If, for instance, the system has translated a price of 100 Euros to 100 Swedish Crowns (which equals 10 Euros), they will not insist to buy the product for that price. But if a company had placed such a translation on its website, then it might be committed to it. There is a well-known trade-off in machine translation: one cannot at the same time reach full coverage and full precision. In this trade-off, Systran and Google have opted for coverage whereas MOLTO opts for precision in domains with a well-understood language.

MOLTO technology will be released as open-source libraries, accompanied by cloud services, to be used for developing plug and play components to translation platforms and web pages and thereby designed to fit into third-party workflows. The project will showcase its results in web-based flagship demos applied in three case studies: mathematical exercises in 15 languages, patent data in at least 3 languages, and museum object descriptions in 15 languages. The MOLTO Enlarged EU scenarios will apply MOLTO tools to a collaborative semantic wiki and to an interactive knowledge-based system used in a business enterprise environment.

2. Core of the report

This section describes the progress of each workpackage and discusses changes to the workplan, if necessary.

3. Project management during M25-M30

Project management during the period consisted mainly in maintaining the routine communication with the partners, by holding a monthly skype call, and in distributing the second installment of the funding.

UGOT received the 2nd interim payment from the EU and it distributed it to the partners on 15 August, 2012. Each partner received also the financial assessment from the EU and an overview of the payment that has been sent. The Consortium has now received 85% of the MOLTO total budget which is the maximum amount possible before the approval of the final reporting.

Followup actions after the annual review included discussions within the Consortium on how to organize a better showcase for the final results of the project and in addressing the reviewers' remarks and suggestions (see Task 1.8). Updated versions of some deliverables were produced and made available on the website.

In terms of infrastructure, the svn repository is currently being used by a larger number of members of the Consortium and in addition there is a new bug-tracking system installed and running at UHEL.

4. Use of the resources

Tables on the usage of resources are not available for midterm reporting, however we have a rough initial estimate of persons' months by almost all nodes. Ontotext has not been able to provide the data.

1. Publishable summary

The project MOLTO - Multilingual Online Translation, started on March 1, 2010 and ran until 31 May 2013. Its goal was to develop tools for translating texts between multiple languages in real time with high quality. MOLTO's grounding technology is multilingual grammars based on semantic interlinguas and grammar-based translation. It also explores ways to use statistical machine translation without sacrificing quality.

MOLTO uses specific interlinguas that are based on domain semantics and are equipped with reversible generation functions. Thus translation is obtained as a composition of parsing the source language and generating the target language. An implementation of this technology is provided by GF, Grammatical Framework, which in MOLTO is furthermore complemented by the use of ontologies, as in the semantic web, and by methods of statistical machine translation (SMT) for improving robustness and extracting grammars from data. GF has been applied in several small-to-medium size domains, typically targeting several parallel languages. During its lifetime, MOLTO has scaled up this technology in terms of productivity, domain size, and the number of languages.

The size of domains has been increased to involve up to thousands of concepts. and the number of languages to twenty parallel ones. A special focus has been to make the technology accessible to domain experts without GF expertise and minimize the effort needed for building a translator. Ideally, the MOLTO tools will reduce the overall task to just extending a lexicon and writing a set of example sentences.

MOLTO was initially committed to dealing with 15 languages, which included 12 official languages of the European Union - Bulgarian, Danish, Dutch, English, Finnish, French, German, Italian, Polish, Romanian, Spanish, and Swedish - and 3 other languages - Catalan, Norwegian, and Russian. The additional languages also addressed in MOLTO are Chinese, Hebrew, Hindi, Latvian, Persian, and Urdu.

While tools like Systran (Babelfish) and Google Translate are designed for consumers of information, MOLTO's main target is the producers of information. Hence, the quality of the MOLTO translations must be good enough for, say, an e-commerce site to use in translating their web pages automatically without the fear that the message will change. Third-party translation tools, possibly integrated in the browsers, let potential customers discover, in their preferred language, whether, for instance, an e-commerce page written in French offers something of interest. Customers understand that these translations are approximate and will filter out imprecision. If, for instance, the system has translated a price of 100 Euros to 100 Swedish Crowns (which equals 11 Euros), they will not insist to buy the product for that price. But if a company had placed such a translation on its website, then it might be committed to it. There is a well-known trade-off in machine translation: one cannot at the same time reach full coverage and full precision. In this trade-off, Systran and Google have opted for coverage whereas MOLTO opts for precision in domains with a well-understood language.

MOLTO technology is continuously released as open-source software and linguistic modules, accompanied by cloud services, to be used for developing plug and play components to translation platforms and web pages and thereby designed to fit into third-party workflows. The project showcases its results in web-based flagship demos applied in three case studies: mathematical exercises in 15 languages, patent translations and queries in 3 languages, and museum object descriptions and queries in 15 languages. The MOLTO Enlarged EU scenarios add to this an application of MOLTO tools to a collaborative semantic wiki and to an interactive knowledge-based system used in a business enterprise environment.

2. Core of the report

This section describes the progress of each workpackage and discusses changes to the workplan, if necessary.

2.3. Deliverables and milestones tables

The list of project deliverables can be obtained from the web pages at http://www.molto-project.eu/view/biblio/deliverables and in annotated form at http://www.molto-project.eu/view/biblio/type/Deliverable. The administrative view provides the links to the final PDF but also to the online version of the documents at http://www.molto-project.eu/workplan/deliverables. Below is a summary for the final period.

ID	As planned (admin page)	Due date	Dissemination level	Nature	Publication	Wiki
D1.7	Final management report	31 May, 2013	Consortium	Report		D1.7 Final Management Report T39
D10.3	MOLTO web service, final version	31 May, 2013	Public	Prototype		D10.3 MOLTO web service, final version
D10.4	MOLTO Dissemination and Exploitation Report	31 May, 2013	Public	Report	D10.4 MOLTO Dissemination and Exploitation Report	D10.4 MOLTO Dissemination and Exploitation Report
D9.2	MOLTO evaluation and assessment report	31 May, 2013	Public	Report
D11.3	User studies for the multilingual semantics wiki	31 May, 2013	Public	Report	Evaluations of ACE-in-GF and of AceWiki-GF
D12.2	User studies for BI's explanation engine	31 May, 2013	Public	Report		D12.2 User studies for BI's explanation engine
D4.3A	Grammar ontology interoperability - Final Work and Overview	31 May, 2013	Public	Regular Publication
D3.3	MOLTO translation tools / workflow manual	31 March, 2013	Public	Regular Publication	D3.3 MOLTO translation tools – workflow manual	D3.3 MOLTO translation tools / workflow manual
D5.3	WP5 final report: statistical and robust MT	31 March, 2013	Public	Regular Publication	WP5 final report: statistical and robust MT
D7.3	Patent Case Study Final Report	31 March, 2013	Public	Regular Publication	Patent Machine Translation and Retrieval. Final Report.
D8.3	Translation and retrieval system for museum object descriptions	1 March, 2013	Public	Prototype	D8.3: Translation and retrieval system for museum object descriptions
D11.2	Multilingual semantic wiki	31 December, 2012	Public	Prototype	Multilingual semantic wiki
D6.3	Assistant for solving word problems	1 December, 2012	Public	Prototype	D6.3 Assistant for solving word problems	D6.3 Assistant for solving word problems
D1.6	Periodic management report 5	1 October, 2012	Consortium	Report	Periodic Management Report T30	D1.6 Periodic Management Report T30
D7.2	Patent MT and Retrieval Prototype	1 September, 2012	Public	Prototype	Patent MT and Retrieval Prototype
D12.1	Requirements for BI's explanation engine	1 September, 2012	Public	Report	Requirements for GF based Verbalization in Be Informed

3. Project management during M25-M39

Project management during the last period aimed at strengthening the cooperation work of the partners for finalizing the tools and technologies delivered. This coordination was mainly achieved through the creation of a Google group for the MOLTO project: all members of the Consortium have been subscribed to it.

A major issue has been the relocation of the project manager Olga Caprotti to the partner node UPC for the period 1 March 2013 - 11 June 2013. This was made necessary by national Swedish regulations that prevent hiring on temporary positions for longer than 2 years (she had already used a 1-year long non-renewable temporary post as a visiting researcher). A part of the funding has been transferred to UPC to cover the costs of hiring Dr. Caprotti until the end of the project.

The use of resources has undergone some internal shift among work-packages in order to cover extra work that had become necessary due to initial delays and to personnel turnover. Where appropriate, they are documented case by case in the work-package reports.

As reported in Deliverable D1.6, followup actions after the annual review included discussions within the Consortium on how to organize a better showcase for the final results of the project and in addressing the reviewers' remarks and suggestions. Updated versions of some deliverables were produced and made available on the website.

Here below we address each comment in the review.

4. Use of the resources

The figures in the attached table come from the participants' time sheets. They are therefore a preliminary estimate: the final figures will be available in the NEF, Form C, when every participant has finalized their reporting there.

Self Declaration of the Coordinator in D1.7

I, as scientific representative of the coordinator of this project and in line with the obligations as stated in Article II.2.3 of the Grant Agreement declare that:

1. The attached periodic report represents an accurate description of the work carried out in this project for this reporting period;

2. The project (tick as appropriate):

   x has fully achieved its objectives and technical goals for the period;

   ☐ has achieved most of its objectives and technical goals for the period with relatively minor deviations.

   ☐ has failed to achieve critical objectives and/or is not at all on schedule.

3. The public website, if applicable:

   x is up to date

   ☐ is not up to date

4. To my best knowledge, the financial statements which are being submitted as part of this report are in line with the actual work carried out and are consistent with the report on the resources used for the project (section 4) and if applicable with the certificate on financial statement.

5. All beneficiaries, in particular non-profit public bodies, secondary and higher education establishments, research organisations and SMEs, have declared to have verified their legal status. Any changes have been reported under section 3 (Project Management) in accordance with Article II.3.f of the Grant Agreement.

Name of scientific representative of the Coordinator:

....................................................................

Aarne Ranta

Date: 30/7/2013

1. Introduction

GF, Grammatical Framework, is a programming language for multilingual grammars. GF is used in the MOLTO project to build translation systems. How to write GF grammars is specified in the numerous tutorials and manuals available via http://grammaticalframework.org. The compiler API is a document that explains aspects of the compiler of the GF language:

• how GF source code is compiled to various formats usable in runtime systems
• how the developers can test their grammars
• how other formats (such as lexica and example sentences) can be converted to GF code
• how to call the compiler in various ways:
  • GF shell commands and scripts
  • Haskell programs
  • web applications

2. Installation

The GF API can be downloaded from the MOLTO svn server at svn://molto-project.eu/compiler-api and compiled by running make. For compilation to succeed, and produce an HTML file readable in the browser, it is necessary to have the txt2tags software (from http://txt2tags.org) and the graphviz software (http://www.graphviz.org).

A version maintained by the GF developers is also available online at http://www.grammaticalframework.org/compiler-api.

1. Introduction

An IDE, Integrated Development Environment, is a software system targeted for programmers. It helps the programmer to write code and test and maintain it. The tasks where IDE helps can include

• editing source code
• compiling and/or interpreting the code
• maintain complex projects with their module dependencies
• test and debug the code

(cf. http://en.wikipedia.org/wiki/Integrated_development_environment). While interactive command interpreters (such as Unix shells) were historically the first systems recognized as IDE's, the contemporary notion of "IDE's proper" assumes a set of visual tools. The most widely used IDE's are probably Eclipse (http://www.eclipse.org/), Microsoft Visual Studio (http://www.microsoft.com/visualstudio), and Apple's XCode (http://developer.apple.com/xcode/). Each of these is a desktop program of substantial size. But recent times have also seen Web IDE's (WIDE), where the user can write programs without implementing any software locally; an example is CodeRun (http://www.coderun.com).

The purpose of this document is to introduce an IDE for GF, Grammatical Framework (http://www.grammaticalframework.org/). GF is a programming language designed for writing multilingual grammars and their applications (Ranta 2011). Typical applications are translation systems (with many simultaneous languages) and the localization of natural language processing systems such as question answering (with many alternative languages).

This paper will introduce two IDE's for GF:

• a Web IDE (http://www.grammaticalframework.org/demos/gfse/), which allows users to build GF grammars and run them "in the cloud"
• an Eclipse plug-in, which allows users to build GF grammars on their desktop and link them with other Eclipse-enabled software, such as Android mobile applications and ontology engineering tools.

The Web IDE is intended to be a quick way to use GF, since it doesn't require any software installation, and also has some helpful functionalities to guide novice users. But it is less adapted for large GF programs consisting of large numbers of modules, such as GF grammar libraries. The Web IDE is a mature program tested by many users, but new developments are still expected.

The Eclipse plug-in is meant for power users of GF, who have to maintain perhaps hundreds of GF modules simultaneously and to link them with other software. But it is less quick to get started with, since it requires the installation of both the GF compiler, the Eclipse platform, and the GF Eclipse plug-in. The Eclipse plug-in is still in the beginning of its development.

Both these tools are new, and have been built during 2011 within the MOLTO project. The traditional "IDE" for GF is one familiar from the Unix environment:

• a batch compiler
• text editor support (e.g. syntax highlighting in Emacs, Gedit, and Geany, http://www.grammaticalframework.org/doc/gf-editor-modes.html)
• an interactive command-based shell, "the original GF program".

The interactive shell is a Read-Eval-Print loop similar to LISP and, more recently, Haskell (GHCI). While it has more IDE functionalities than many programming languages provide, we are not calling it an IDE, but reserve that name to the graphical Web IDE and Eclipse systems. Actually, the GF shell can be seen as an API (Application Programmer's Interface) to the GF compiler. It provides a set of commands that can be used for compiling, diagnosing, and testing GF grammars. More sophisticated IDE's can be built by using the shell command language to communicate with the compiler. The document The GF Grammar Compiler API (MOLTO Deliverable 2.1) gives more information on the available functionalities.

2. Multilingual grammars

A GF program is a multilingual grammar, which for

n languages consist of 1+n modules: one abstract syntax defining the semantic content in a language-independent way, and for each language a concrete syntax showing how this content is expressed in that language. Here is a "hello world" example for English, Finnish, and Italian:

  abstract Hello = {
    cat Greeting ; Recipient ;
    fun 
      Hello : Recipient -> Greeting ;
      World, Mum, Friends : Recipient ;
  }
  
  concrete HelloEng of Hello = {
    lin 
      Hello rec = "hello" ++ rec ;
      World = "world" ;
      Mum = "mum" ;
      Friends = "friends" ;
  }
  
  concrete HelloFin of Hello = {
    lin 
      Hello rec = "terve" ++ rec ;
      World = "maailma" ;
      Mum = "äiti" ;
      Friends = "ystävät" ;
  }
  
  concrete HelloIta of Hello = {
    lin 
      Hello rec = "ciao" ++ rec ;
      World = "mondo" ;
      Mum = "mamma" ;
      Friends = "amici" ;
  }

The GF compiler produces from this code a system that can parse phrases like hello world, ciao mamma and also generate them each language, thus enabling translation between any pair of languages.

The Hello grammar is of course extremely simple, on purpose. But it shows the essential structure of multilingual grammars, and it is easy to see how the grammar could be extended by adding new functions (i.e. combination rules like Hello and words like Mum).

The GF compiler controls that the abstract and concrete syntaxes are in synchrony. For instance, it checks that each abstract syntax function (fun) actually has a linearization (lin) in each concrete syntax. An IDE is expected to go one step further: it reminds the programmer, prior to running the compiler, of those linearizations that are missing. And when a new language (i.e. a new concrete syntax) is added to the system, the IDE initializes its code with a template for all required linearization rules.

Multilinguality is one aspect of GF's module system: each language, as well as the abstract syntax, has its own module. Larger GF applications have an additional complexity created by the inheritance and opening of modules; a large grammar can easily have 20 modules involved for each language, and this is multiplied by the number of languages plus one for the abstract syntax. While the opening and inheritance correspond to the module dependencies found in most other programming languages (such as inheritance and the use of libraries), the multilinguality aspect is an extra dimension, which makes GF programs more complex than usual programs.

A GF project with 15 languages, as targeted in the MOLTO project, involves hundreds of modules in scope at the same time. These are roughly divided to two groups,

• the application grammar: the code written by the programmer
• the resource grammar: the code imported from libraries

The total resource grammar code in September 2011 comprises 755 modules, addressing 20 natural languages. This code is normally distributed in binaries (although the source is also available) and never read or written by the application programmer. But the programme of course needs to inspect the code: to see, for instance, what functions are available to contruct objects of a given type such as noun or sentence. Inspecting the library code is one of the most important things that should be supported by the IDE.

3. The Web IDE

Traditionally, GF grammars are created in a text editor and tested in the GF shell. Text editors know very little (if anything) about the syntax of GF grammars, and thus provide little guidance for novice GF users. Also, the grammar author has to download and install the GF software on his/her own computer.

In contrast, the GF online editor for simple multilingual grammars is available online, making it easier to get started. All that is needed is a reasonably modern web browser. Even Android and iOS devices can be used.

The editor also guides the grammar author by showing a skeleton grammar file and hinting how the parts should be filled in. When a new part is added to the grammar, it is immediately checked for errors.

Editing operations are accessed by clicking on editing symbols embedded in the grammar display: + = Add an item, × = Delete an item, % =Edit an item. These are revealed when hovering over items. On touch devices, hovering is in some cases simulated by tapping, but there is also a button at the bottom of the display to "Enable editing on touch devices" that reveals all editing symbols.

In spite of its name, the editor runs entirely in the web browser, so once you have opened the web page, you can continue editing grammars even while you are offline.

4. The Eclipse plug-in

The aim behind developing a desktop IDE for GF is to provide more powerful tools than may be possible and/or practical in a web-based setting. In particular, the ability to resolve cross-references between source files and libraries instantaneously during development time is one of the primary goals and motivations for the project.

The choice was made to develop this desktop IDE as a plugin for the Eclipse Platform as it seemed to be the most popular choice among the GF developer community. Support for the platform is vast and many tools for adapting Eclipse to domain-specific languages already exist. Unlike the zero-click WIDE approach, using the GF Eclipse plugin (GFEP) will require some manual installation and configuration on the development machine. Thus the GFEP is aimed more at seasoned developers rather than just the curious.

5. Future direction: example-based grammar writing

It is typically the case that the writer of a GF concrete grammar is at least fluent in the language and has GF skills which are directly proportional with the complexity of the abstract syntax to implement. However, in the case of a rather complex multilingual grammar comprising 5 to more languages, as for instance was the case with the MOLTO Phrasebook(reference...) which was first available in 14 languages and which has a reasonably rich semantic interlingua, the task of finding grammar developers is a difficult one. Even if there exist such developers, their task can still be made easier, by trying to automate where possible, and alleviate over certain technicalities of GF programming that would slow down the grammar development.

When writing a application grammar, one such problem would be to use the resource library in order to build generate text for a given language with the help of the primitives already defined in the correspondent resource grammar. For this, however, one needs to be familiar with the almost 300 existing functions, assuming that the domain writer is different than the resource grammar write, as it is often the case.

In order to make the users' task easier, an API is provided so that the domain grammar writer only needs to know the GF categories and how they can be built from each other. This layer makes the interaction with the resource library smoother for users, and also makes it easier to make new constructions from the library available.

For example, the sentence "I talked to my friends about the book that I read", is parsed to the following abstract syntax tree:

  UseCl (TTAnt TPast ASimul) PPos (PredVP (UsePron i_Pron) (ComplSlash 
  (Slash3V3 talk_V3 (DetCN (DetQuant DefArt NumSg) (RelCN (UseN book_N) 
  (UseRCl (TTAnt TPast ASimul) PPos (RelSlash IdRP (SlashVP 
  (UsePron i_Pron) (SlashV2a read_V2))))))) 
  (DetCN (DetQuant (PossPron i_Pron) NumPl) (UseN friend_N))))
  

If we use the API constructors, the abstract syntax tree is simpler and more intuitive:

  mkS pastTense (mkCl (mkNP i_Pron) (mkVP (mkVPSlash talk_V3 (mkNP the_Art 
  (mkCN (mkCN book_N) (mkRCl pastTense  (mkRCl which_RP (mkClSlash 
  (mkNP i_Pron) (mkVPSlash read_V2))))))) (mkNP (mkQuant i_Pron) 
  plNum friend_N)))

In this way, the domain grammar writer, can just use the functions from the API, and combine them with lexical terms from dictionaries and functions from outside the core resource library that implement non-standard grammatical phenomena, that do not occur in all languages.

One step further in the direction of automating the development of domain grammars is to have the possibility to enter function linearizations as a positive example of their usage. This is particularly helpful in larger grammars containing syntactically complicated examples that would challenge even the more experienced grammarians. If instead an example is provided, even though the grammar could return more than one parse tree, the user can select the good tree or take advantage of the probabilistic ranking and take the most likely one.

The example-based grammar writing system is still work in progress, but there is a basic prototype of it available already, and it will be further developed and improved. The basic steps of the system will be shortly described further on, along with the directions for future work.

The typical scenario is a grammarian working on a domain concrete grammar for a given language - which we call X for convenience.

In this case, he would need at least a resource grammar for X. Preferably there should also be a large lexical dictionary and/or a larger-coverage GF grammar with probabilities. Currently, larger lexical resources exist for English, Swedish, Bulgarian, Finnish and French. For Turkish there exists a large lexicon also, but the resource grammar is not complete.

We also assume that the user has an abstract syntax for the grammar already and that the _lincats_ (namely representations of the abstract categories in the concrete grammar) are basic syntactic categories from the resource grammar(NP, S, AP).

Consequently, the functions from the abstract syntax will be grouped in a topological order, where the ordering relation a < b <=> b takes a as argument in a non-recursive rule. There are no cycles in this chain of ordered elements, since a similar check is being performed at the compilation stage. The elements will be ordered in a list of lists - where every sub-list represents incomparable elements. The user will be provided first with the first sub-list and after completing it, with the next ones.

For each such function, an abstract tree from the domain grammar having as root the given function will be generated. The arguments are chosen among the functions already linearized. In case that another concrete grammar exists already, the user can also see a linearization of the tree in the other language, and also an example showing how the given construction fits into a context. For example, if the user needs to provide an example for Fish in a given grammar, say the tourist phrasebook, and there is an English grammar already then he would get a message asking him to translate fish as in "fish" / "This fish is delicious".

When providing the translation, the user will be made aware of the boundaries of the grammar, by the incremental parser of the resource grammar. If the example can be parsed and the number of parse trees is greater than 1, then either the user can pick the right one, or the system can choose the most probable tree as a linearization. From here, the system will also generalize the tree by abstracting over the arguments that the function could have. Finally the resulting partial abstract syntax tree will be translated to an API tree and written as linearization for the given function.

The key idea is based on parsing, followed by compilation to API and provides considerable benefits,especially for idiomatic grammars such as the Phrasebook, where the abstract syntax trees are considerably different. For example, when asking for a person's name in English the question "What is your name" would be written using API functions as:

  mkQCl (mkQCl whatSg_IP (mkVP (mkNP (mkQuant youSg_Pron) name_N)))

which stands for the abstract syntax tree:

  UseQCl (TTAnt TPres ASimul) PPos (QuestVP whatSg_IP (UseComp 
    (CompNP (DetCN (DetQuant (PossPron youSg_Pron) NumSg) (UseN name_N)))))

On the other hand, in French the question would be translated to "Comment t' appelles tu" (literally translated to "How do you call yourself") which is parsed to:

  UseQCl (TTAnt TPres ASimul) PPos (QuestIAdv how_IAdv 
    (PredVP (UsePron youSg_Pron) (UseV appeler_V)))

and corresponds to the following API abstract tree:

  mkQS (mkQCl how_IAdv (mkCl p.name appeler_V)))

Currently, steps are made to integrate the system with the Web Editor and in this way combine the example-based methods with traditional grammar writing. In this case the set of functions that can be linearized from example will be computed incrementally, depending on the state of the code.

A similar procedure to the one that determines which functions can be linearized from example can be used to find the functions that can be tested - functions already linearized that can be learned from example. In this way, the functions linearized in the editor - manually or by example can be also tested by randomly generating an expression and linearizing it in the language that is under development and also in one or more languages for which a concrete grammar exists. In case the linearization is not correct, the user can proceed to ask for a new example, or to modify the linearization himself.

Other plans for future work, in addition to integrate the method with the GF Web Editor, include a thorough evaluation of the utility of the method for larger grammars and with grammarians of different levels of GF skills. Moreover, we plan to include a handle for unknown words, that should make it easier for the user to build a small lexicon from examples.

As a solution to this, we devised the example-based grammar learning system, that is meant to automate a significant part of the grammar writing process and ease grammar development.

The two main usages of the system are to reduce the amount of GF programming necessary in developing a concrete grammar and the second and more important - to make possible learning certain features of a language for grammar development.

In the last years, the GF community constantly increased and so did the number of languages from the resource library and the number of domain grammars using them. The writer of a concrete domain grammar is typically different than the writer of the resource grammar for the same language, has less GF skills and is most likely unaware of the almost 300 constructors that the resource grammars implement for building various syntactical constructions; see http://www.grammaticalframework.org/lib/doc/synopsis.html.

6. Conclusion

We have presented two IDE's for GF. The web-based IDE is a stable system, which makes it easy to develop multilingual applications in the cloud. The Eclipse plugin brings GF to one of the leading desktop environments of software development. It is already usable for simple tasks such as syntax highlighting and cross-modular references, but more functionalities are being added; the further development of the Eclipse plugin will be sensitive to the actual users in the other sites of the MOLTO project. In addition to the IDE's, we have introduced the technique of example-based grammar writing, which has already been implemented as a desktop shell program and within the web-based IDE.

The IDE's are expected to make the use of GF more efficient for power users and more accessible for beginning users. The success in this will be monitored and evaluated in the case studies of the MOLTO project.

1. Introduction

MOLTO promises a translation tool based on Grammatical Framework, a programming language for multilingual grammars. The Grammatical Framework (GF) is used in the MOLTO project to build translation systems for EU languages. The user of the MOLTO translation tool need not know how to write GF grammars. She is supposed to use domain specific grammars developed by others to translate documents in the domains covered. Basic domain language coverage does not guarantee that all terms and idioms in the translatable document are covered. The MOLTO translation tool should handle lexical gaps in a way that benefits and benefits from a wider community of translators. It should also provide fallback solutions when a text is not covered by the available grammar(s).

This report explains the components of the MOLTO translation tool API. The API is the main value because end user translation environments and tools are many and change quickly with time, while MOLTO tools should have a more long lasting value. The components of the API include at least the following (The Core API):

• translation editor
• grammar manager
• document manager
• term manager

Provisions for interfacing with further typical CAT tool components will be considered (The Extended API).

WP3 design diagram:

A model implementation of MOLTO translation tools based on the API will be demonstrated in the MOLTO prototype due as deliverable 3.2 in February 2012.

2. Translation scenarios

GF is a multilingual interlingual translation system geared toward multilingual generation. As a proof of concept, GF demos display immediate generation into dozens of languages from a tiny grammar. Extended to a more realistic case, this scenario could have a native-language editor producing text for more or less immediate multilingual distribution, for instance, a multilingual website. For this scenario to work, the translations should be acceptable as is without target language native revision.

The GF approach as such suits best an authoring/pre-editing scenario, where an original author or authorised content editor can choose or edit the original message to conform to a domain specific constrained language grammar, which GF is then expected to blind translate reliably to a number of languages. In real life situations, the text to translate is likely to be at least partially new to the system, and no guarantee can be given that the translation is correct in all the generated languages. It is specifically such extensions of the original MOLTO "fridge magnet" demo scenario that this document tries to address.

The current professional human translation scenario is quite different. It is a post-editing scenario. The roles of author (client) and translator are separated. The translator has quite restricted authority over the target text and almost none over the original, aside from obvious errors. The translation process is normally bilingual. This is because the translation is created or at least chosen by human, and human translators rarely have professional competence in more than one or two languages besides their native language.

The preferred professional translation direction is from a second language to native language, because for humans language generation is more demanding than language understanding. In this direction, the translator can exploit external resources to understand the source text and use her native competence to check the quality of the target text. Even in this case, a native subject expert is usually needed to check the translation. The reviser need not know the source language or have the source text at hand.

The extended MOLTO translation scenarios considered here spread between these two extremes. We may still assume that the translator has some authority over the text to produce, i.e. she is the author or is authorized to adapt the text to better satisfy the constraints of the translation grammar. The MOLTO pre-editor/translator should be native or at least fluent in the source language, and familiar with the domain or at least its special language in order to know how the message can be (para)phrased. Thus the extended MOLTO scenario retains an element of constrained-language authoring or pre-editing.

But we may need to relax the blind generation assumption. Although the GF engine may give warnings or suggestions when it is unsure or knows the translation fails, there are likely to be cases where the translation is technically correct, but inadequate for human consumption. A native revision is then needed for one or more target language(s). As in the human translation case, the author/translator can at best serve as informant for one or a few target languages. For the rest, the translation needs to be distributed to a pool of revisers. In real life, a translation has to go out even if GF fails. There must be a way to override GF with human translations. If the translation were a one-off affair, that could end the process. However, in many real life scenarios, the same or very similar texts will come up for (re)translation, and in that case, the results of the revisions should get fed back to the translation cycle, to avoid making the same errors twice. In other words, we should make the MOLTO translation system consisting of GF and the human users an adaptive whole. This is the most demanding part to conceive here. Pre-editing MT has not been very successful in the past, probably partly just because not enough attention has been given to practical concerns like these.

Translation industry standards

As document automation progresses, professional translation is merging into localization, or the adaptation of software to a new locale (language and culture). Translation used to differ from localization in that translators were not expected to worry about formats or the document lifecycle. Translations were shipped to translators as raw text and returned as such. In an intermediate phase, a specialized localization industry developed to multilingualize software, preserving the source format. More recently, with multi channel publishing and document toolchains, there is again a push to separate form from content. The localization industry solution to these conflicting pressures is to separate content from form in a reversible fashion. Localization formats and tools like Gnu gettext and XLIFF make provisions for extracting the translatable text from a document in a way that allows embedding the target text in the same document form.

The current GF translation engine as such is neutral about the format of the text it receives, but the existing resource grammars expect text to come in raw form. It should be technically possible to include document formatting in GF parsing and generation, and if suitably restricted, that might be the most efficient solution for the translation of inline tags. However, for the rest, it seems best to take advantage of existing content extraction technologies in translation industry. We propose to use XLIFF for MOLTO translatable document format in the extended API.

XLIFF is one of the OASIS LISA OAXAL standards. As of 2011 February 28, the Localization Industry Standards Association (LISA) is insolvent. The LISA standards continue to be used by the industry. The OASIS Open Architecture for XML Authoring and Localization (OAXAL ) reference model, comprises the following open standards:

• Unicode
• XLIFF ‐ OASIS XML Localization Interchange File Format
• SRX – LISA Segmentation Rules Exchange
• TMX – LISA Translation Memory Exchange
• GMX/V – LISA Word and Character Count Standard
• W3C ITS – Internationalization Tag Set
• xml:tm – LISA XML based text memory

Translation tools survey

For the extended scenario, we may add other industry standard CAT tools for MOLTO translators to use besides the core list above. There is a plethora of packages for CAT and translation project management/automation both commercial and open source. It seems best to borrow from existing open source packages that comply with translation industry standards, instead of reinventing the wheel. Examples of CAT packages are

• OmegaT http://www.omegat.org/
• OpenTM2 http://www.opentm2.org/
• OpenTMS http://www.opentms.de/?q=en/node/27
• TinyTM http://tinytm.sourceforge.net/
• SwordFish http://www.maxprograms.com/products/swordfish.html
• Heartsome http://www.heartsome.net/EN/home.html

SwordFish and HeartSome are commercial. Examples of translation project management and workflow automation packages are

• ProjectOpen http://www.project-open.com/en/modules/index.php
• GlobalSight http://www.kmworld.com/Articles/News/News/Open-source-translation-management-52166.aspx
• SDL WorldServer http://www.sdl.com/en/language-technology/products/translation-management/worldserver/default.asp
• Across v5 http://www.across.net/en/index.aspx
• XTM http://www.xtm-intl.com/

Of the systems listed above, ProjectOpen and GlobalSight are open source, the rest are commercial.

From existing open source projects we can shop for properties generally expected from TM (http://en.wikipedia.org/wiki/Translation_memory), CAT (http://en.wikipedia.org/wiki/Computer-assisted_translation), and translation project management software. Some commercial systems also have open interfaces, e.g. Across (http://en.wikipedia.org/wiki/Across_Systems). Here are some translation tools listings from the Web.

• http://socialsourcecommons.org/toolbox/show/1107
• http://translatewiki.net/wiki/Main_Page
• http://www.translatewrite.com/foss/index.php?s=foss
• http://www.i18nguy.com/TranslationTools.html
• http://www.translatorstraining.com/sito/

For comparisons, see e.g. Wikipedia.

3. Translation process

Here we study variants of the machine assisted translation process, to develop a version that suits MOLTO.

The translation industry workflow

To have a point of comparison, we review the practices in the professional translation industry today. Going beyond the 90's single-user computer-assisted translation (CAT) setup with a translation editor, translation memory, and termbase, current translation management system (TMS) packages provide tools for managing complex translation industry projects involving clients, project managers, and a distributed pool of translators, reviewers, and subject experts. Many aspects of the workflow and the associated communication (notification, document transfer) can be automated in these systems. For an example of a translation industry workflow, we take the ]project-open[ Translation Workflow. Tasks typically covered by translation project and workflow management packages include

• Analyzing source text using a translation memory
• Generating quotes for the customer
• Generating purchase orders for providers and freelancers
• Executing the project
• Monitoring the project
• Generating invoices to the customer
• Generating invoices for providers and freelancers

Roles within the translation workflow

In ]project-translation[ five user roles can be defined.

• Translator: A person responsible to execute the translation and/or localization projects.
• Project Manager: A person responsible for the successful execution of projects. Project Managers frequently act as Key Account managers in small translation agencies.
• Senior Manager: Is responsible for the financial viability of the business and is the ultimate responsible for the relationships to customers
• Key Account Manager: A person responsible for the relationship to a number of customers. We assume that customer project requests are handled by a Key Account Manager and then passed on to a project Manager for execution.
• Resource Manager: A person responsible for the relationship with translation resources and providers.

GlobalSight has yet more default roles:

• Administrator
• Customer
• LocaleManager
• LocalizationParticipant
• ProjectManager
• SuperAdministrator
• SuperProjectManager
• VendorAdmin
• VendorManager

New roles can be invented at will in GlobalSight. As discussed in the MOLTO requirements document (Deliverable 9.1), The role cast in MOLTO can have at least these roles:

• Author
• Editor
• Translator
• Reviewer (domain/language expert)
• Ontologist
• Terminologist
• Grammarian

The Project Cycle

The figure below shows in a schematic way in which the workflow proceeds:

• A document from the customer is passed to the project manager for translation (This action is represented by the arrow from documents in the upper left corner from the client to the project manager).
• The Project Manager uploads the document into the ]project-open[ System
• A translators downloads the file
• The same translators uploads the translated files

Similarly for editors and proofreaders. Finally, the project manager retrieves the document and sends it to the customer. Alternatively, the project manager can allow the customer to download the files directly. In addition to tracking the status of a project at every stage, the system allows the project manager to allocate projects to the most suitable team and streamline the freelancers’ job.

GlobalSight

GlobalSight (http://www.globalsight.com/) is an open source Translation Management System (TMS) released under the Apache License 2.0. Version 8.2. was released on Sept 15, 2011. As of version 7.1 it supports the TMX and SRX 2.0 Localization Industry Standards Association standards.[2] It was developed in the Java programming language and uses MySQL database and OpenLDAP directory software. GlobalSight also supports computer-assisted translation and machine translation.

According to the documentation the software has the following features:

• Customizable workflows, created and edited using graphical workflow editor
• Support for both human translation and fully integrated machine translation (MT)
• Automation of many traditionally manual steps in the localization process, including: filtering and segmentation, TM leveraging, analysis, costing, file handoffs, email notifications, TM update, target file generation
• Translation Memory (TM) management and leveraging, including multilingual TMs, and the ability to leverage from multiple TMs
• In Contect Exact matching, as well as exact and fuzzy matching
• Terminology management and leveraging
• Centralized and simplified Translation memory and terminology management
• Full support for translation processes that utilize multiple Language Service Providers (LSPs)
• Two online translation editors
• Support for desktop Computer Aided Translation (CAT) tools such as Trados
• Cost calculation based on configurable rates for each step of the localization process
• Filters for dozens of filetypes, including Word, RTF, PowerPoint, Excel, XML, HTML, Javascript, PHP, ASP, JSP, Java Properties, Frame, InDesign, etc.
• Concordance search
• Alignment mechanism for generating Translation memory from previously translated documents
• Reporting
• Web services API for programmatic access to GlobalSight functionality and data
• Integrated with Asia Online APIs for automated translation

GlobalSight Web Services API

GlobalSight provides a web services API (http://www.globalsight.com/wiki/index.php/GlobalSight_Web_Services_API). It is used to integrate external systems to GlobalSight in order to submit content to the localization/translation work-flow, and monitor its status. The Web services API allows any client to connect and exchange data with GlobalSight, regardless of its implementation technology or operating system. The web service provides methods for

• Authentication
• Content Import
• Project management
• Activity and task management
• User management
• Locale management
• Job management
• Content export
• Documentum support
• Translation Memory management
• Term Base management
• CVS support

For convenience, we shall borrow parts of the MOLTO extended API from the GlobalSight translation management system.

The web localization workflow

The translation industry workflow is top-down controlled, built on email and file transfers. For a more collaborative bottom-up approach, we can look at web localization. Web platforms are getting localized by a collaborative translation workflow. Here, translation is typically crowdsourced to a pool of volunteers, who either translate manually online or download po files to work on with local tools. The website coordinates the effort. Different projects may have assigned managers that monitor the collaboration. It is exemplified by the Translate toolkit (http://en.wikipedia.org/wiki/Translate_Toolkit) used to collaboratively localize open source software packages.

An instance of the Translate toolkit is Pootle http://en.wikipedia.org/wiki/Pootle, an online translation management tool with translation interface. It is written in the Python programming language using the Django framework and is free software originally developed and released by Translate.org.za in 2004. It was further developed as part of the WordForge project and the African Network for Localisation and is now maintained by Translate.org.za.

Pootle is intended for use by free software translators but is usable in other situations. Its main focus is on localization of applications' graphical user interfaces as opposed to document translation. Pootle makes use of the Translate Toolkit for manipulating translation files. The Translate Toolkit also offers offline features that can be used to manage the translation of Mozilla Firefox and OpenOffice.org in Pootle. Some of Pootle's features include terminology extraction, translation memory, glossary management and matching, goal creation and user management.

It can play various roles in the translation process. The simplest displays statistics for the body of translations hosted by the server. Its suggestion mode allows users to make translation suggestions and corrections for later review, thus it can act as a translation specific bug reporting system. It allows online translation with various translators and lastly it can operate as a management system where translators translate using an offline tool and use Pootle to manage the workflow of the translation.

The Translate Toolkit API is documented at http://translate.sourceforge.net/doc/api/. It is open source subject to the GPL licence. The Google Translator Toolkit

Google provides a free service for translating webpages by post-editing Google MT results. The toolkit allows users to

• Upload and translate documents
• Use documents from your desktop or the web.
• Download and publish translations
• Publish translations to Wikipedia™ or Knol.
• Chat and share translations online
• Collaborate online with other translators.
• Use advanced tools like translation memories and multilingual glossaries.

The Google Translator Toolkit Data API allows client applications to access and update translation-related data programmatically. This includes translation document, translation memory, and glossary data stored with Google Translator Toolkit. The Google Translator Toolkit API is now a restricted API (http://code.google.com/apis/gtt/).

The MOLTO translation workflow

We now consider the MOLTO translation scenario. The MOLTO translation demo editor (see figure further below) supports a one-person workflow where the same person is the author(ised editor) of the source and the translator. Technically we can extend this to a more collaborative scenario where more actors are involved as in the professional workflow above, by adding the usual project support tools to the toolkit. A more difficult part is to adjust the workflow so that the adaptivity goal above is satisfied. In the professional workflow, corrected translations accumulate in the translation memory, which helps translators avoid the same errors next time. In the MOLTO workflow, GF has an active role in generating translations, so it is GF that should learn from the corrections. Concretely, when a translator or reviser changes a wording, the correction should not go unnoticed, but should find its way to back to the GF grammar, preferably through a round of community checks.

We next try a description of one round of the ideal MOLTO translation scenario.

Although it is possible that an author is ready to create and translate in one go (especially in a hurry), it is more normal to have some document(s) to start from. The document/s might be created in a GF constrained language editor in the first place. In that case, the only remaining step is translation. If translation coverage and quality has been checked, nothing more is neeeded. But frequently, some changes are needed to a previously translated document, or a new one is to be created from existing pieces and some new material. Imaginably, some of the parts come from different domains, and need to be processed with different grammars. Some such complications might be handled with document composition techniques in the manner of Docbook or DITA toolchains.

The strength of GF is that it ought to handle grammatical variation of existing sources well, so as to avoid manual patching of previous translations. Assume there is a previously GF translated document, and we want to produce a variant. Then it ought to be enough to load the document, make desired changes to it under the control of the GF grammar, and let GF generate the modified translations.

Is it necessary to show the translations to the user? Not unless the translator knows the target language(s). We should distinguish two profiles: blind translation, where the author does not know or is not responsible for the target languages herself, but relies on outside revision, and plain translation, in which there is one or two target language known to the author/translator to translate to, who wants to check the translations as she goes.

In the blind profile, the author has to rely on revisers, and the revision cycle is slower. The revisers can either notify the author that the source does not translate correctly in their language(s), or they may notify the grammar/lexicon developer(s) directly, or both. If there is a hurry, the reviser/s should provide a correct translation directly for the author/publisher to use as canned text. In addition, they should notify the grammar developer/s of the revisions needed to GF. The notification/s could happen through messages, or conveyed through a shared translation memory, or both. In this slower cycle, it may not be realistic to expect the author to change the source text and repeat the revision process many times over for the same source and possibly a multiplicity of languages to get everything translate right before publication.

In the plain profile, a faster cycle of revision is called for. The author/translator can try a few variations of the input. If no variant seems to work, then she probably wants to use her own translation, but also to make sure that GF learns of and from the failure. The failure can be a personal preference, or a general fix that the community should profit from. If it is a personal preference, the user may want to save the corrected translation in her translation memory and/or glossary, but also she may want to tweak her GF grammar to handle this and similar cases to her liking next time. If it is just a lexical gap or missing fixed idiom, then there should be in GF translation API a service to modify the grammar without knowing GF. The modifications could happen at different levels of commitment. The most direct one would be to provide a modular PGF format which would allow advising the compiled user grammar on the fly. Such a runtime fix would make sure that the same error will not happen during the same translation session or subsequent ones at least until the domain grammar is recompiled.

The next level of commitment to a change would be to generate new GF source, possibly from example translations provided by the author/translator, compile them, and add the changed or extra modules to the user's GF grammar. The cycle involved here might be too slow to do during translation, but it could happen between translation sessions. If fully automatic grammar revision is too error prone, the author/translator could just go on with canned translations in this session, and commit change requests to the grammar developer community. In this case, the changes would be carried out in good time, with regression tests and multilingual revision cycles, especially if the changes affect the domain semantics (abstract grammar) and thereby all translation directions.

4. MOLTO Translation tools API

The MOLTO Translation Tools API exposes the most important operations used in translating with GF in MOLTO. It makes them available for programmers who want to create alternative accesses to GF translation tools, besides the MOLTO web translation demo platform. The API is divided into a Core API basically answering the needs of a single author/translator, and an Extended API addressing the needs of a community of authors, translators, and grammar engineers.

The components of the MOLTO TT Core API include at least the following:

1. sign in
2. grammar manager
3. document manager
4. term manager
5. translation editor

The components of the MOLTO TT Extended API include the following:

1. user management
2. grammar management
3. document management
4. lexical resources
5. translation editing
6. translation memory
7. reviewing/feedback
8. grammar engineering

The first five are extensions of the corresponding facilities in the Core API. The lexical resources API borrows from TermFactory. The translation memory and the reviewing/commenting facilities are adapted from GlobalSight. The last item is based on the GF grammar development tools API.

The MOLTO Translation Tools Core API

The core API basically provides for the one-editor/translator scenario, where an editor/translator creates or edits a source document under constraints of a selected GF grammar in PGF form and generates translations for the source. For lexical gaps (out-of-vocabulary items) there is a simple term editor which allows looking up concepts and adding equivalents. The demo prototype translation editor

This section describes the translation editor developed by K. Angelov at UGOT.

To guide the development of a suitable translation editor API to support MOLTO translation needs, UGOT has created a prototype web-based translation editor. It is implemented in Google Web Toolkit. It is usable for authoring with small multilingual grammars. It doesn't require any downloads or use of command shells. All that is needed is a reasonably modern web browser.

The editor runs entirely in the web browser, so once you have opened the web page and have documents and grammars loaded, you can continue translation editing while you are offline.

Sign in

Signing in should allow a user controlled access to her own and some (maybe not all) shared resources. Ideally, the same login should work throughout the different parts of the distributed toolkit. There should be some group scheme to set group level access restrictions.

For basic sign in needs, the demo editor currently uses the Google authentication API.

Web applications that need to access services protected by a user's Google or Google Apps (hosted) account can do so using the Google Authentication service. This service lets web applications get access without ever handling their users' account login information. Google offers two libraries for handling authentication: one using the OAuth open standard, and a second interface called AuthSub, developed prior to the release of the OAuth standard. Authentication and authorization for Google APIs allow third-party applications to get limited access to a user's Google accounts for certain types of activities.

Grammar manager

The demo editor has a simple grammar manager that retrieves the user's grammars from a mySQL database via a ContentService implemented in Haskell, subject to a successful login through Google.

Available operations in ContentService:

• login
• update_grammar
• delete_grammar
• grammars (listing)
• save
• load (document from mysql db)
• search
• delete

Document manager

The demo editor has a simple file database manager that uploads and requests the user's documents from a mysql database using the same ContentService as the grammar manager.

Term manager

The demo editor has a simple treegrid editor for searching and editing translation correspondences from the web of data, including TermFactory services. It is not yet connected to the GF grammar back end. The management of lexical resources and ontologies is detailed in connection with the extended API below.

Editor

The editor guides the text author by showing a set of fridge magnets and offers autocompletion to hint how a text can be continued within the limits of the current grammar. In the current version, there is a sign-in box and tabs for grammars, documents, editor, and terms, plus two to query and browse the loaded grammar.

The prototype gives a first rough idea of how a web based GF translation editor could work. While this editor is implemented in JavaScript and runs entirely in the web browser, we do not expect to create a full implementation of the MOLTO translation tools that runs in the web browser, but let the editor communicate with outside servers, including a TMS server (Globalsight) and a GF server.

The MOLTO Translation Tools Extended API

User management

For more flexibility (as well as vendor independence), an open source LDAP (The Lightweight Directory Access Protocol) based user management implementation can be used. There is one in GlobalSight. It allows distinguishing different roles and user groups, and controlling access to resources by roles.

Document management

The simple document manager of the demo editor will be complemented with a more sophisticated XLIFF based document manager built using the GlobalSight document management API. Document format conversions belong to the day's work in the translation business, and they can be assumed to be handled by the extended dcoument manager, using XLIFF as a fixpoint.

XLIFF (XML Localisation Interchange File Format) is an XML-based format created to standardize localization. XLIFF was standardized by OASIS in 2002. Its current specification is v1.2[1] released on Feb-1-2008. The XLIFF Technical Committee is currently at work on XLIFF 2.0. The specification is aimed at the localization industry. It specifies elements and attributes to aid in localization.

XLIFF cognizant open source editors and localization platforms include

• Benten - an open source XLIFF editor written in Java.
• OmegaT - a cross-platform and open source CAT tool.
• Pootle - a web-based localisation platform.
• Heartsome - a suite of cross-platform CAT (Computer-assisted translation) tools founded on open standards: XLIFF, TMX, TBX, SRX, XML, GMX. It also provides a free Lite version.
• Swordfish III - a cross-platform CAT tool that uses XLIFF 1.2 as native format.
• Virtaal - an open source CAT tool.
• XTM - a highly collaborative web server based CAT environment with extensive support for XLIFF (1.0 through to 1.2) as well as an implementation of the OASIS OAXAL architecture.

Examples of XLIFF Documents

Example 1: A simple XLIFF file with strings extracted from a Windows RC file. Here the skeleton (the data needed to reconstruct the original file are) is stored in a separate file:

<?xml version="1.0" encoding="windows-1252" ?>
<xliff version="1.1" xml:lang='en'>
 <file source-language='en' target-language='fr' datatype="winres"
  original="Sample1.rc">
  <header>
   <skl><external-file href="Sample1.rc.skl"/></skl>
  </header>
  <body>
   <group restype="dialog" resname="IDD_DIALOG1">
    <trans-unit id="1" restype="caption">
     <source>Title</source>
    </trans-unit>
    <trans-unit id="2" restype="label" resname="IDC_STATIC">
     <source>&Path:</source>
    </trans-unit>
    <trans-unit id="3" restype="check" resname="IDC_CHECK1">
     <source>&Validate</source>
    </trans-unit>
    <trans-unit id="4" restype="button" resname="IDOK">
     <source>OK</source>
    </trans-unit>
    <trans-unit id="5" restype="button" resname="IDCANCEL">
     <source>Cancel</source>
    </trans-unit>
   </group>
  </body>
 </file>

</xliff>

Example 2: an XLIFF document storing text extracted from a Photoshop file (PSD file) and its translation in Japanese:

<xliff version="1.2">
 <file original="Graphic Example.psd"
  source-language="en-US" target-language="ja-JP"
  tool="Rainbow" datatype="photoshop">
  <header>
   <skl>
    <external-file uid="3BB236513BB24732" href="Graphic Example.psd.skl"/>
   </skl>
   <phase-group>
    <phase phase-name="extract" process-name="extraction"
     tool="Rainbow" date="20010926T152258Z"
     company-name="NeverLand Inc." job-id="123"
     contact-name="Peter Pan" contact-email="ppan@xyzcorp.com">
     <note>Make sure to use the glossary I sent you yesterday.
      Thanks.</note>
    </phase>
   </phase-group>
  </header>
  <body>
   <trans-unit id="1" maxbytes="14">
    <source xml:lang="en-US">Quetzal</source>
    <target xml:lang="ja-JP">Quetzal</target>
   </trans-unit>
   <trans-unit id="3" maxbytes="114">
    <source xml:lang="en-US">An application to manipulate and 
     process XLIFF documents</source>
    <target xml:lang="ja-JP">XLIFF 文書を編集、または処理
     するアプリケーションです。</target>
   </trans-unit>
   <trans-unit id="4" maxbytes="36">
    <source xml:lang="en-US">XLIFF Data Manager</source>
    <target xml:lang="ja-JP">XLIFF データ・マネージャ</target>
   </trans-unit>
  </body>
 </file>

</xliff>

XLIFF is bilingual (each translation unit offers a and a elements). There are however ways to have multilingual XLIFF documents:

• Each <file> element can have different source/target pairs.
• The language of the data in the <alt-trans> element can be different from the main source/target languages. This allows alternative translations coming from a different language. For example: French (fr-FR) proposed translations could be offered when translating into French Canadian (fr-CA), and so forth.

In the GF interlingual model, the source "language" can be the abstract syntax representation of a translation unit.

The above considerations entail some requirements for translation-time document management in the MOLTO Translation tools API:

Associated to the MOLTO Translation Tools API, there must be tools for extracting XLIFF content documents out of various types of original skeleta and putting translated content back to the skeleton. (These tools are outside of MOLTO proper on the because many such tools already exist and because it is up to the provider of a new document type to also provide XLIFF support for it.)
There must be methods in the Molto Translation API for extracting raw text from XLIFF source elements, feeding it into GF and inserting the translation into the XLIFF target element. The GF translation API should also have methods for handling XLIFF coded inline tags. The best solution for that could be a special purpose GF grammar, because the correct placement of inline tags can depend on the translation of the content. 

Lexical resources

A key consideration for the usability of MOLTO translation is the ease with which its text coverage can be extended by a user community. We need to pay great attention to adaptability. The most important factor in extensibility is lexical coverage. Grammatical coverage can be developed and maintained with language engineering, and grammatical gaps can often be circumvented by paraphrasing. There are two cases to consider: either the abstract grammar misses concepts, or concrete grammars for some language/s are missing equivalents. In the first case, we need to extend the domain ontology and its abstract grammar. In the second case, we need to add terms.

For ontology and term management, we propose to apport to MOLTO the TermFactory ontology based terminology management concept. TermFactory is a system of distributed multilingual term ontology repositories maintained by a network of collaborative management platforms. It has been described at length in the TermFactory Manual at http://www.helsinki.fi/~lcarlson/CF/TF/doc/TFManual_en.xhtml.

The user of the MOLTO translation editor has direct access to the treegrid editor for querying and editing term equivalents for concepts already in available ontologies, either already in TermFactory or 'raw' from the Web of Data, in particular, the OntoText services serving data from FactForge repository.

Term management

Say for instance there is no equivalent listed for cheese in some language's concrete grammar FooLang. The author/translator can use the treegrid editor to query for terms for the concept food:Cheese in TermFactory or do a search through OntoText services for candidate equivalents, or, if she knows the answer herself, submit equivalents through the treegrid editor. The new equivalent/s are saved in the user's own MOLTO lexicon, and submitted to TermFactory as term proposals for the community to evaluate.

Ontologies

If there is a conceptual gap not easily filled in through the treegrid editor, there is the option of forwarding the problem to an appropriate TermFactory collaborative platform. This route is slower, but the quality has a better guarantee in the longer run, as inconsistency or duplication of work may be avoided. Say there is no concept in the domain ontology for the new notion that occurs in the source text. In easy cases, new concepts can be added through the treegrid editor, subclassing some existing concept in the ontology. In more complex cases, where negotiations are needed in the community, an ontology extension proposal is submitted through a TermFactory wiki. TermFactory offers facilities for discussing and editing ontologies and their terms. In due time, them modified ontology gets implemented in a new release of the GF domain abstract grammar. Translation editing

The translation editor demo is a good prototype, but different scenarios and platforms may call for different combinations of its features. One way to go is to extend the demo with further tabs and facilities for CAT tool support. But there is the also the opposite alternative to consider of calling MOLTO translation tool services from a third party editor. GlobalSight has two built in translation editors, called popup editor and inline editor. The popup editor is a Trados TagEditor lookalike, while the inline editor has something of the look and feel of old Trados versions running WYSIWYG on Microsoft Word. The inline editor has been implemented in javascript using the FCKEditor library. It might just be feasible to embed MOLTO demo editor functionalities into the GlobalSight editor(s). In the Globalsight setup, there is already support for importing cut-and-dried MT translations from a MT service, but here we are talking about something rather more intricate.

It is not immediately obvious which route would provide least resistance. From the point of view of GF usability, finding a neat way of embedding GF editing functions in third party translation editors could be a better sales position than trying to maintain a whole new MOLTO translation environment. (Unless of course, the new environment is clearly more attractive to targeted users than existing ones.) We may also try to have it both ways.

Reviewing/feedback

It was noted above that blind translation in the case of incomplete or inadequate coverage in resource grammars can occasion a round of reviewing and giving feedback on the translations before publication. This part of the process is in its main outlines familiar from the translation industry workflow, and can be implemented as a variation of it. In the MOLTO workflow, reviewer comments are not returned (just) to the human author/translator(s), but they should have repercussions in the ontology and grammar management workflows. This part requires modifying and extending the existing GlobalSight revisioning tools to communicate with the MOLTO lexical resources and grammar services. The GlobalSight revisioning tools now use email as the human-to-human communication channel. We probably want to use a webservice channel for machine-to-machine communication, and possibly some web commenting system as an alternative to email.

Grammar engineering

To the extent grammar engineering can be delegated to translation tool users, it must happen transparently without requiring knowledge of GF. One way to do this is through what is known as example-based grammar writing in GF. Example-based grammar writing is a new GF technique for backward-engineering GF source from example translations. It can play a significant role in the translation-to-grammar feedback cycle. This part of the TT API will be borrowed from the MOLTO Grammar Developer Tools API. See the last section of this document.

5. Web services API for the MOLTO Translation Tools

To develop the above outlined web-based translation environment further, or implement other usage scenarios, a web service interface to the MOLTO editor API will be useful. The interface consists of several parts.

• Translation editor demo
• Globalsight API (adapted for MOLTO)
• TermFactory API (adapted for MOLTO)
• OntoText API
• MOLTO Grammar Tools API
• Translation tools glue

The editor demo is in the MOLTO darcs repository. The services provided by the GF server are outlined in the MOLTO Grammar Tools API document. The GlobalSight WS API was described above. The TermFactory web services are documented in the TF Manual at http://www.helsinki.fi/~lcarlson/CF/TF/doc/TFManual_en.xhtml#Services .

The translation tools glue connects the different parts of the whole. It includes at least:

• treegrid editor back end: answers queries to populate the editor from TF and Ontotext repositories, and communicates user additions to TF and the GF grammar editing services (see next section).
• linking between translation editor/s, translation leveraging tools (TM/termbank) and GF services
• linking between the MOLTO (GlobalSight) TT reviewing system and TermFactory
• linking between the MOLTO (GlobalSight) TT reviewing system and GF grammar editing services
• conversion between TermFactory ontology format and GF abstract grammar format

Here is a figure showing some of the connections in the design.

Requirements on the GF grammar and translation APIs

The above design generates a wishlist of requirements on the GF grammar and translation API.

Assume the GF translation goes to a reviser, working with or without another copy of the MOLTO translation tool. The corrected translation, in XLIFF form, should be brought to GF's attention. This calls for a new functionality from the GF grammar API: one which corrects the grammar and lexicon software to produce the output required by the corrected translation. This functionality is to be built on the GF example-based grammar writing methodology.

In order for the corrections to converge, revised translations must accumulate so that the newest corrections do not falsify earlier ones. The collection of manual corrections may become ambiguous or inconsistent, which situation should also be recognised and brought to the attention of a grammar engineer. Again, it is important to pay attention to user roles and rights.

We may want to provide ways to override GF translations with canned translations. At the translation tools level, this can happen by preferring TM translations over GF. We should also consider ways to override compositional translations on GF grammar level.

Another requirement is translation time update of grammar, at least the lexicon, so that translator's on the fly lexicon additions are possible.

If we want to support translating formatted documents using XLIFF, the minimum requirement is that the GF translation API handles XLIFF inline tags.

1. Introduction

MOLTO promises a translation tool based on Grammatical Framework, a programming language for multilingual grammars. The Grammatical Framework (GF) is used in the MOLTO project to build translation systems for EU languages. The user of the MOLTO translation tool need not know how to write GF grammars. She is supposed to use domain specific grammars developed by others to translate documents in the domains covered by the grammars. GF resource grammars offer basic grammar coverage in dozens of languages. A domain specialist is supposed to write an abstract grammar for a domain based on an ontology of the domain that provides the key concepts and their relationships. Language specific grammar engineers are supposed to map the common abstract grammar to the different resource grammars. Basic domain language and coverage does not guarantee that all terms and idioms found in a translatable document are covered. To be really usable, the MOLTO translation tool should handle lexical gaps in a way that benefits and benefits from a wider community of translators. It should also provide fallback solutions when a text is not covered by the available grammar(s).

This document builds on the Translation Tools API document, which lays out the translation scenario/s addressed by the prototype and describes the various programming APIs available for building the prototype. This document explains the installation, use, and limitations of the MOLTO translation tool prototype. The prototype integrates some but not yet all aspects of the MOLTO translation tools design in the TT API document. As in the API document, we single out a set of core tools for a standalone translator used by one translator, from an extended set of tools that are designed to support MOLTO translation communities.

The core MOLTO Translation Tool (TT) consists of these parts.

• translation editor
• grammar manager
• document manager
• term manager

The core TT editor can be used standalone. It is being integrated, though in the prototype deliverable, only just embedded in the rest of MOLTO translation and ontology/terminology maintenance tools (the extended prototype), in particular, the GlobalSight TMS and the TermFactory term ontology management. Eventually, they both shall play together with grammar GF maintenance and development machinery. To help orientation, we recapitulate the intended workflow from the Translation Tools API document.

2. The MOLTO Translation Tools Architecture

The MOLTO Translation Tools architecture is recapitulated here briefly. It consists of many largely independent components. There is a core basically answering the needs of a single author/translator, and an Extended API addressing the needs of a community of authors, translators, and grammar engineers.

The components of the MOLTO TT editor prototype currently include the following:

1. sign in
2. grammar manager
3. document manager
4. term manager
5. translation editor

The components of the MOLTO TT extended prototype include the following:

1. user management
2. grammar management
3. document management
4. lexical resources
5. translation editing
6. translation memory
7. reviewing/feedback
8. grammar engineering

The first five are extensions of the corresponding facilities in the core. The lexical resources API borrows from TermFactory. The translation memory and the reviewing/commenting facilities are adapted from GlobalSight. The last item is based on the GF grammar development tools API.

3. The MOLTO Translation Tools Prototype

This section describes the code constituting the prototype. The code base of the translation tools extended prototype currently consists of the following parts.

• MOLTO TT editor
• GlobalSight (adapted for MOLTO)
• TermFactory (adapted for MOLTO)
• OntoText API
• MOLTO Grammar Tools API

This document describes the prototype's software packages, their installation, use and current limitations. The last two components are not discussed further in this document, because they are described in other MOLTO deliverables. The services currently provided by the GF server are outlined in the MOLTO Grammar Tools API document. The GlobalSight WS API was described in the MOLTO Translation Tools API document. TermFactory is documented at length in the TermFactory manual at http://www.helsinki.fi/~lcarlson/CF/TF/doc/TFManual_en.xhtml .

/var/www/editor$ ls 
grammars  index.html  org.grammaticalframework.ui.gwt.EditorApp  WEB-INF

/var/www/fcgi-bin$ ls -l 
content-service -> /usr/local/bin/content-service
pgf-service -> /usr/local/bin/pgf-service

/usr/local/bin$ cat fpath
localhost moltodb moltouser moltopass

/usr/local/bin$ ./content-service fpath

/var/www/editor$ ls 
grammars  index.html  org.grammaticalframework.ui.gwt.EditorApp  WEB-INF

io/lib/tf-io.jar            The core library (offline tools)
ws/service/TFServices.aar   The Axis2 webservice archive
ws/servlet/TermFactory.war  The Tomcat webapp archive

4. Integration

This section comments on the current status of the integration the different parts.

• Linking between the MOLTO TT translation editor and GlobalSight document management and translation process This linking is important for usability, but is closely connected to the further development of the TT editor and the MOLTO GF back end. Alternatives range from cut and paste (already supported) to automatic processing of XML/XLIFF document elements marked for MOLTO translation.
• Linking between the equivalents editor and TermFactory, in particular
  • TermFactory back end to answer equivalents editor queries to populate the editor from TF repositories
  • TermFactory back end to allow equivalents editor to communicate user additions to TF
  A JSON format i/o API for converting term equivalent tables to/from TermFactory to term ontology format is in place in TermFactory, so this item is almost complete.
• Communication between the equivalents editor, TermFactory and the GF grammar services, in particular,
  • conversion of lexical entries between TermFactory ontology format and GF abstract grammar format
  • updating of GF grammars with user defined entries
  A mapping between MOLTO grammars and ontology formats has been defined by UGOT on the Museum case. UHEL has started generalizing the solution.
• Linking between translation editor/s, translation leveraging tools (TM/termbank) and GF services, in particular
  • linking between the MOLTO (GlobalSight) comment/review system and TermFactory
  • linking between the MOLTO (GlobalSight) comment/review system and GF grammar editing services
  These steps are less urgent, so they will be left last.

Here is a figure showing some of the connections in the design.

5. Requirements on the GF grammar and translation APIs

This section repeats the wishlist of requirements from Translation Tools on the GF grammar and translation API.

Assume the GF translation goes to a reviser, working with or without another copy of the MOLTO translation tool. The corrected translation, in XLIFF form, should be brought to GF's attention. This calls for a new functionality from the GF grammar API: one which corrects the grammar and lexicon software to produce the output required by the corrected translation. This functionality is to be built on the GF example-based grammar writing methodology.

In order for the corrections to converge, revised translations must accumulate so that the newest corrections do not falsify earlier ones. The collection of manual corrections may become ambiguous or inconsistent, which situation should also be recognised and brought to the attention of a grammar engineer. Again, it is important to pay attention to user roles and rights.

We may want to provide ways to override GF translations with canned translations. At the translation tools level, this can happen by preferring TM translations over GF. We should also consider ways to override compositional translations on GF grammar level.

Another requirement is translation time update of grammar, at least the lexicon, so that translator's on the fly lexicon additions are possible.

If we want to support translating formatted documents using XLIFF, the minimum requirement is that the GF translation API handles XLIFF inline tags.

Appendix: Developer notes

The complete MOLTO TT prototype editor code is downloadable as an eclipse (Helios) project archive http://tfs.cc/molto/molto-tt-0.9-linux-eclipse-20120529.zip. The TT editor's database back-end Haskell source code is packaged as http://tfs.cc/molto/molto-tt-server-0.9-linux-20120529.zip.

Apache web server settings

Install apache and fastcgi with apt-get: sudo apt-get install apache2 libapache2-mod-fastcgi

Here is a sample Apache2 virtual host below to handle the MOLTO TT back end services from port 8888 (the default). The back end server is supposed to be in the same domain as the editor to avoid cross-domain scripting violations. Copy the text below to /etc/apache2/sites-available/default

<VirtualHost *:8888>
    ServerAdmin webmaster@localhost

    DocumentRoot /var/www
    AddDefaultCharset UTF-8

    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>
    <Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
    </Directory>

        # Allow fastcgi services from fcgi-bin. 

    <Directory "/var/www/fcgi-bin/">
        Options +ExecCGI 
        AddDefaultCharset UTF-8
        SetHandler fastcgi-script
    </Directory>

        # Identify pgf-service as a fastcgi server
        FastCgiServer /var/www/fcgi-bin/pgf-service 

        # Identify content-service as a fastcgi server
        FastCgiServer /var/www/fcgi-bin/content-service 

        # Make action pgf-service handle pgf files
    Action pgf-service /fcgi-bin/pgf-service
    AddHandler pgf-service .pgf
    AddCharset UTF-8 .pgf
</VirtualHost>

After you have copied the above to /etc/apache2/sites-available/default, activate the changes:

sudo a2enmod fastcgi
sudo a2enmod actions

Finally, restart apache by typing sudo service apache2 restart.

Some attested problems

1. Server doesn't start, error message is just "fail". If you copy and paste conf files, make sure they don't override any previous confs you might have.
2. "Permission denied" error messages when trying to access (chmod 775) files in /var/www.
   Solution was to change the ownership group from root to all users: sudo chown -R root:www-data /var/www/ (the name of the group might vary, you can see yours by seeing which group has /var/www; do grep "/var/www" /etc/passwd).

GF server settings

Get the latest sources for GF from darcs repository. The instructions are here: http://www.grammaticalframework.org/download/index.html

Assuming you have the source files, go to src/server and type sudo cabal install -f content --global. It is important to use the option --global, because by default they are installed in the home directory, and that doesn't go well with Apache. The binaries will be installed in /usr/local/bin. Because of Apache, you need to set their owner group to the apache group (depending on machine, e.g. www-data or apache).

The next step is to link the binaries to /var/www/fcgi-bin.

/var/www$ sudo ln -s /usr/local/bin/content-service fcgi-bin/
/var/www$ sudo ln -s /usr/local/bin/pgf-service fcgi-bin/

Some attested problems

1. gf-server-1.0 depends on fastcgi-3001.0.2.3 which failed to install.
   If you get the following error, you must first have C library fcgi. First install libfcgi-dev (sudo apt-get install libfcgi-dev), then try again to install PGF service and content service: sudo cabal install -f content --global

Developer version settings

This applies only if you want to use the editor from Eclipse. Otherwise you don't need any of this.

To test the TT editor under eclipse using GWT devMode, we found it necessary to recompile content-service to add the gwt code server port parameter to page URLs. To do so activate the following lines in ContentService.hs . We have been using eclipse 3.6 JEE with Google Web Toolkit version 2.3.1.

-- devModeScriptName = (liftM2 (++)) (getVarWithDefault "SCRIPT_NAME" "") (return "?gwt.codesvr=127.0.0.1:9997") 
-- path <- devModeScriptName

A corresponding change is neeeded in the client code. Activate the following line in TT-0.9/src/org/grammaticalframework/ui/gwt/client/SettingsPanel.java

// String defaultUrl = "/fcgi-bin/content-service?gwt.codesvr=127.0.0.1:9997";

Launch settings for building and testing under devMode under eclipse (in $HOME/workspace/.metadata/.plugins/org.eclipse.debug.core/.launches):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="com.google.gdt.eclipse.suite.webapp">
<booleanAttribute key="com.google.gdt.eclipse.core.RUN_SERVER" 
                  value="false"/>
<stringAttribute key="com.google.gdt.eclipse.core.SERVER_PORT"
                  value="80"/>
<stringAttribute key="com.google.gdt.eclipse.suiteMainTypeProcessor.
PREVIOUSLY_SET_MAIN_TYPE_NAME" value="com.google.gwt.dev.DevMode"/>
<booleanAttribute key="com.google.gdt.eclipse.
suiteWarArgumentProcessor.IS_WAR_FROM_PROJECT_PROPERTIES" value="true"/>
<listAttribute key="com.google.gwt.eclipse.core.ENTRY_POINT_MODULES">
<listEntry value="org.grammaticalframework.ui.gwt.EditorApp"/>
</listAttribute>
<stringAttribute key="com.google.gwt.eclipse.core.URL"
                 value="editor"/>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
<listEntry value="/TT-0.9-ORIGINAL"/>
</listAttribute>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
<listEntry value="4"/>
</listAttribute>
<stringAttribute key="org.eclipse.jdt.launching.CLASSPATH_PROVIDER"
                 value="com.google.gwt.eclipse.core.moduleClasspathProvider"/>
<stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE"
                 value="com.google.gwt.dev.DevMode"/>
<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS"
                 value="-startupUrl editor -war $HOME/workspace/TT-0.9/www/editor \
                 -noserver -remoteUI "${gwt_remote_ui_server_port}:${unique_id}" \
                 -logLevel INFO -codeServerPort 9997 \
                  org.grammaticalframework.ui.gwt.EditorApp"/>
<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="TT-0.9"/>
<stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Xmx512m"/>
</launchConfiguration>

Database settings

HSQL and HSQL-MySQL installation

First you need to install HSQL. It's in hackage, so it can be installed by typing sudo cabal install hsql --global.

The public version of the Haskell MySQL package hsql-mysql-1.8.1 used by the TT content service appears to have a bug that prevents multiple successive mysql procedure calls. A debugged version of the package can be found at http://tfs.cc/molto/hsql-mysql-1.8.1-molto.zip.

Install the debugged version:

• Download and extract the files in hsql-mysql-1.8.1-molto.zip
• Go to the top level directory, where you can find hsql-mysql.cabal
• Install by typing sudo cabal install --global

Some attested problems

1. HSQL 1.8.2 doesn't install. Solution: try HSQL 1.8.1. You can choose it by typing sudo cabal install hsql-1.8.1 --global or downloading the version from hackage.

MySQL server settings

In addition to the above, you need a mysql server. You can install one by typing sudo apt-get install mysql-server.

Content-service uses a mysql database to store users, grammars and documents.

To create the database connection you need to do the following steps:

1. create the database for molto content service
2. create the content service database owner user
3. give that user all rights for the database
4. create key file fpath somewhere with the unholy quartet host db user pwd in format known to haskell readFile.
5. call service with fpath as the only argument to create user, grammar and document tables:
   content-service fpath

Now create the database:

$ mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
...

mysql> CREATE DATABASE moltodb;
CREATE USER moltouser IDENTIFIED BY 'moltopass';
GRANT ALL on moltodb.* to moltouser;

Query OK, 1 row affected (0.02 sec)

mysql> Query OK, 0 rows affected (0.00 sec)

mysql> Query OK, 0 rows affected (0.00 sec)

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| moltodb            |
+--------------------+
2 rows in set (0.00 sec)

mysql> quit
Bye

Next, create the database files.

/usr/local/bin$ ./content-service fpath

And then log in to mysql with the user moltouser.

mysql -u moltouser -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.

mysql> use moltodb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+-------------------+
| Tables_in_moltodb |
+-------------------+
| Documents         |
| GrammarUsers      |
| Grammars          |
| Users             |
+-------------------+

4 rows in set (0.00 sec)

If so the tables got created ok. There is nothing yet in the tables. After you first sign in with your google account, then your user account will be in the table Users. You can query any of the tables by writing select * from <table>.

Tabular editor (stand-alone version)

To install the tabular equivalents editor source, do this:

1. checkout the whole source code directory from https://svn.it.helsinki.fi/repos/molto/trunk/molto_term_editor/ and put it in any place where the apache server can reach, i.e. /var/www/.
2. download the extjs-4.0.2a package from http://extjs.cachefly.net/ext-4.0.2a-gpl.zip, and uncompress it as extjs-4.0.3 under the directory molto_term_editor/.
3. then, you can open the link http://localhost/molto_term_editor/editor_sparql.html, if you put the source code under /var/www/.

GlobalSight

The GlobalSight installation values are kept in $HOME/workspace/GS-8.2.2.1/main6/tools/build/dist/GlobalSight/install/data/installValues.properties. The following shows settings used for a MOLTO GlobalSight eclipse installation (with $HOME replacing the installation directory and PASSWORD the password/s) :

#Mon May 28 22:52:03 EEST 2012
mailserver=mail.domain.com
system_log_directory_forwardslash=$HOME/workspace/GS-8.2.2.1/main6/tools/build/dist/GlobalSight/logs
install_data_dir_forwardslash=$HOME/workspace/GS-8.2.2.1/main6/tools/build/dist/GlobalSight/install/data
server_host=localhost
database_password=PASSWORD
database_server=localhost
database_username=globalsight
ldap_password=PASSWORD
ldap_install_dir=/var/lib/ldap
server_port=9090
ldap_host=localhost
gs_home=$HOME/workspace/GS-8.2.2.1/main6/tools/build/dist/GlobalSight
ldap_username=ldap_connection
admin_email=WelocalizeAdmin@domain.com
system4_admin_username=gsAdmin
ldap_base=globalsight.com
ldap_port=389
GS_HOME=$HOME/workspace/GS-8.2.2.1/main6/tools/build/dist/GlobalSight
cap_login_url=http\://127.0.1.1\:9090/globalsight

1. Introduction

This deliverable D3.3, is a manual and a description of workflow for the translation tools produced within WP3. As stated in the previous deliverables 3.2 and 3.1, the user of the translation tools is not required to know how to write GF grammars. They are either translators, whose job is to translate from fixed source, or authorized to modify the source text in order to fit into the structures covered by the domain-specific grammar(s). This document presents workflows for both scenarios.

1.1 Outline of the document

In section 2, we present the components: the open-source translation management system Pootle, the Simple Translation Tool and the Syntax Editor. In section 3, we present the translation workflows. (Technical details, where?) In section 4 we talk about future work (and failures? e.g. professional scenario hard to adjust to the idea of non-fixed source. TF not really in use, so lexicon adding did not work as planned.).

1.2 Changes from Deliverables 3.1 and 3.2

We have changed the plan from deliverables D3.1 (translation tools API) and D3.2 (prototype). The previous deliverables use GlobalSight, a translation management system, and an external editor that supports GF.

Due to the changes, it is not necessary to include a summary. The sections of this document are self-contained; assuming that a reader is in general familiar with MOLTO project.

2. Components

2.1 Simple translation tool

The Simple translation tool (http://cloud.grammaticalframework.org/translator) is a translator's editor that supports manual and automatic translation. Documents consist of a sequence of segments that are translated independently. The user can import text in the source language and obtain automatically translated text in the target language. Imported text can be segmented based on punctuation. Optionally, one can also use line breaks or blank lines to indicate segmentation in imported text. Text can be edited after it has been imported.

In the image below, the translator chooses the source and target languages and uploads a text in the source language.

The text can be displayed as parallel texts or segment by segment, as shown below.

The translator can choose a translation method for the whole document, or when needed, for each segment. The translation methods include various GF grammars, transfer-based machine translation by Apertium and manual translation. Other machine translation options can be added as well. The choice of grammars is shown in the picture above. Choosing a different grammar for different segments is relevant, if the body of the text is unrestricted, but there are passages where precision is required, such as formulas in a patent application. Then the unrestricted text can be translated with a method that has more coverage but less precision, and the formulaic parts with a specialised grammar.

2.2 Syntax Editor

The Syntax Editor (http://cloud.grammaticalframework.org/syntax-editor/editor.html), written by John Camilleri, is a tool for building and manipulating abstract syntax trees in GF.

The image below shows an initial view of the Syntax Editor. The chosen grammar is Phrasebook and the level of the construction is Action; a verb phrase whose tense and polarity are not fixed yet. This excludes some of the possibilities to construct a sentence in Phrasebook, for instance greetings and other fixed phrases.

A syntax tree can also be imported as raw text, as shown in the image below.

The editor maintains the structure of the abstract syntax tree (AST) and outputs linearizations in the languages of the concrete syntaxes. In the following three images, the first shows a change of an argument in the AST and the consequent change in the linearizations. Son is changed to a daughter, in English only the word changes, but in French and Bulgarian, changing the gender of the argument also affects the agreement of the possessive pronoun.

The second image shows the change of the head of the phrase. Both AKnowPerson and ALove take two arguments of type Person, so from the point of view of the AST, they are interchangeable.

The third image manipulates the polarity of the sentence. As opposed to the previous two examples, this AST is complete, belonging to the start category of the grammar, that is, Phrase.

Finally, a tree created or modified in the editor can be exported as raw text.

Future work includes integration to the Simple Translation Tool. Further details about the plans in 4.X.

2.3 Pootle as an example of GF integration

Pootle (http://tfs.cc/pootle LINK TODO) is an open-source translation and project management platform that is completely implemented as a Web service. The platform accepts most of the formats used in translation industry like XLIFF, TMX and PO.

Integration of GF into Pootle

Pootle has a support for both standard translation memories and machine translation. Google Translate and Apertium MT systems are available in the standard installation, and Web server queries to other MT systems can be sent by modifying the source code of Pootle. GF translation via GF Web API has been added to the Pootle translation environment as a proof of concept.

Unlike Google Translate and Apertium which only require the translatable segment and the source and target language codes as input, the GF system also needs the name of the resource grammar(s) to be used. The selection of the grammar has been added to the Pootle project administration dialog, where the project manager normally selects the languages, file formats, translation memories and other resources to be used:

The translator user interface shows the buttons for different MT systems above the edit box (GF, Google and Apertium buttons are seen on the screenshot below).

When the GF button is clicked, the web browser sends the source segment to the GF server, which parses and linearizes it into the target language using the given grammar(s). The translated text is then sent back to the browser. The translation suggestion can then be edited, after which the segment is added to the project translation memory.

This illustrates that the GF translation system can be relatively easily added into various translation editing applications via the Web API. The GF Web API can be modified to comply with any standard Web API like the one proposed by TAUS (https://tauslabs.com/interoperability/taus-translation-api)

3. Workflows

This part consists of two separate workflow descriptions. The first workflow is that of a traditional professional translation, using the translation platform Pootle, with GF integrated in machine translation and translation memory. The second workflow describes a case where the translator is authorised to do changes to source. The tools of choice are the Simple Translation Tool and the Syntax Editor.

3.1. Translation of a fixed source

The workflow of a professional translation is often fairly complex, including roles such as project manager, translator and reviewers of both content and language. Machine translation is used as the translator's aid, along with other tools such as dictionaries and translation memories. This is an established practice in computer-assisted translation; one of the main objectives of WP3 is to demonstrate that MOLTO tools can be adapted in a traditional translation workflow.

The translator is not allowed to modify the source text, which is a serious limitation for the MOLTO translation, precision at the cost of coverage. However, in this scenario we assume that the translator necessarily knows both source and target languages. The role of the machine translation is not to provide publication quality text for blind translation, but to help the translator to produce translations.

When does it make sense to use MOLTO tools? With free text of unrestricted domains, the most common case is that GF grammars do not produce any translation at all, due to missing words or constructions. When we have a professional translator post-editing GF grammars beat general-purpose MT in situations where the structure is crucial. Any formulaic parts within unrestricted text, such as mathematical constructions (case study X) and chemical formulas (case study Y). A construction such as (2S)-2-[(4S)-4-(2,2-difluorovinyl)-2-oxopyrrolidinyl]butanamide is constructed by elaborate rules, which can be expressed precisely with a GF grammar. However, statistical machine translation fails to capture the structure, and the result is worthless for post-editing; a change, addition or omission of even one element is enough to change the formula completely.

Thus, we have integrated GF as one of the translation options in Pootle. The technical side is handled by GF Web API calls, explained in more detail in section 2.3.

3.1.1 The Pootle workflow

The Pootle translation enviroment implements the now industry-standard workflow where the translatable material, the translation memories and the editing tools reside on the same Web server. The system also includes rel-time word-count reporting, user management and terminology asset handling. This greatly reduces the effort needed for a translation project, as all the tools and resources are centralized. As the translations are updated into a shared translation memory in real time, the need to create, update and document the memories after the project is unnecessary. Pootle also allows the local downloading of necessary resources in cases where the translator does not have an always-on internet connection.

3.1.2 Translation project manager

The translation project manager can upload the files to be translated to the Pootle server and define the language pairs, translation memories, glossaries (either general or project specific) and file formats to be used in the translation. The systems allows the use of standard translation file formats like XLIFF (for source material), TMX (translation memories) and TBX (terminology). In our GF machine translation enabled version of Pootle, the PM can also select the GF grammar or grammars used for translation (see Section 2.3 for an example).

When the translation assets have been configured, the PM can give the necessary access rights to them for the translator s and reviewers. The material can also be translated as crowd-sourcing, so anyone with an access to the Pootle server can participate in the translation. This method has been used in many open-source localization projects, for example in the OpenOffice suite.

3.1.3 Translators

The translators can then log in with their credentials onto the Pootle server, and see all the translation tasks assigned to them by the PM:

After clicking a project name, the Languages page shows the target languages the translator has been assigned to:

Clicking the language name opens the editing environment:

Any exact or fuzzy match ("Translation suggestion" in Pootle terminology) found in the translation memory can be selected and edited for a translation. As explained in the previous section, the translator can use machine translation services (including GF) by clicking the relevant button. The translator is thus able to use either the sugggestions from the translation memory, a choice of machine translations or a translate the segment from scratch.

The Pootle editing tool includes automatic checking for quality issues, for example missing tags, variables or numbers, wrong capitalisation, punctuation and so on, so the translator gets instant feedback on possible formatting errors in the translation. The translator is also able to include comments to reviewers and PMs as separate field in the tool and add or review terms in the terminology.

3.1.4 Review and post-processing

During the translation, the PM can follow the progress of the project on the Projects page. When the translation of a component is ready, the PM gets a notification, and the translation can be sent to reviewers, who then check and correct the translations by accepting or rejecting the suggestions. After the review process, the PM is again nofified, and the translated and reviewed file can be downloaded for post-processing.

3.2. Translation of an editable source

We hold on to the assumptions stated in D3.1:

• Translator is the author or is authorized to adapt the text to better satisfy the constraints of the translation grammar,
• Translator is native or fluent in the source language, and familiar with the domain or at least its special language in order to know how the message can be paraphrased,
• Translator is not required to know (all of) the target languages.

In a case of at least partially blind translation, the quality of MT needs to be excellent. External revisers can be added to this scenario as well, but we assume the quality to be in general good, errors are due to bugs in grammars and grammar writers are correcting them. A concrete scenario could be a multilingual website, where the authorized users can create content in any of the languages, and it is updated simultaneously into all of them. Assuming there are users for every language, they can work themselves as reviewers, providing feedback in case there is an error in the grammar. Then a grammar writer fixes the grammar, and the all structures that had the same problem will be updated.

There might be a source document or it can be created from scratch. In any case, there is a need for guided authoring, to ensure that the produced text is recognized by the grammar. This is not currently implemented, but planned by UGOT and explained further in section 4.2.

The Simple Translation Tool (STT) offers the functionalities for pre- and post-editing of MT. When needed, machine translation can be completely overridden by manual translation. The functionalities of STT are demonstrated with a toy text about pizzas. More complex grammars produced within MOLTO include the patent grammars in WP7 and the mathematical grammar library in WP6, but they are not integrated to STT at the moment. We plan to produce a video demo with some real use cases.

In the first image, the text is uploaded into STT and a default translation method is chosen.

In the second image, we see three errors. The first one, indicated with number 1, is an error in the grammar; an unidiomatic word choice. This type of error is easiest to fix just by modifying the target -- followed by a bug report to a grammar writer. Of course, spotting this type of error requires that the translator knows the target language. In cases where not, they just need to assume that input is correct.

The second error manifests as no translation. The solution here is to paraphrase the source; in this case, changing the modifier "really" to "very", that is supported by the lexicon. This example is very simplified; in any realistic situation, the possible changes are numerous. Either we need to assume that the translator/author has a good documentation on the allowed constructions in the restricted language, or the program needs to guide the translator. The latter is a planned feature, the first depends on the individual use case.

The third error also shows no translation, but it is due to the segment being totally different domain. In the example document of 5 phrases, the first is a commentary, written on completely unrestricted text, and the four remaining phrases are the sort of restricted language that translates with our chosen GF grammar. In a realistic situation, the first phrase could be generic instructions and the latter ones could be mathematical formulas, in order for the scenario to make sense. In any case, the error is corrected by changing the translation method for that segment. Instead of any GF grammar, we choose Apertium, with more coverage but quality not quaranteed. In case the translator spots errors in generic MT option, there is the source post-editing option.

Finally, all three errors have been corrected. The user can view the texts parallel and save the project.

4. Future work

4.1 Translation memory generation

UHEL will conduct experiments on creating translation memory data with GF grammars. Grammars of a given domain are used to generate bilingual aligned data, which can be converted into a translation memory. Then, when translating new material, the translation memory can provide fuzzy matches for cases where the constructions are similar, but words are different. This is one way to compensate for the lack of lexicon in a situation where adding new vocabulary is hard.

Jonson (2006) describes an experiment on synthesizing a corpus with GF for training speech recognition models. The idea is similar: use a grammar to generate reliable data for a data-driven approach.

By using GF translation suggestions in a translation memory it is also possible to use standard translation tools like Trados to generate pre-translation reports of exact and fuzzy matches. These percentages of different matches are easier to demonstrate to translation industry stakeholders, as the scientific metrics used in MT evaluation (BLEU, NIST, Rouge and so on) are not generally used or well understood within the industry.

4.2 GF cloud

Services in the GF cloud will be linked to each other by UGOT. Syntax editor (http://cloud.grammaticalframework.org/syntax-editor/editor.html) will be used within the Simple Translation Tool (http://cloud.grammaticalframework.org/translator/). As described in the DoW, there will be a mode for editing source text, where structural changes to the document can be made by manipulating abstract syntax trees. This functionality will be added to the Simple Translation Tool.

Simple Translation Tool will be extended to a bilingual, controlled language document authoring tool, with useful ways to enter and edit the source text too. Additions include a text input guided by word completion and syntax tree editing, by invoking the syntax editor (see section 2.2) on a source segment.

plan to submit a system demo paper to the MT Summit, http://www.mtsummit2013.info/ deadline 22 April. About a unique MT platform,

• scalable from controlled language to open domain systems
• incremental parsing and syntax editing
• visualizations
• web interface
• free

4.3 Grammar editing

Grammar editing in the translator's tools is still an open question. One of the main shortcomings of a MOLTO type translation is the limited coverage, and that's why it is important that a translator can easily extend and modify the lexicon. Just importing raw lexicon data, with or without TermFactory, is described in Listenmaa (2012). This is a question of adding more content, but another question is modifying existing grammars, usually in a case of an error.

There are some steps taken to further this issue. D11.2 presents a multilingual semantic wiki, where it is possible for every user to modify the grammar behind the wiki. This is still an expert work, as the editing is done with raw GF code, but there are methods for guided grammar editing, such as the cloud-based IDE (see documentation). This environment offers an easy way of multilingual grammar writing and editing.

1. Introduction

The purpose of this document is to describe the knowledge representation infrastructure in MOLTO. It clarifies the expectations concerning the back-end infrastructure, serving the various MOLTO knowledge engineering tasks. It is based on the summary and analysis of the requirements gathered from the case studies, from grammar development, and from the partners. The scope of the deliverable covers presentation of the requirements, specification and description of the MOLTO Knowledge Representation Infrastructure (KRI).

Blending these expectations with previous experience in knowledge engineering, and adding a pinch of common sense, we come up with the specification of the MOLTO Knowledge Representation Infrastructure. This KRI is the data modeling and manipulation backbone of the entire project, aiming to serve semi-automatic creation of abstract grammars from ontologies; deriving ontologies from grammars, and instance level knowledge from NL. In terms of retrieval, NL queries will be transformed to semantic queries and the resulting knowledge, expressed back in NL.

The KRI is based on pre-existing products, and ensures a mature basis for storage and retrieval of both knowledge and content, covering all modalities of the data. This document provide descriptions of the technology building blocks, overall architecture, standards used, query languages and inference rules.

2. Requirements

The KRI should allow for:

• Building the conceptual models and knowledge bases needed for grammar development and the use cases of MOLTO - one base set and three specialized knowledge sets for the use cases.
• Extending of the PROTON ontology with a large coverage knowledge base focused on named entities and a thesaurus. The specialized sets will include the necessary domain specific models and instances, e.g. multi-lingual patent classification taxonomies, museum ontology and instance base, etc.
• Using a semantic alignment methodology paired with a set of data source transformation tools for each of the structured data sources.

3. KRI Specification

The objective of this section is to introduce the KRI specification - the technology building blocks, overall architecture, standards used, query languages and inference rules. It describes how to modify the KRI, how to change the default underlying ontology and database, and how to adjust the inference rule-set of the OWLIM semantic repository.

A demo of the KRI is running on http://molto.ontotext.com.

The KRI is responsible for the storage and retrieval of content metadata, background knowledge, upper-level ontology, and other possible data, if available (users and communities), and exposes convenient methods for interoperability between the stored knowledge and the toolkit for rendering natural language to machine readable semantic models (ontologies) and vice versa.

The KRI includes:

• OWLIM — a semantic repository that stores all structured data such as ontologies, background knowledge, etc., and provides SPARQL query mechanism and reasoning.
  For more details about the OWLIM architecture and function, please see the OWLIM section.
• RDFDB — an API that provides a remote access to the stored structured data via JMS.
  For more details about the RDFDB architecture and function, please see the RDFDB section.
• PROTON Ontology — a light-weight upper-level ontology, which defines about 300 classes and 100 properties, covering most of the upper-level concepts, necessary for semantic annotation, indexing and retrieval.
• KRI Web UI — a UI that accesses OWLIM through the RDFDB layer. The web UI gives the user the possibility to browse the ontologies and the database, to execute SPARQL queries, etc.
  For more details about the KRI Web UI, please see the KRI Web UI section.