WG1 Initial Ideas

General

Since Workgroup 1 is supposed to deal with business requirements, we should focus on 4 elements:

1. Processes
2. Applications to be connected
3. User requirements
4. The “wrapper”, in other words the meta data about the process, not the data to be translated or moved around. GALA published this diagram:

The logos shown here are household names or placeholders of applications to be connected. If you categorize them, you end up with a list like this:

• Translation Memories
• Translation Management Systems
• Machine translation Systems
• Content Management Systems
• Document Management Systems
• ERP
• Layout applications

Arguably, this list is not complete and the systems mentioned above show some overlap. Thus, you should look at typical workflows to determine which systems are supposed to talk to each other at which points of the workflow. In this way, you can determine:

• The type of systems potentially involved
• The type of information exchanged between a specific subset of these systems (not all of the systems are interested in the same set of data).

API discussions are usually very technical and developer-driven. This workgroup should turn the scenario upside down and start with user requirements and then ask software publishers for their needs regarding the fulfillment of the user requirements.

In a nutshell, this workgroup shall define the type of data to be exchanged whilst the other groups define the respective data formats.

Workflows and Examples

In order to start the process, let us look at a simplified translation workflow:

If reality would be that simple, we would not meet in this workgroup. A typical translation process is nothing but linear and localization adds a few dimensions. But even in this simplification, we can already add a number of applications required:

Not shown in this diagram, but important for LSPs is the calculation of project cost, which includes external cost (invoices of subsuppliers) and internal cost (overhead and time spent by employees on the project). Hence, we need to add three types of applications:

• Accounting systems
• A/V applications
• Time trackers

But even that workflow is quite far from reality. It is unusual and happens only for small projects that there are just two parties involved: customer and supplier. Usually, the supplier called LSP below subcontracts many tasks or jobs in the course of a project. Typical tasks subcontracted include:

• Extract content from source
• Clean up source files
• Translate (several subcontractors for several languages)
• Revise (language)
• Revise (subject matter, e.g. doctor in case of medical translations)
• DTP or cleanup of target content
• Subtitling
• Voice overs
• Accounting (tax accounting)

Thus, there will be many hand-offs with corresponding orders and invoices on the way. Let us take a look at a rather simple example: Translation of a document. Since we intend to automate the process as much as possible, we assume that the various applications talk to each other and can do without the human interventions. It will be the task of this workgroup to determine the data that need to be transferred along the arrows of this diagram:

Let us take a look at the arrow marked with an asterisk: there will be several jobs for translators and revisers etc. Thus, the following data need to be transferred:

• Name/ID of the project
• Name(s) of the file(s)
• Name/ID of the resource
• Source language
• Target language
• Reference documents
• Instructions
• Start date
• End date

There might be more data required depending on the way the individual resource (translator, reviser, etc.) will get information about the job. Another example: if the customer uses a content management system or a web portal, then the TMS and or TM should talk directly to these systems. A portal should then transfer all the data about the project:

• Content to be translated
• Source language
• Target language(s)
• Tasks requested
• Order number
• Number of framework contract
• Contact person
• Ordering person
• Invoicing information
• End date
• …

At the end of the localization process, a CMS needs to get sufficient information enabling it to put the translated content into the right “slots”.

These simple examples are merely meant to give an idea of the applications and steps involved. In other localization jobs, the set of applications might be much larger, including e.g. apps for the following tasks:

• Terminology extraction
• Terminology validation
• Language quality assurance
• Technical quality check on the files
• Transcription
• Script validation
• Additional linguistic tasks
• New application to vendor management
• Rate update
• NDA signing
• Contract signing
• External / related request, such as banner (graphics) or screenshot linguistic validation
• …

Tasks for Workgroup 1

I. Establish a list of tasks to be covered II. Establish a list of hand-over points III. Determine the data set required at each hand-over point IV. Combine all of these data sets V. Create a unique naming convention (or use an existing one and extend it) VI. Ensure that existing conventions are adhered to, e.g. language codes and locales, currencies, etc. (by reference to existing standards) Members of WG1 need to collect real-world workflows and processes and determine the data needed to automate each step in these workflows and processes. This should be done from two angles:

• View of users (customers and LSPs)
• Software publishers

First of all, the users should start with their own particular processes and define the steps they would like to automate. Then they should determine the data, which need to be exchanged at each step to be automated. In this way, we get a practical collection of apps and handover points involved, which we can then extend to a more complete picture. Software publishers then need to check whether these lists are complete. If not, they should add additional data needed to enable a complete handover. Moreover, WG1 needs to define the scope of applications to be included in TAPICC. And WG1 needs to check whether an existing standard can be used as a starting point and be extended to cover the requirements.