Table of Contents
One of the most important aspects of technical translation is standardising the technical terms used. This Technical Translation Database is at the heart of the technical translation process.
The Technical Translation Database is a crucial tool in the technical translation process, aimed at standardizing technical terms used in projects. It consists of three objectives: standardizing terms, creating an extensive reference base, and generating statistics of terms. The database aims to retain and standardize vocabulary on a project, provide search vocabulary for other projects, and provide synonyms and a deeper understanding of terms. It also stores agency contacts, email addresses, and logins to agency portals.
The database is designed to store translation terms in source and target languages (French to English) and can be adapted for any language pair. It allows easy searching for any term from any project and generates statistics about projects and domains. Essential fields include the number of words, agency and end customer, and estimate in accounts. The database allows users to search for terms within a project and compare terms from previous projects. It also includes two important fields: the chosen term in the target language and the alternatives.
The above is essentially the process of collecting terms for reference.
There are 3 objectives of collecting translation terms.
- Standardize terms during a project
- Constitute an extensive reference base
- Generate statistics of terms
Purpose of the technical translation database
- Retain and standardise vocabulary on a project (like a termbase)
- Provide search vocabulary for other projects
- Provide synonyms and a deeper understanding of terms
- Vocabulary, project tracking, wph, stats, link with accounts
- Calculate translation volumes per month, customer and type of work
- Store agency contacts, email addresses, and logins to agency portals
Design of the technical translation database
At the outset, I stored my translation terms in Evernote and on Google Sheets. But after a while, searching for terms previously encountered was quite time-consuming.
I designed the translation database to store translation terms in source and target languages (French to English). It could be adapted for any language pair.
Terms are attached to a project, but as they are in one table, I can easily search for any term from any project.
I realized that the database could also be used to generate statistics about projects and the domains in which I work. This is part of an ongoing attempt to define my profile as a technical translator.
Structure of the technical translation database
The essential tables are described below in a summary class diagram.
A term can be attached to only one project. A possible adaptation would be to allow terms to be attached to more than one project. Terms may have significantly different meanings depending on the context.
The Essential Fields
Once a project is started, complete the number of words, the agency and end customer, and the number estimate in accounts.
The customer table includes the contact details, their payment conditions (30, 45 or 60 days), price in currency for translation, MTPE, Revision or Audiovisual.
So we have a project that links back to the agency and all terms within a project.
Terminology in the technical translation database
Each project in the translation database has its own specific terms which I record against the project ID, so I can come back and look at the vocabulary for specific projects.
Search for terms in the technical translation database
I can search through all the vocabulary to find the term I’m looking for. I can attach an existing term to the current project, enter new terms, and thus constitute the terms for a project. This is also an opportunity to improve terms I’ve come across already.
I import term bases into the translation database and technical dictionaries (such as the engineering one), which are available when I’m doing a project.
The advantage of a bespoke database is that it creates functions tailor-made to your process. The essential requirement for me was to store terms and then be able to search for them in one location.
Search for terms
So while terms are standardised within a project, they are also available for search across all projects. So, I often search for a term to see if I have come across it in previous projects and how I handled it. The following fields are searchable.
Alternative terms in the translation database
There are two important fields: the chosen term in my target language (English) and the alternatives. This helps me reflect on the most appropriate term during translation.
At the end of a project, I may send a list of terms to the customer with the target files to show them the alternatives considered or for customers to choose the appropriate industry-specific term.
I store the abbreviations in French and English. It is often important to spell out an abbreviation to confirm its meaning and to determine, with customers, whether an abbreviation should be translated or left as is.
Deduplication of translation database terms
Terms may come up in more than one context or project. Sometimes the same word may mean different things in different contexts or be combined with a strict duplicate.
Before building the database, I stored terms in Google Sheets, one for each project. So I had some work to do to combine these sheets together into the database and to help, built a deduplication function to combine terms.
This function is still useful to combine terms encountered on current projects. I take care, though, only to combine terms if they have the same meaning and are essentially synonyms, in which case the English term of one goes into the ‘alternative field’ of the other.
Standardizing translation terms
This is the recording and standardisation of terms in ‘everyday’ translation. Writing down terms and weighing the synonyms leads to a better understanding.
What term to use?
Is there an industry-standard term?
‘Animation à interval courte’ is not’ short term management’ but ‘short interval management’, a standard term in visual management screens for Lean Management.
Reversible ratchet handle, rack wrench, stud wrench, open-end spanner, strap wrench, offset wrench, screw key are all variations of different types of spanner (clé in French)
A text may use similar terms, or one might translate terms using similar words only to realise that two similar terms are indeed the same (particularly for large projects).
The project vocabulary list serves as a reference for the terms used and to standardise them during proofreading.
Customers may come back to you once you have ‘learnt’ their technical or industry vocabulary. So this may be useful as an opportunity.
The database allows you to pull up the vocabulary for the customer to work on repeat projects.
At the same time, all terms are available for search, no matter what project.
I have done a lot of work in computing (112k) but only have 1000 terms.
I collected many industrial terms because it was not my original speciality and a field that I wanted to focus on.
Scientific: these words came from a large project for electrostatic discharge (ESD) specifications and guidelines for an electronic component manufacturer.
Legal and Business may overlap with ‘management’ with many (24) smaller projects of around 1500 words.
In Electrical Engineering and Nuclear, I integrated a large terms’ database (42k) but have never specifically categorized a project in that domain.
I leave Electrical and Mechanical Engineering separate, because together they would create a distinctively large category and distort statistics.
Translation project management
I favour using Trados for translation projects. I import customer source documents, translate with or without machine translation, proofread and export the target document.
The customer supplies a PO number, which, once the finished project has been accepted by the customer, will be used to invoice.
It’s no longer sufficient to have a good or bad feeling about past performance. It requires measurement. I have measured translation output, performance, and productivity. Words done by day, week and year and been able to improve because of measurement.
The database manages projects. I time all work spent on projects, and I use the accumulated statistics in a Weekly Review.
Measuring the key data
I therefore need to capture time spent on projects in the translation database. I work on projects in batches of roughly half an hour, which I record using the timer screen.
Timing project work
This is where I record the customer order, along with the price, the customer PO number, and my initial estimate for the job.
The timer screen is the heart of the database. Its where I record time spent on projects. As you can see below, I record project time in batches. (I usually work according to the Pomodoro method, so often the batches last 30 minutes.) For each batch, I record the number of words done, draft or checked and can then calculate the average word rate.
The timer screen becomes the central screen to track my progress against the initial estimate to know whether I’m on track for delivery.
It has been important to track words per hour, and pleasing to note that wph is increasing. This might be due to increased efficiency. Also, the volume of machine translation is increasing, so the number of words processed is on the rise. When will it reach a plateau?
Start working on a project. Time the work done with the timer screen
- Enter 2 batches: 1 x 0.5 hours to 750 words and 1 x 0.5 to 1500 words
- Enter 1 batch: 1 x 0.5 hrs for 1500 words of proofreading (to OK)
1500 words in 1.5 hours is a word rate of 1000 words per hour and hourly rate of 50 GBP
- The timer screen is where I show the time spent on projects
- Applies the Pomodoro method.
I can see my progress on the timer screen, including how many days a job has taken me, my average hourly rate, and my word rate.
The objective is to maximise production time at a favourable rate. But rates vary, and minds wander. It is better to do the translation work and remember terms than remember how long a project takes. Indeed, the more projects we do, the harder it is to average. But a database can do this well.
The objective is to work, but to review the work in a weekly GTD review. But to get the data to do this review, you have to measure production.
Statistics from the technical translation database
Analysis of project domains
Where there are more words than terms, it means I just ‘get on with the project’ and don’t need so much support.
Where there are more terms than words, it is generally because I went out to look for support and found a detailed online source.
See here for credits to some of my sources, including Tech Dico, Le Grand Dictionnaire du Quebec, Linguee, and specific data sources.
I calculate the number of terms in the database against the number of words translated in that domain. I have set myself some objectives as part of managing my business, notably the number of words per month, average word rate, and financial objectives based on the volume done.
The translation database presents a graph of the number of words handled per month
Average word rate
Average translation rate: I measure the time taken for each project in Trello Plus and with the total number of words for each project, I calculate the number of words translated per hour. Access then calculates the average.
I want to know how many words I’m averaging per hour overall. But wph is also broken down into wph by project type and by task type. This means I know the wph for subtitling projects but also for subtitling tasks. The difference may be that a project includes a proofreading step to bring down subtitling project wph, but the subtitling task is only the subtitling step.
A high hourly word rate means that I’m working as fast as possible (maintaining quality). A rising word rate may be a sign of finding better ways of doing things (continuous improvement).
The translation database helps me manage my translation projects, create statistics on my productivity, and drive invoicing.
I record the time spent working on translation projects, the volume handled, and time spent on management activities. The following video demonstrates some of the measures that I calculate to monitor translation project activity, notably word rate, hourly rate, and words per hour performance.
- Explains the key measures that the translation database helps to manage.
- Demonstrates a test project and records time spent.
- Provides a short explanation of hourly rate.
Estimation of project delivery dates
I estimate a project for 1500 words at a word rate of 0.05, total price is 75 GBP. It will take me 1.5 hours, thus an hourly rate of 50 GBP. This is achieved two half hour batches of 750 words one translating to draft and a half hour proofing 1500 words.
In this example, I use a new project,
- Number of words: 1500
- Price: 75 EUR
- Time estimate: 1.5 hrs
- Estimated hourly rate: 50 EUR
Measures from the technical translation database
I produce some or all of these combinations of indicators and review them regularly in my GTD review to ensure that I’m on track. Whether for individuals, projects, or overall productivity,.
There are six main indicators, but the core measures are average price per word and hourly rate.
Average order price might highlight different periods; say in week 19-09 I was working on relatively large projects (low number, high price), whereas in week 20-11, there was a high number of orders but at relatively low price.
Margin data comes from Quickbooks and highlights profit in the last 30 days but with an opportunity to comment. The natural reflex might also be to establish actions if the financials are under objectives.
|Hourly rate (GBP)
|Hourly word rate (WPH)
|Avg order price (GBP)
|PW by period
|PT by period
|HR by project
|Avg order (AO)
|PW by customer
|AO by customer
|HR by project
|PW by category
|WPH by task type
Production overview (GTD)
The GTD review is an overview of performance, and I measure it with some key data:
I use the translation database to do GTD reviews every week. But because the data for each week is discrete, I can review and modify my objectives at any time. I don’t have to wait until the end of the week to see how things are going.
The main thing that I look at is the hourly rate, the word rate, to reassure myself that the hourly rate is high enough.
And also that the word rate is high enough to know that I’m doing things fast enough.
- Statistics, particularly the hourly rate and word rate per hour
- Overall statistics for a period: the year, broken down by category, domain,
- A customer breakdown enables me to see which customers are sending me the work I’m most efficient at
- Weekly performance: how many hours I’ve done in a week and how many words
Monthly production (hours)
Overall, I can see how many words I’m doing per month and whether I’m putting in the hours.
Monthly production (words)
Project words is the number of words in the order. But if a project is 5,000 words, I might do 10,000 in all – 5,000 to draft and 5,000 to proofread. All this time and volume must be (and is) counted in the hourly rate.
Hourly rate (GBP)
The hourly financial rate helps me tell whether the hours I’m putting in are profitable.
Issues may arise during projects. A project may be established to solve more than one issue. A single issue might require one or more actions.
Once over a certain size, reflect on whether the cost-benefit of the issue requires a dedicated project to achieve its objective.
Business issues may be more or less severe and may or may not stop production. Some issues may be development challenges.
This is the detail of the issue form, showing how I structure an issue.
Another possible field is probable cause, which may follow observation before ascertaining a solution. The actual cause may only be ascertained once a solution is found and put into action.
I recently added objectives to determine the objective of solving the issue.
If I can’t initially identify the action, I create an issue, which encourages me to analyse the observation, cause, and solution. This analysis helps drive action.
Observation: breakdown an issue first into what is observed and, separately, possible causes. This way, possible solutions can address the cause.
Cost of doing: this could be the time, resources, and financial costs of resolving the issue. If the problem is insufficient turnover, then the solution could be the whole cost of business development over three years. If the issue is a sticking door, the solution is much simpler.
Cost of not doing: is the potential detrimental cost of not solving the issue.
Solution: a summary of the action required to solve the issue, whatever the criteria, to remove or reduce the negative effects of the issue.
Conclusion: how the issue was solved or why it was closed without solving; perhaps the cost outweighed the benefit?
Objective: the reason why this issue needs to be solved and, whatever the actions, what we’re aiming for.
Is it possible to start with a business objective and create an issue? Or should I create a separate list of business objectives?
It seems silly to ‘invent’ an issue just because you wish to establish a strategic choice or direction. Perhaps you might reflect on why you wish to do so. If your thinking is to develop the European market, is it because you have insufficient revenue (an issue) or simply because you believe that you can achieve additional profit (development)? So a business objective might be related to a management project.
Inspired by #Clayton Christensen’s book, How Will You Measure Your Life? Somehow this generated in me the desire to measure what I’m doing. Early on, I thought this would provide some empirical mathematical answer to what I should do. But I realized that the answer to that question would come from me. Measurement initially is to control production and to whatever extent possible, understand it. Understand the effect of your actions and plan new ones incorporating learning.
The Eisenhower matrix groups action into the following four categories:
Favour those that are important and urgent.
Those that are neither important nor urgent are by definition out of the current frame.
It is up to you to determine what is important and urgent. Some things may appear to be both important and urgent but not when in context against other planned actions.
Lower priority items need to wait until they move up the scale to receive focus.
Review priorities regularly to ensure that your appreciation of their relative weight is still appropriate. You may have classed something not urgent or important but it bugs you. Perhaps this is a feeling which motivates you take another look. Make that task current.
In Eisenhower speak, perhaps it should become important for a while while you analyse it. You are free then either to pursue it or reclassify.
Those in between, that are urgent but not important, also might need to move up the scale before getting attention, but if priority one tasks are on hold, for whatever reason, you can choose an action from another quadrant (urgent not important).
Indeed, using Pomodoro is an ideal opportunity to squeeze in short, less important tasks into the [five or fifteen minutes] break.
The four quadrants have a nominal priority 1,2,3,4 on the Eisenhower grid. I decided to place the urgent and important list at the top left, where the eye reads first.
Roughly, its green for urgent and important tasks (actions), red for less important non-urgent tasks, orange for important not urgent that might just be on hold, and mauve for less important but urgent tasks. Production orders are always a top priority.
Task analysis: the training course is not so urgent, and I only need to invoice customers at the end of the month. Invoicing, of course, remains important. I could downgrade it until just before the due date. Just about everything else is less important and less urgent right now.
But there may be development projects, so once the production order is over, switch back to development (creating production capacity). The choice then is up to you to determine which of the priority four items to upgrade.
A double click on the Eisenhower grid opens the action card. An action can be linked to issues, projects, orders or customers