...
- Translation will be implemented as a module that extends the functionality of what can be done with a reference set given the previous sections. This means that defining the pool of content to be translated is done by developing or importing a reference set. Each “version” of a translation will be correlated to a “version” of the reference set.
- After defining or loading and then creating a “translation reference set”, the tool will provide the ability to initiate a translation project. Existing content can be loaded into that translation project from RF2 files (e.g. descriptions and language reference sets). While the import handler is extensible, the default implementation will only support RF2. We are of the opinion that conversion of other formats to RF2 is relatively trivial and keeps operation of the system less complicated.
- Tracking of translation project metadata, including the reference set used to define it, the spelling correction dictionary it will use, and information like allowable description types (and their definitions), and information about releases. User and role pairings are associated with the project used to create the reference set that backs the translation project – thus no special need exists for user/role management at this level.
- Export of completed translations to RF2 (descriptions and language reference set files). The tool will use an extensible handler mechanism with a default RF2 implementation that could be customized by members if another format was needed.
- Simple workflow mechanism that supports these features:
- Assignment of batches to authors. All content to translate will exist as a single collection of concepts that can be sorted, searched, and filtered to produce the set of concepts desired to be assigned to a particular author.
- Ability to develop translations for one or more descriptions of a concept. When a concept is presented to an author for translation, all descriptions of the concept to translate will be shown with an option for that author to translate one or more. Validation checks can be used to enforce policy (e.g. the “FN” must be translated). Authors can save work if not yet ready to move on.
- Ability to submit translations for review when editing is complete.
- Ability for a reviewer to assign a batch of concepts from a review pool (exactly analogous to the earlier assignment to authors).
- Ability to review an author’s work, make changes, and submit the “final” translation (again with the opportunity to use validation checks to provide additional information or control). Reviewers can save work if not yet ready to send on.
- Ability to mark a translation as “preview ready” which makes it available to other users of the overall reference set tool for viewing and feedback. This action is reserved for reviewers/admins.
- Ability to mark a translation as “published“ and generate corresponding RF2 artifacts.
- Workflow will be is implemented in an extensible way with a “default” workflow implementation as described above. Dual independent review and other more complicated workflows will not be supported out of the box but could be developed in the future.
- Enhanced workflow to achieve the stated SNOMED CT Translation Workflow (http://www.ihtsdo.org/resource/resource/110)
- Persistence of translation content will also be managed by a handler that will have a default implementation that communicates with the IHTSDO terminology server (to the extent that its capabilities support the needs). If it turns out to be more desirable at this time to use local storage, a local storage option will be employed as well. When storing translated content, a binding of descriptions to the source descriptions will be maintained (where individual descriptions are specifically translated) – otherwise a simple concept connection will be maintained.
- Support for lookups of audit trail and history of translations. This will support the ability to see which authors edited which translations and which reviewers reviewed them. It will also provide a means to see the state of a translation at any point in the past (for example the prior publication state or a prior review state).
- Support the ability to compute the concept and description changes when transitioning from one version of SNOMED CT® to another. This will be done by using effective times to determine the complete set of descriptions and concepts changed in the updated delta. This will support a feature that allows reviewers and admins to see the scope of content that may need to be revisited for translation based on what changed. The concepts involved at this stage can then be put into the workflow (either for re-authoring or simple review).
- Spell checking capabilities based on Lucene and a custom word dictionary provided for the translation project. Spell checking can be handled by validation checks which then provide the author or reviewer an opportunity to add new words to the spelling correction dictionary and re-submit the content.
- Translation suggest feature based to use a dynamic translation memory based on phrase-level translations already approved by reviewers on an individual project. This feature will be implemented with an extensible handler whose default behavior will be to store a 1-n map of possible translations for a particular phrase and it will be specific to individual projects. Thus different “teams” can use different memories.
- The handler can also be extended to implement things like the google translate API if needed.
- The handler can also be extended to support reuse of phrase-level translations from other projects if desired. Given localization considerations and the desire to be consistent with across the terminology, it is likely that project level choices will remain specific to that project. However, where no “standard” phrase level translation exists yet, it may be useful for projects to borrow candidate translations from other projects.
- The feature will support partial translation suggestions where the candidate phrase to translate is longer than phrases currently in the memory. For example, there may be a translation in the memory for “renal failure”. When the phrase “acute renal failure” is encountered, the extent of what can be looked up in the memory will be returned as an option.
- The translation suggest feature will function like an “autocomplete”, or a drop-down picklist available to the author at the point of data entry.
- The feature will support authors adding phrase level translations directly to the memory and it will learn from actual use as well.
- It would be possible with this framework to enable a validation check (if desired) to warn authors during the translation process if they were using a non-standard phrase level translation. For example, if translating “acute renal failure” where the memory contains a phrase level translation for “renal failure” and the author chooses a translation that does not contain the words of the phrase level translation – a warning could be produced (giving the author a chance to normalize the translation before proceeding).
- Support for the ability to annotate a concept translation in a variety of ways, including simple note, document attachment, or URI link.
- Contextualized help icons associated with each “widget” or “feature” of the client application. For the scope of this project, these icons will lead to pages that contain placeholder content in anticipation of a future effort to develop comprehensive documentation.
- Notification mechanism that allows emails to be sent in response to various workflow events. This will be implemented as a default workflow listener that informs an author or reviewer (if user preferences are configured as such) via email when a new batch of work has been assigned.
- Simple reporting of productivity by time period for authors or reviewers on translation projects. This report, available to reviewers and admins, will simply report the number of concepts/descriptions handled by each author for a specified period of time (daily, weekly, monthly, custom). Other, more sophisticated reporting can be considered in the future, or be derived through API calls.
- As with reference set tooling, this tool will integrate with IHTSDO component identifier service to manage identifier assignment.
...