Wiki

Clone wiki

Okapi / ProjectManager

General

Project

  • one source language

  • many target languages

  • input documents

    • filter configuration (could be none)
    • fall-back encoding
    • what target language is needed for this file
  • segmentation (first time you generate the tkit?)

  • for each target of each input document

    • output name (directory structure, and file name, and may be customized through scripts.
  • translation may be done partially only then put back in the project

  • update of the input document can be done

  • store different versions of the translations

  • file base serialization archived/zip (do we need a db?)

Application level

The application can handle multiple projects.

A project's basic information are a number, a name, and a client.

A project can have one source language and an unlimited number of target languages.

A project has a set of input documents that can be: files, URL, database, etc.

Each input document can be associated with one or more target language, it may not be associated with all target languages.

Each input document is associated with:

  • a default encoding
  • a filter setting (possibly blank)
  • a optional output name/URL/folder/etc. for each target language it is associated with. Such target names can be set using macros.

It should be possible to start the workflow for a given file, reach a certain point, and have a new version of the file fed into the system. The application should have a mechanism to compare the different versions and generate tkit of delta as needed.

The first (optional) step of adding a file to the project should be a way to look at the extracted text without committing it to the workflow yet, and be able to tune-up the filter's options to re-import the file without immediately triggering the updates/workflow/etc.

Each content of input file should be viewable through a simple interface (table-like). The target content, and any localizable attributes should be editable from that simple interface.

Each source entry should have a translate flag and a status properties. Suggested status: * pending (entry not yet entried in the WF) * new (new source text) * guessed match * same ID, changed text * same text * same Id and text * deleted

Each target entry should have a status property. Suggested status: * N/T (non-translatable items) * Unused (old entries) * To translate * To edit * To review * Ready

Input files can be group in sets, each set can be associated with various properties like what TM to use (for each language), what TKit to generate, etc.

If possible: The system should be able to connect to various content management systems through ClayTablet interface.

Updated