1. FLAVIUS Technical presentation (Overblog, Qype, TVTrip) - WP2 Platform architecture

2. FLAVIUS Technical presentation (Overblog, Qype, TVTrip)

3. Technical presentation FLAVIUS Presentation of 20 minutes for each partners (CMS, web technology, …)  Overblog  Qype  TVTrip

4. FLAVIUS WP2 Platform architecture

5. FLAVIUS  Introduction of WP2 – Platform architecture  FLAVIUS workflow  Analyze user’s need  Specify the FLAVIUS platform architecture  Implement the FLAVIUS platform  Deliverables

6. WP2 : Platform architecture FLAVIUS  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

7. WP2 : Platform architecture FLAVIUS

8. FLAVIUS Workflow FLAVIUS  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

9. Translation with minimum intervention FLAVIUS (1) Webmaster sends his sources files, and define parameters (language, ….) (2) Text revision (automatic correction of source text) (3) Translation (4) Webmaster downloads the translated text  Automatic correction  No terminology extraction  No use of translation memory  SMT not customized  No post-edit

10. Translation with source text revision 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 translation memory  SMT not customized  No post-edit

11. Translation with source text revision, 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 terminology using TM or SMT.  Enrich personal dictionary with terminology  SMT customized with his personal dictionary  Post-edition

12. Customized translation with personal 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

13. Analyze user’s need FLAVIUS  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

14. Analyze user’s need FLAVIUS  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, …)

15. Specify the FLAVIUS platform architecture 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,..)

16. Implement the FLAVIUS platform FLAVIUS  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

17. Deliverables FLAVIUS  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.

18. Deliverables FLAVIUS  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.

19. Deliverables FLAVIUS  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.