A fair compensation in CAT-based projects - Calling technical/scientific translators Thread poster: Tomás Cano Binder, BA, CT
|
|---|
[I hope the title caught your attention! Cheeky on my part, my apologies!]
Dear colleagues and nevertheless friends,
For quite some time in my many years translating all sorts of manuals containing many a page of specifications, spare parts lists, etc. I often stumble upon a project that contains a huge number of segments for a relatively low number of words. Today, to name one project, I have 4000 new words strewn over 3500 segments (total wordcount is just over 10K wo... See more [I hope the title caught your attention! Cheeky on my part, my apologies!]
Dear colleagues and nevertheless friends,
For quite some time in my many years translating all sorts of manuals containing many a page of specifications, spare parts lists, etc. I often stumble upon a project that contains a huge number of segments for a relatively low number of words. Today, to name one project, I have 4000 new words strewn over 3500 segments (total wordcount is just over 10K words).
Out of the approximately 9 hours this job is taking me today, I spend about 50% of the time processing segments and only 50% of the time translating the 2, 3 or 4 words in each new/edited segment. The processing burden is thus quite high. Add to it that in the rush of things I accepted this job at a PEMT rate when the MT engine used is pretty much useless in this language pair/text type with many short technical items, and this job is barely profitable.
Now, and here comes the question at last: Should we begin to consider to add a surcharge per segment in technical translations with a high number of segments but low wordcount (catalogues, databases, parts lists, specs...)?
Thank you for your feedback!
Tomás Cano Binder ▲ Collapse
| | | | Jan Truper 
Germany
Local time: 12:11
Member (2016)
English to German
Tomás Cano Binder, BA, CT wrote:
Should we begin to consider to add a surcharge per segment in technical translations with a high number of segments but low wordcount (catalogues, databases, parts lists, specs...)?
I am only rarely confronted with such texts, but right now I am fighting with a list of about 3000 single terms (technical, car-related) of a vehicle simulation game.
Unfortunately, I did not gauge the source text thoroughly before accepting the job, so I'll bite the bullet -- but if I had seen this passage beforehand, I would have either stipulated a rate surcharge or declined the job altogether.
| | | | Adieu
Ukrainian to English
+ ...
| Yes, segments are obnoxious | Jul 17, 2021 |
Yesterday, I accidentally accepted a "1.5 hr" revision job with a seemingly-reasonable word count... that had been split into 399 segments because it contained an attached 300-segment government form. with literally NOTHING of consequence written in it, on account of being redacted for participant privacy.
Just 300 segments of abbreviations and unfilled blanks.
So yup, I definitely "donated" some free labor.
I think there should be some sort of MINIMUM SEGM... See more Yesterday, I accidentally accepted a "1.5 hr" revision job with a seemingly-reasonable word count... that had been split into 399 segments because it contained an attached 300-segment government form. with literally NOTHING of consequence written in it, on account of being redacted for participant privacy.
Just 300 segments of abbreviations and unfilled blanks.
So yup, I definitely "donated" some free labor.
I think there should be some sort of MINIMUM SEGMENT SURCHARGE. Nothing extreme, maybe +$0.10 per segment.
Also: +$10 / file. Whether it is the hassle of MemoQ QA or old school manually attaching or uploading stuff, the manipulations involved in keeping track of and delivering high file count projects should come with surcharges.
[Edited at 2021-07-17 05:55 GMT]
[Edited at 2021-07-17 05:57 GMT] ▲ Collapse
| | | |
Jan Truper wrote:
Unfortunately, I did not gauge the source text thoroughly before accepting the job, so I'll bite the bullet -- but if I had seen this passage beforehand, I would have either stipulated a rate surcharge or declined the job altogether.
This is exactly what happened to me with the job I described above. In the rush of things I accepted this from a regular client without actually looking inside the manuals... and they ended being replacement part lists. Awful!
| | |
|
|
|
Samuel Murray
Netherlands
Local time: 12:11
Member (2006)
English to Afrikaans
+ ...
| You poor thing (or: welcome to the club) | Jul 17, 2021 |
Tomás Cano Binder, BA, CT wrote:
Out of the approximately 9 hours this job is taking me today, I spend about 50% of the time processing segments and only 50% of the time translating the 2, 3 or 4 words in each new/edited segment. The processing burden is thus quite high.
Yes, even without machine translation or even without a CAT tool, translating short segments take longer to translate per word than longer sentences (up to a certain long length, of course). This applies to non-meaningful segments like words lists and lists of specifications in particular, but it also applies to short segments that are actual short sentences or content that are broadly related to the surrounding content. Even if you are are allowed to translate it with the first meaning that comes to mind (i.e. the client doesn't mind if a segment has multiple possible meanings and you end up choosing a less likely one), it takes longer per word to translate very-short segments than medium-length segments.
The best thing to do is to never accept a job that you haven't seen, but that is something that most of us can't do. We trust our clients not to do things that are bad for us, but sometimes our clients are also just pressured by their clients (who care less about them than they care about us), and then we end up with situations like yours.
So, with the theoretical stuff out of the way, let's get to discussing charging strategies to avoid such problems.
You can have a system that charges a minimum fee for all segments. For example, you could say that all segments under 10 words long are charged as 10 words. Then a 4-word segment is charged as 10 words, a 12-word segment is charged as 12 words, and a 20-word segment is charged as 20 words.
Or, you can have an extra charge per segment for all segments (and argue that you have to perform certain tasks like press certain shortcut keys, read the text, check fuzzy matches or glossary/QA flags, and think for a second or two, before you start typing, regardless of the segment length). Then a 4-word segment is charged as 4+5=9 words, a 12-word segment is charged as 12+5=17 words, and a 20-word segment is charged as 20+5=25 words. And optionally, to protect the client against unnecessary surcharges on "normal" text, you can then apply a 15% discount on the final amount.
However, as you can imagine, for jobs with lots of short segments, this scheme is going to make your quote double, triple quadruple, etc. Do you have clients who would be happy with such an outcome?
Add to it that in the rush of things I accepted this job at a PEMT rate when the MT engine used is pretty much useless in this language pair/text type with many short technical items...
Yup, the machine translator reduces the average time that you spend on a segment, but again, the rates that we accept for PEMT is based on averages, and the average sentence is a medium-long sentence and the average sentence is not non-meaningful.
This is unfortunate but it is part of the fact that PEMT should really be charged per hour or per editing distance, but our clients want to know the final amount beforehand, and you can only do that with an average-based per-word rate.
Should we begin to consider to add a surcharge per segment in technical translations with a high number of segments but low wordcount
So... you propose a system whereby a surcharge kicks in only once the number of words divided by the number of segments reach a certain threshold? The advantage of such a system would be that you can easily apply it to jobs that have been analysed using existing word counting tools only. But if you do that, then you're again relying on averages and hoping that averages will average out in your favour.
A system that charges a minimum rate per segment would require an entirely new analysis engine, and you'd have to decide how to deal with minimum fees on fuzzy matching segments (do you base the minimum fee on the weighted word count or the actual word count, and do you apply a slightly reduced minimum fee or the full minimum fee).
By the way, this isn't the first time I wrote a post about this.
[Edited at 2021-07-17 08:33 GMT]
| | | | | That would be simplest way to go | Jul 17, 2021 |
Samuel Murray wrote:
The best thing to do is to never accept a job that you haven't seen, but that is something that most of us can't do. We trust our clients not to do things that are bad for us...
Exactly. I do not blame my client in this case. It was probably my fault for assuming that this set of manuals had actual text, which was not the case.
Samuel Murray wrote:
So... you propose a system whereby a surcharge kicks in only once the number of words divided by the number of segments reach a certain threshold?
I think that would make sense indeed! The average word per segment in normal text is probably around 10 words per segment. If we go extremely low, like 3 words per segment, we should either add a surcharge of a couple of cents per word or add hourly work to that based upon what it would have taken us to translate the text.
Yesterday's job took me 9 hours whereas translating it with normal text and with MT would have taken me perhaps 5 hours. Maybe charging the extra 4 hours on an hourly rate, even if not ideal, would have compensated the effort.
| | | | Adieu
Ukrainian to English
+ ...
| Is there a known mechanism to achieve this? | Jul 17, 2021 |
Sounds challenging. How would you calculate this?
Samuel Murray wrote: Tomás Cano Binder, BA, CT wrote:
Out of the approximately 9 hours this job is taking me today, I spend about 50% of the time processing segments and only 50% of the time translating the 2, 3 or 4 words in each new/edited segment. The processing burden is thus quite high. Yes, even without machine translation or even without a CAT tool, translating short segments take longer to translate per word than longer sentences (up to a certain long length, of course). This applies to non-meaningful segments like words lists and lists of specifications in particular, but it also applies to short segments that are actual short sentences or content that are broadly related to the surrounding content. Even if you are are allowed to translate it with the first meaning that comes to mind (i.e. the client doesn't mind if a segment has multiple possible meanings and you end up choosing a less likely one), it takes longer per word to translate very-short segments than medium-length segments. The best thing to do is to never accept a job that you haven't seen, but that is something that most of us can't do. We trust our clients not to do things that are bad for us, but sometimes our clients are also just pressured by their clients (who care less about them than they care about us), and then we end up with situations like yours. So, with the theoretical stuff out of the way, let's get to discussing charging strategies to avoid such problems. You can have a system that charges a minimum fee for all segments. For example, you could say that all segments under 10 words long are charged as 10 words. Then a 4-word segment is charged as 10 words, a 12-word segment is charged as 12 words, and a 20-word segment is charged as 20 words. Or, you can have an extra charge per segment for all segments (and argue that you have to perform certain tasks like press certain shortcut keys, read the text, check fuzzy matches or glossary/QA flags, and think for a second or two, before you start typing, regardless of the segment length). Then a 4-word segment is charged as 4+5=9 words, a 12-word segment is charged as 12+5=17 words, and a 20-word segment is charged as 20+5=25 words. And optionally, to protect the client against unnecessary surcharges on "normal" text, you can then apply a 15% discount on the final amount. However, as you can imagine, for jobs with lots of short segments, this scheme is going to make your quote double, triple quadruple, etc. Do you have clients who would be happy with such an outcome? Add to it that in the rush of things I accepted this job at a PEMT rate when the MT engine used is pretty much useless in this language pair/text type with many short technical items... Yup, the machine translator reduces the average time that you spend on a segment, but again, the rates that we accept for PEMT is based on averages, and the average sentence is a medium-long sentence and the average sentence is not non-meaningful. This is unfortunate but it is part of the fact that PEMT should really be charged per hour or per editing distance, but our clients want to know the final amount beforehand, and you can only do that with an average-based per-word rate. Should we begin to consider to add a surcharge per segment in technical translations with a high number of segments but low wordcount So... you propose a system whereby a surcharge kicks in only once the number of words divided by the number of segments reach a certain threshold? The advantage of such a system would be that you can easily apply it to jobs that have been analysed using existing word counting tools only. But if you do that, then you're again relying on averages and hoping that averages will average out in your favour. A system that charges a minimum rate per segment would require an entirely new analysis engine, and you'd have to decide how to deal with minimum fees on fuzzy matching segments (do you base the minimum fee on the weighted word count or the actual word count, and do you apply a slightly reduced minimum fee or the full minimum fee). By the way, this isn't the first time I wrote a post about this. [Edited at 2021-07-17 08:33 GMT]
| | | | kd42
Estonia
Local time: 13:11
English to Russian
| Not enough starting data + partial solution | Jul 17, 2021 |
Tomas, it is not clear what data you are dealing with (tables like packing lists or specs), and in what form you have received it (original document or Trados package). Please give an example of the data.
A good way to deal with a highly repetitive data is to run analysis and export all matches below 100%. Then you translate the exported data against the same TM. This will allow you to translate "Spring washer anodized" only once, and not 700 times, and will save you from waiting while Stu... See more Tomas, it is not clear what data you are dealing with (tables like packing lists or specs), and in what form you have received it (original document or Trados package). Please give an example of the data.
A good way to deal with a highly repetitive data is to run analysis and export all matches below 100%. Then you translate the exported data against the same TM. This will allow you to translate "Spring washer anodized" only once, and not 700 times, and will save you from waiting while Studio applies the translation of "Spring washer anodized" 699 times.
When your trasnslation is complete, you auto-translate the full version of the document against the same TM.
The bad thing about this workflow is that some repetitions are translated differently in a different context, but this is extremely rare.
HTH ▲ Collapse
| | |
|
|
|
Samuel Murray
Netherlands
Local time: 12:11
Member (2006)
English to Afrikaans
+ ...
Adieu wrote:
Sounds challenging. How would you calculate this?
If you mean charging a minimum fee per segment (i.e. charging for 10 words if the segment is smaller than 10 words), it should be fairly simple for a CAT tool developer to include such a feature.
You see, during a normal word count/analysis, a weighted word count is calculated for each segment. The individual segments are not shown in the analysis report because what matters in an analysis report is the total weighted word count per file or per project. But since the actual and weighted word counts of all segments are known, the analysis system only needs to look for segments whose actual word count is 10 words or less, and then change those segments' weighted word counts to "10 words". I'm sure most/all current CAT tools that do analyses would be able to do that with very little extra programming.
Doing this "manually" with only the functions that CAT tools currently provide, would be more difficult, simply because CAT tools typically don't allow you to extract a list of all segments along with their weighted word counts. Even getting a list of segments along with their fuzzy match percentages (from which a weighted word count could be calculated to a certain extent) isn't trivial in most CAT tools. But if you can create a list of segments with the relevant information (actual word count and weighted word count), you can sort the list by length, so as to find segments that are 10 words or less, and then change their weighted word counts all to "10". You'd have to figure out how to deal with repetitions, though.
[Edited at 2021-07-18 08:20 GMT]
| | | | Adieu
Ukrainian to English
+ ...
| Key word: developer | Jul 21, 2021 |
CAT tool developers are more oriented towards features helping agency clients pay less, not assisting us in charging more.
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » A fair compensation in CAT-based projects - Calling technical/scientific translators | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
| | Wordfast Pro | Translation Memory Software for Any Platform
Exclusive discount for ProZ.com users!
Save over 13% when purchasing Wordfast Pro through ProZ.com. Wordfast is the world's #1 provider of platform-independent Translation Memory software. Consistently ranked the most user-friendly and highest value
Buy now! » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news
