Terminology creation and management

The process of terminology creation, approval and change is clear and customizable. Requests for term creation/change can be easily submitted online.

  • Term creation/change proposal, approval, and posting are all separated
  • All term-related history is stored in the database, including the time and reason for the creation/change of a term, who created the entry, etc.
  • All terminologists adhere to a centralized process that covers all details and instructions

Target terminology creation/change process is completely autonomous. It does not require customer involvement.

  • Language-specific feedback is immediately taken into account
  • Clarifications, requests, and fixes are all parts of our internal process
  • No problems related to improperly added terms or missing instructions
  • No excess time or money spent on queries or source term improvements

A high-level process chart is presented below:

 

Logrus IT_term_database

 

In cases where client subsidiaries or other vendors are involved in the terminology process, the workflow is adjusted accordingly.

  • A proposal is initiated by any registered term contributor
    • A proposal can include a new term or change in translation
    • Can either be rejected immediately by the Logrus terminology manager or expert  – OR –
    • Term is created or changed and sent for client [vendor/subsidiary] approval
  • Client [vendor/subsidiary] comments are checked
    • Term is finalized
    • In some cases multiple iterations are required

A particular workflow can be easily customized to optimally fit a client’s terminology creation and approval process.

 

Logrus IT_terminology_workflow

What We Need from Clients

To do source terminology work, we need:

  • Name and version of the product
  • Support contact within the product team
  • Reliable terminology data and ownership by author
  • References and/or terminology for related products and areas
  • A terminology database decision (client’s database or Logrus IT database) or an agreed template
  • Files for term harvesting (if required)

To do target terminology work, we need

  • The list of target languages (almost all languages supported)
  • Deadlines
  • Support contact on the client end
  • Contacts for target languages if terms are vetted by client and/or third party representatives
  • Metadata to find source terminology in the product

Special aspects should be discussed and defined upfront.

 

How It Works in Real Life

It is important to discuss process details in advance. Be prepared to cover the following:

  • Who can initiate creation of new source terms?
    • In some cases all source terms are developed/maintained by the client
    • In other cases this work is partially or fully outsourced
  • Who can initiate term requests (client, Logrus IT, other vendors)?
  • Who can approve these proposals (client’s localization team, Logrus IT, subsidiaries)?
  • Who can post terms or changes (client, Logrus IT)?
  • Does client separate in-house terminologists and subsidiary reviewers?
  • What are required/agreed term attributes?
  • Are there any other specific requirements for the process?
  • What access rights should be provided to all external terminology database users?

Typically, proposals can be initiated by all parties:

  • Client (when new software or concepts/terms emerge)
  • Vendor (when a new concept/term surfaces during translation)
  • Terminology Vendor (upon client’s request or when inconsistencies or change requests are received)