FLAVIUS

Technical presentation (Overblog, Qype, TVTrip)

-

WP2 Platform architecture

FLAVIUS

Technical presentation (Overblog, Qype, TVTrip)

Technical presentationFLAVIUS

Presentation of 20 minutes for each partners (CMS, web technology, …)

Overblog

Qype

TVTrip

FLAVIUS

WP2 Platform architecture

FLAVIUS

Introduction of WP2 – Platform architecture

FLAVIUS workflow

Analyze user’s need

Specify the FLAVIUS platform architecture

Implement the FLAVIUS platform

Deliverables

WP2 : Platform architectureFLAVIUS

Main objectives of WP2: analyze, define and implement the FLAVIUS architecture (and workflow)

Glossary and acronyms:

TM : Translation Memory Compose of text segments in a source language and their translations into one or

more target languages Reduce cost of translation project

SMT : Statistical Machine Translation Translations are generated on the basis of statistical models whose parameters

are derived from the analysis of bilingual text corpora.

Post-edition Feature allowing a webmaster to modify translated text

WP2 : Platform architectureFLAVIUS

FLAVIUS WorkflowFLAVIUS

Different translation workflow will be available according to option selected by webmaster

Automatic/semi-automatic correction of source text

Create a personal translation dictionary

Post-edit the translation

Train SMT engine with personal translation memory

Etc …

Feedback from users :

A widget will allow user to post their feedback about the translation

Webmaster will be able to see and use this feedback

Translation with minimumintervention

FLAVIUS

(1)

•Webmaster sends his sources files, and define parameters (language, ….)

(2)

•Text revision (automatic correction of source text)

(3)•Transla

tion

(4)

•Webmaster downloads the translated text

Automatic correction

No terminology extraction

No use of translationmemory

SMT not customized

No post-edit

Translation with source textrevision

FLAVIUS

(1)

•Webmaster sends his sources files, and define parameters (language, ….)

(2)

•Text revision (automatic correction of source text, …)

(3)

•Webmaster corrects the text (helped with advices given by FLAVIUS) and sends his modifications

(4) •Translation

(5)

•Webmaster downloads translated source text

Automatic and semi-automatic correction

No terminology extraction

No use of translationmemory

SMT not customized

No post-edit

Translation with source textrevision, translation customization, ….

FLAVIUS

(1)

•Webmaster sends his sources files, and defines parameters (language, ….)

(2)

•Text revision (automatic correction of source text)

(3)

•Terminology extraction and translation using TM and SMT

(4)

•Webmaster correct the text and sends his modifications. His personal dictionary is enriched.

(5)

•Translation (using his personal dictionary enriched with terminology)

(6)

•Post-edition of translation. His TM is enriched.

(7)

•Webmaster downloads translated source text

Automatic/Semi-automatic correction

Terminology extraction

Translation of terminologyusing TM or SMT.

Enrich personal dictionary with terminology

SMT customized with his personal dictionary

Post-edition

Customized translation withpersonal translation memories

FLAVIUS

SMT customized with a personal TM :

Webmaster can submit his own TM

SMT is trained with his TM

Workflow can be one of the three previous workflow :

Automatic/Semi-automatic correction

Terminology extraction

Translation of terminology using TM or SMT.

SMT customized with his personal dictionary

Post-edition

Analyze user’s needFLAVIUS

Content that FLAVIUS should be able to translate :

Web technologies : asp, asp.net, php, html, xml, …

CMS : joomla, wiki-like…

Establish a grid criteria to evaluate and select web technologies and CMS that should be supported

audience (number of websites, visitors, …) workload (easy to implement)

Analyze the feasibility of generalizing CMS translation by considering SQL Database translation.

Establish a list of main CMS Make a technical analysis (SQL database, web technology) Generalize to other CMS if possible

Analyze user’s needFLAVIUS

Spelling and grammar checker output usefull for a webmaster (semi-automatic correction)

Ease the process of translating a web site

Simple and efficient workflow

High availability of FLAVIUS platform High availability of partner applications Warn FLAVIUS platform in case of service degradation (raised errors, …)

Specify the FLAVIUS platformarchitecture

FLAVIUS

Compatibility with partner applications :

Internet browser supported (IE 6.0, 7.0, FF 3.0, 3.1, Safari, Chrome, ...)

Client-side technology used (Flash, Java, SVG, Ajax, …)

Handling CMS translation :

Translation of CMS « user-generated content » (direct translation, SQL dump, …) request user to define fields to translate ?

Translation of CMS « label » (multilingual CMS issue, …) do not translate already CMS translated label ?

Importing translation memory :

Format supported (TMX , Excel, ….)

Version of TMX (1.4, 1.3, ..)

Implement the FLAVIUS platformFLAVIUS

Interoperability

Feedback from partners about the interoperability of their technology (known limitation)

Way of communication supported/available (webservice, REST)

Performance :

Feedback from partners about performance issues of their applications.

Hosting :

Partner’s application can be hosted elsewhere ?

Hardware

Limitation

DeliverablesFLAVIUS

Technical analysis report

This document must contain :

Technologies that will be supported

Explanation of workflow

(1)

•Each partner will establish a technical team to discuss about technology, workflow issue.

(2)

•PM (Project Manager) will formalise and supervise the study (define a first list of criteria and technology, CMS to support, draft worflow )

(2)

•Each partner will send an informal reply to this document (suggestion of technologies to support, workflow improvement, …)

(3)

•PM will compulse this reply into a draft document and send it to each partners

(4)

•Draft document will be discussed during regular meeting

(5)

• PM will write a final document, and send it to each partner for validation.

DeliverablesFLAVIUS

Website specification

This document must contain :

Detailed platform architecture

Integration specifications for each module

Planning :

(1) -> (4) : define the architecture

(5) -> (7) : define integration of partner application relative into the chosen architecture

(8) : write final document

(1)

•PM will send a draft document to partners with a proposal of architecture

(2)

•Each partner will send an informal reply to this document (suggestion, improvement, incompatibility, …)

(3)

•PM will compulse this reply into a draft document and send it to each partners

(4)

•Draft document will be discussed during regular meeting

(5)

•Each partner will send integration specifications (for their application in the chosen architecture) to PM

(6)

•PM will write a draft document (architecture + integration) and send it to each partners

(7)

• Draft document will be discussed during regular meeting

(8)

• PM will write a final document, and send it to each partner for validation.

DeliverablesFLAVIUS

Implementation plan

This document must contain :

Delivery dates

Integration and testing phases

(1)

•PM will send a draft document with a proposal implementation plan to each partner

(2)

•Each partner will send an informal reply to this document (suggestion, technologies, improvement)

(3)

•PM will compulse this reply into a draft document and send it to each partners

(4)

•Draft document will be discussed during regular meeting

(5)

• PM will write a final document, and send it to each partner for validation.