Auto-propagation problem with dashes/hyphens in Trados 2009 Thread poster: Nick Quaintmere
|
|---|
This is something that has caused me to tear my hair out in frustration a number of times. Trados 2009 automatically corrects corresponding segments when you make an amendment to a segment. So far so good. However, it does not seem to recognize the difference between an en-dash and a hyphen. Consequently, I'm having problems when translating a text with a list of numbers in this format 1–5 (i.e. 1 to 5), 5–10, 10–15, etc.
This wouldn't be a problem if the numbers in the source... See more This is something that has caused me to tear my hair out in frustration a number of times. Trados 2009 automatically corrects corresponding segments when you make an amendment to a segment. So far so good. However, it does not seem to recognize the difference between an en-dash and a hyphen. Consequently, I'm having problems when translating a text with a list of numbers in this format 1–5 (i.e. 1 to 5), 5–10, 10–15, etc.
This wouldn't be a problem if the numbers in the source text were correctly formatted, but often this isn't the case (and the source text isn't editable to correct it).
Basically what happens is this. My source text has a list that is formatted thus:
1 - 5
5 - 10
and so on.
And I want to translate it thus:
1–5 (NOT 1-5)
5–10 (NOT 5-10)
etc.
Trados accepts the first entry (with an en-dash) and autopropagates the rest with hyphens! If I then move into the next segment and change the autopropagated hyphen to an en-dash it even goes back to the previous confirmed segment and changes that en-dash to a hyphen too!
Has anyone had this problem and does anyone know of a solution?
[Edited at 2010-07-15 14:08 GMT] ▲ Collapse
| | | | Jerzy Czopik 
Germany
Local time: 20:11
Member (2003)
Polish to German
+ ...
| Change the behavior of AutoPropagation | Jul 15, 2010 |
Let you be asked to confirm if the Autopropagation is allowed and let the Autopropagate segments be confirmed then.
Go to Tools - Options - Editor - AutoPropagate.
First change the setting for "Ask the user" (or however this is called in English - I'm working with the German interface now) from "Never" to "Always".
Then activate "Confirm autopropagated segment".
Now each time a segment shall be autopropagated you will be asked.
If the segment is of that kind ... See more Let you be asked to confirm if the Autopropagation is allowed and let the Autopropagate segments be confirmed then.
Go to Tools - Options - Editor - AutoPropagate.
First change the setting for "Ask the user" (or however this is called in English - I'm working with the German interface now) from "Never" to "Always".
Then activate "Confirm autopropagated segment".
Now each time a segment shall be autopropagated you will be asked.
If the segment is of that kind you described, do not allow autopropagation, but use the regex \d+\-\d+ to show segments with numbers like 5-5 and then: select all segments, use copy source to target, use Search&replace to replace all dahses by hyphens, select all segments again, right click on the segment number column and change segment status to "Translated" "Confirmed" or "Signed off".
But even if you do not do that - the program will not autopropagate in already confirmed segments, unless you have the corresponding option checked (which is IMHO a very DANGEROUS setting). ▲ Collapse
| | | | Nick Quaintmere
Germany
Local time: 20:11
German to English
+ ...
TOPIC STARTER | Autopropagation change | Jul 15, 2010 |
Thanks again Jerzy, let's see if that at stops Trados from doing it wrong.
But yet again there seems to be no way to force the system to do it right! Grrr!
| | | | Jerzy Czopik
Germany
Local time: 20:11
Member (2003)
Polish to German
+ ...
| Wrong and right | Jul 15, 2010 |
While I agree with you, that having a system doing evertyhing we would want it to do in a perfect way would be a great improvement, I must admit, that I really understand the problem here: we could ask the system to do everything right, if the source would always be perfect, in any term. But the source is mosty wrong, sometimes even very wrong. How shall the system know that?
Try the suggested settings and workaround, I hope this will help you.
Since having the view filter in Studio ... See more While I agree with you, that having a system doing evertyhing we would want it to do in a perfect way would be a great improvement, I must admit, that I really understand the problem here: we could ask the system to do everything right, if the source would always be perfect, in any term. But the source is mosty wrong, sometimes even very wrong. How shall the system know that?
Try the suggested settings and workaround, I hope this will help you.
Since having the view filter in Studio I have not a perfectly working system, but a nearly perfect way to work around ▲ Collapse
| | |
|
|
|
Nick Quaintmere
Germany
Local time: 20:11
German to English
+ ...
TOPIC STARTER | The problem is the software not the source ... | Jul 19, 2010 |
Having a system that did everything we want it to do in a perfect way WOULD be a great improvement! But I'm not expecting perfection here. I just want the system to stop doing something that it is not supposed to do nor is it designed to do.
When I enter a translation with a dash in it and press confirm, there is no logical reason why the software should then go back and insert hyphens in previously confirmed segments which had dashes in them. After all these are two different chara... See more Having a system that did everything we want it to do in a perfect way WOULD be a great improvement! But I'm not expecting perfection here. I just want the system to stop doing something that it is not supposed to do nor is it designed to do.
When I enter a translation with a dash in it and press confirm, there is no logical reason why the software should then go back and insert hyphens in previously confirmed segments which had dashes in them. After all these are two different characters with different unicode numbers!
This is a programming error and we should not be expected to find workarounds. I hope someone from SDL looks in here and reads this! ▲ Collapse
| | | | Jerzy Czopik
Germany
Local time: 20:11
Member (2003)
Polish to German
+ ...
| Usualy SDL Support is monitoring the threads here | Jul 19, 2010 |
But left alone the change hyphen to dash what I do not understand is why the AutoPropagation is done for already confirmed segments.
Did you allow that? If yes, simply disallow it. IMHO this is not a setting which can be used for production purposes.
| | | | Scott Spellerberg (X)
Sweden
Local time: 20:11
Swedish to English
+ ...
| Well, it's been three years now... | May 14, 2013 |
... and still this aggravating automatic change of en-dash to a hyphen continues.
So, Trados developers, please note: A great many scientific journals tell their authors to use an en-dash for a number interval and *never* a hyphen. I can understand that programmers may not see this as important, to programmers dashes and hyphens are synonyms, but to the editors of many scientific journals, it is important. Thus, it would be real nice for Studio to simply use the same damned symbo... See more ... and still this aggravating automatic change of en-dash to a hyphen continues.
So, Trados developers, please note: A great many scientific journals tell their authors to use an en-dash for a number interval and *never* a hyphen. I can understand that programmers may not see this as important, to programmers dashes and hyphens are synonyms, but to the editors of many scientific journals, it is important. Thus, it would be real nice for Studio to simply use the same damned symbol we approved and be consistent. It is a huge time sponge to have to manually manipulate all of this one translation after the other, year after year, and no, manipulating the source file first, doesn't help much, nor should this be the translator's task. The TM software should know the difference between a f--ing hyphen and an en dash and an em-dash.
Now, there are some situations in which there is supposed to be a hyphen between digits as in a document name), so it's equally wrong for an automated use of a dash.
What's really needed is for the software to know that a hyphen and dash are as different in meaning as a plus sign and a minus sign. Why is this so hard? ▲ Collapse
| | | | | It's not so hard... | May 14, 2013 |
... but I think perhaps a little look at how the software handles this might help and then you will get more from it. So for example... I have this document with en-dash, em-dash and hyhpens. I open it with a clean TM and translate the first one. This is what I see:
So, #2 is confirmed and 3, 4, 6, 7, 8 are AP'd. The en-dash and em-dash are actually represented by tag... See more ... but I think perhaps a little look at how the software handles this might help and then you will get more from it. So for example... I have this document with en-dash, em-dash and hyhpens. I open it with a clean TM and translate the first one. This is what I see:
So, #2 is confirmed and 3, 4, 6, 7, 8 are AP'd. The en-dash and em-dash are actually represented by tags as you can see and so these are correctly carried over.
The hyphens are not tags and so are not AP'd. So I click in #10 and now get this:
It's a fuzzy because I have tagged content in the TM. I don't want to simply confirm this now or I will overwrite the one in my TM, so I add it as a new translation after adding the hypen to handle this case and then I get this:
If I now clear all the tranlsations and pretranslate with these two TU's stored in my TM I now see this:
So all three different types of dashes are recognised and correctly populated across the file.
I guess the problem comes when you then want to use an en-dash for example where the source is a hyphen? If I took one of the tags that represented this character then this would be a problem because Studio would see this as a tag error where you have introduced an additional tag into the target. But if I create a Quick Insert entry for this then I can add it, but also as an additional TU or I will overwrite the ones that had gone before:
If I look in my TM I now see this:
So I have three entries, one for tagged dashes, one for ordinary hyphens and one for ordinary hyphens that should be translated as en-dashes.
The point I wanted to make really is that if you want to do this type of thing then it's helpful to know how the software is trying to handle the information and when you know this you will be able to maximise your use of the features.
I hope I covered your usecases anyway... but if not, and if I'm going to have egg on my face after this, let me know and perhaps we can address the problem you have.
Regards
Paul ▲ Collapse
| | |
|
|
|
Nick Quaintmere
Germany
Local time: 20:11
German to English
+ ...
TOPIC STARTER | Doesn't quite fit the problem. | May 18, 2013 |
Thanks Paul for you extensive answer.
There's some very interesting information in there which, I'm sure, will be of great help to someone.
But it doesn't however cover my usage case. You see the problem I was having did not involve translating en-dashes to en-dashes or even simply en-dashes to em-dashes.
If you scroll up the page, you'll see what I was having problems with.
Namely cases such as these:
number[space][hyphen][space]number which ha... See more Thanks Paul for you extensive answer.
There's some very interesting information in there which, I'm sure, will be of great help to someone.
But it doesn't however cover my usage case. You see the problem I was having did not involve translating en-dashes to en-dashes or even simply en-dashes to em-dashes.
If you scroll up the page, you'll see what I was having problems with.
Namely cases such as these:
number[space][hyphen][space]number which has to be translated to
number[en-dash]number (without the spaces)
Trados seems to get confused when the source has spaces and the target doesn't. ▲ Collapse
| | | |
Hi Nick,
I've automated this kind of tasks with a replacement rule (Regular expression rule) in TermInjector (OpenExchange)
([0-9]+)/([0-9]+)/([0-9]+) \2/\1/\3
([0-9]+).([0-9]+) \1,\2
([0-9]+),([0-9]+).([0-9]+) \1 \2,\3
([0-9]+),([0-9]+),([0-9]+) \1 \2 \3
This is for English into French, the 1st line changes the date format (US to French)
The remaining lines change the number and decimal separator to the French format, you should... See more Hi Nick,
I've automated this kind of tasks with a replacement rule (Regular expression rule) in TermInjector (OpenExchange)
([0-9]+)/([0-9]+)/([0-9]+) \2/\1/\3
([0-9]+).([0-9]+) \1,\2
([0-9]+),([0-9]+).([0-9]+) \1 \2,\3
([0-9]+),([0-9]+),([0-9]+) \1 \2 \3
This is for English into French, the 1st line changes the date format (US to French)
The remaining lines change the number and decimal separator to the French format, you should be able to customise it to suit your needs.
Drop me an email if you need further help.
HTH,
Bernard
[Edited at 2013-05-18 15:49 GMT]
[Edited at 2013-05-18 15:53 GMT] ▲ Collapse
| | | | Alena Tomesova
Czech Republic
Local time: 20:11
Member (2013)
English to Czech
+ ...
| Still not fixed | May 25, 2015 |
I am following up on this thread to let SDL developers know that the bug is still here even in Studio 2014 and it is really tiresome to work around it.
I have read Paul's explanation of how Studio handles dash tags... but why does Studio consider them tags in the first place? They are simply different Unicode characters, so I don't see why we should waste our time adding additional TUs, etc., only because it is a problem for Studio to use n-dash in the target if there is a hyphen i... See more I am following up on this thread to let SDL developers know that the bug is still here even in Studio 2014 and it is really tiresome to work around it.
I have read Paul's explanation of how Studio handles dash tags... but why does Studio consider them tags in the first place? They are simply different Unicode characters, so I don't see why we should waste our time adding additional TUs, etc., only because it is a problem for Studio to use n-dash in the target if there is a hyphen in the source. Other CAT tools I use handle this without problems.
We have to deal with this on a daily basis. Different languages have different typographic rules (not to speak about the fact that most authors of source documents don't know them anyways).
I have exactly the same problem as Nick. In Czech, it is mandatory to use n-dash and no spaces when expressing a range (1–5 metres). What I get in the source text is all kinds of stuff, 1-5 metres, 1 - 5 metres, 1- 5 metres.. and Studio cannot handle these properly.
What is so difficult about a rule
turn
[number1] [(space can be here) (something1) (space can be here)] [number2]
into
[number1] [(no space)(something2 -- it may be identical to something1 but not necessarily)(no space)] [number2]
for example
[1] [(space) (hyphen) (space)] [2]
into
[1] [(no space) (n-dash) (no space)] [2]
???
When you have TMs with a lot of numbers, Studio picks up absolutely random combinations. How can it make a slash out of a hyphen?
Example 1:
Then I uploaded another file, this time without spaces in the source text.
This came up although I had previously translated 2014-2015 as 2014–2015:
And autopropagated like this:
I saved the TU with an n-dash. Why does it keep coming up with a hyphen then? Or is it my settings? If so, why does Studio not get it right by default?
[Edited at 2015-05-25 11:41 GMT]
[Edited at 2015-05-25 11:42 GMT]
[Edited at 2015-05-25 11:44 GMT]
[Edited at 2015-05-25 11:45 GMT] ▲ Collapse
| | | | | Why does Studio not trust us translators? | Jul 18, 2015 |
I also find this behaviour very annoying. I'm on Studio 2015 now, and still the same issue.
Source segments:
$15-30,000
$30-70,000
$70-100,000
$100-250,000
So, number ranges spelt with a hyphen.
I translate the first segment:
$15–30.000 [note the en-dash!]
And auto-propagation populates the next 3 like this:
$15-70.000
$15-100.000
$15-250.000
So, the thousands separator is correctly... See more I also find this behaviour very annoying. I'm on Studio 2015 now, and still the same issue.
Source segments:
$15-30,000
$30-70,000
$70-100,000
$100-250,000
So, number ranges spelt with a hyphen.
I translate the first segment:
$15–30.000 [note the en-dash!]
And auto-propagation populates the next 3 like this:
$15-70.000
$15-100.000
$15-250.000
So, the thousands separator is correctly replaced (Thank you, Studio) BUT the hyphens are pulled from the source. Why? I used an en-dash for a reason, but Studio seems to "think" I'm stupid.
Is there a way to add default formats for number ranges in "Auto-substitution", just as there are for dates and times? PLEASE!!!
Best regards,
Stefan ▲ Collapse
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Auto-propagation problem with dashes/hyphens in Trados 2009 | 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 » |
| | Trados Studio 2022 Freelance | The leading translation software used by over 270,000 translators.
Designed with your feedback in mind, Trados Studio 2022 delivers an unrivalled, powerful desktop
and cloud solution, empowering you to work in the most efficient and cost-effective way.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news related to SDL Trados
