Translator Web Application

The eRegulations Translator Web Application is accessible at the same location as the Admin Web Application and behaves like a special sub-module that is activated only if the authenticated user has the "Admin-Regulation-Translator" role. The interface is completely different from the Admin Web Application and it is built to serve to a authorized translator to update the datra of the eRegulation content in a secondary language. Here below the categories of eReegulation content that can be translated through this interface:

• objectives
• blocks
• steps
• recourses
• generic requirements
• laws
• entities in charge
• units in charge
• persons in charge
• menus

The translator interface access a replica version of the content that is recorded in special tables after an explicit action from the admin interface. The explicit action is "Send to translator".

The idea behind this specialized interface is to create a decoupled working space to external users of the system. Their work will not directly affect the eRegulation content. The translator can work in a parallel space and only when their work is fully completed they can commit the translation at which time the data is copied back into the " _i18n" tables in the admin space. The administrator can then validate (publish) the translation or can directly make some final corrections. When the administrator is sending an element to translator the system makes a full copy of that object and also its current translation data, it serializes it into XML format ans saves that data in specialized tables : "XMLSerializedItem" and "XMLSerializedItem_i18n".

It is worth mentioning an important rule that was introduces as a need of assuring a better organization of work: translator can work on one element only at one particular moment in time. The system implements this rule by demanding the explicit actions from the translator for :

• start working on element
• stop working on element

In order to take into account the time implications of the translation activity the system records the version of the data in the original language and also a version of the translation:

• the version of the original data is incremented each time the administrator "re-demands" a translation after a previous translation has been commited or it has the status "working in progress".
• the version translation is incremented with each commit

The translation can be in one status at one time:

• inexistent
• work in progress
• already commited ( a first commit exists)
• not commited (never commited)

1. Application architecture

The architecture of the Translator Web Application follows a 3-tiers design : Data, Business, Presentation. You can have a look at the diagram here 2.1. Application architecture.

The architecture follows the same Model View Presenter pattern and define the views as interfaces gaining in flexibility of implementing the view interfaces as ASPX pages or as customized views for Ajax requests. The update of translation follows the same sequence described in the previous chapters. (see 2.4. code execution flow)

The challenge of this application was to isolate the working of the translator from the main repository. Keep the admin data to fuel the public and the snapshot tables and also have a version of the data that the translator can focus on. Also all the eRegulations applications must share the domain model.

We illustrate in the static diagram below translation contracts used for this module :

For assuring the independent working space we used the idea of storing a serialized version of the model and reconstruct it for the translator application only.

The translator admin application is working with only 4 tables:

• XMLSerializedItem
• XMLSerializedItem_i18n
• Workspace
• ProcedureContext

We used the same principle of interface segregation for assuring a shared contract for all the models that will force the consistency of implementation across all the models that must be translated. One key concept was the need of keeping track of the property accessors that are capable of having translated data.

2. Presenter logic - code flow

We will explain the logic inside the presenter for loading the page inside the translator space :

1. The presenter method "InitView" is called with the parameter Id (parameter that refers to the id of the object inside the translator space)
2. A new instance of the XMLSerialializedItemBO (BusinessObjectAPI) is called
3. the businessObject API loads the XMLSerializedItem from the dabase using the correspondent IRepository instance (in our case LinqXMLSerializedItemRepository)
4. verifies the status of the current user Workspace (if the item is activ, the ask teh view to set that flag, or show a message). If another object is activ in the current user Workspace retrieve the name of that element and trigger an "ItemLocked" event passing the activ element in evenArguments
5. verify if a newer version of the same element exists and trigger an OnNewVersionReleased event if found
6. deserialize the XMLData and XMLTranslationData into Model object
7. if the original data has a new version (step 5 resulted in true) the display for the current modification the number of words added / deleted in rapport to the current version. ask the view tp display the data of latest version

3. Data structure

The translator data structure is here.