Studio 2014 11.0.3688.0 Thread poster: Enrico C - ECLC
|
|---|
Dear SDL (Paul, Richard?)
I am noticing a few issues that apparently started with the last update (not sure).
I have two main issues + a few smaller ones:
1) Some terms that are in the MT database don't show (Random issue with random terms). The term is in the segment, it's also in the MT database i open but it doesn't show. When then i try to add it i get the usual message telling me the term is already in the database and whether i want to merge it. If it's alre... See more Dear SDL (Paul, Richard?)
I am noticing a few issues that apparently started with the last update (not sure).
I have two main issues + a few smaller ones:
1) Some terms that are in the MT database don't show (Random issue with random terms). The term is in the segment, it's also in the MT database i open but it doesn't show. When then i try to add it i get the usual message telling me the term is already in the database and whether i want to merge it. If it's already in (and i know it and even see it) why it doesn't show when it is supposed to do it?
2) Concordance: We're not quite there yet. Some segments are say 95% similar. I get a similar segment and check the differences. Well, the concordance window shows me the similar part in YELLOW (All fine till there), But DOES NOT show me the missing part in blue or any other colour. What does this imply? It implies that i can copy/paste a portion of segment thinking that is correct (All yellow) while in actual fact there is one missing word or more.
I also have the impression concordance is not leveraging the TM properly.
I have realized this today and i am fairly disappointed at the performance the CAT is offering in this respect. It's forcing me to extra checks i shouldn't do under normal conditions (Studio 2011 didn't have this specific issue, it was actually pretty accurate).
3) Numbers: Look guys you need to find a solution for numbers. Whatever setting i adopt numbers are just "numb nutty". Dates mistaken for amounts, amounts mistaken for else. I need to check numbers in most of my translations and your QA in this respect is terrible. Not only the QA, but also during translating.
I want "1,23" mm in a 20 item list, i change the first item and it's all ok; i change the second item (sometimes autopropagation doesn't work with numbers, that's another issue) as "1,45 mm" and immediately the first one goes from "1,23 mm" to "1,23mm". I have to lock segments to make all this work.
4) Filters often don't find what i look for.
5) Capital letter "A" doesn't work in the filter field
I am not asking you to do magic in 30 seconds as this is about wrong algorithms but can i at least know whether you have any solution in the works? I can grant you guys this is really making translating very frustrating.
[Edited at 2013-11-29 04:12 GMT] ▲ Collapse
| | | | Erik Freitag 
Germany
Local time: 01:39
Member (2006)
Dutch to German
+ ...
Enrico C - ECLC wrote:
1) Some terms that are in the MT database don't show (Random issue with random terms). The term is in the segment, it's also in the MT database i open but it doesn't show. When then i try to add it i get the usual message telling me the term is already in the database and whether i want to merge it. If it's already in (and i know it and even see it) why it doesn't show when it is supposed to do it?
This has been a confirmed bug since at least Studio 2011 (don't know if it was present in 2009 as well, but I guess so). Nothing changed so far.
Enrico C - ECLC wrote:
I want "1,23" mm in a 20 item list, i change the first item and it's all ok; i change the second item (sometimes autopropagation doesn't work with numbers, that's another issue) as "1,45 mm" and immediately the first one goes from "1,23 mm" to "1,23mm". I have to lock segments to make all this work.
I'm experiencing this as well. I think the reason is inconsistent usage in the source text (so Trados needn't worry )
| | | | David Bullock
Germany
Local time: 01:39
Member (2012)
German to English
| I am having a different problem with this Studio 2014 update. | Nov 29, 2013 |
I use the term base quite extensively, and before this update (after eliminating the Java 45 problem) adding terms to the termbase during the translation process worked very efficiently. Now however there is always a delay before I can confirm (Ctrl + F12), delay before the curser is available for use, the delay is sometime as much as 5 seconds, which is a real handicap.
Of course I have the Java 45, because the Java 24 no longer works, so this is definately a Java 45/Studio 2014 c... See more I use the term base quite extensively, and before this update (after eliminating the Java 45 problem) adding terms to the termbase during the translation process worked very efficiently. Now however there is always a delay before I can confirm (Ctrl + F12), delay before the curser is available for use, the delay is sometime as much as 5 seconds, which is a real handicap.
Of course I have the Java 45, because the Java 24 no longer works, so this is definately a Java 45/Studio 2014 compatability problem. As SDL issued this update I am surprised that they did not fully check this. Or am I the only preson with this problem.
I use a DEL Precision M4400 with Windows 7. ▲ Collapse
| | | | Giles Watson
Italy
Local time: 01:39
Italian to English
In memoriam | Java problem | Nov 29, 2013 |
DavidSEG wrote:
I use the term base quite extensively, and before this update (after eliminating the Java 45 problem) adding terms to the termbase during the translation process worked very efficiently. Now however there is always a delay before I can confirm (Ctrl + F12), delay before the curser is available for use, the delay is sometime as much as 5 seconds, which is a real handicap.
Of course I have the Java 45, because the Java 24 no longer works, so this is definately a Java 45/Studio 2014 compatability problem. As SDL issued this update I am surprised that they did not fully check this. Or am I the only preson with this problem.
I use a DEL Precision M4400 with Windows 7.
Hi David.
This is a Java problem, according to Richard from SDL.
The good news is that - at last - SDL seem to have taken on board that Java is more trouble than it's worth.
| | |
|
|
|
Shai Navé
Israel
Local time: 02:39
English to Hebrew
+ ...
| Checking the measurement format | Nov 29, 2013 |
Enrico C - ECLC wrote:
I want "1,23" mm in a 20 item list, i change the first item and it's all ok; i change the second item (sometimes autopropagation doesn't work with numbers, that's another issue) as "1,45 mm" and immediately the first one goes from "1,23 mm" to "1,23mm". I have to lock segments to make all this work.
Have you checked: File > Options > [Relevant Language Pair] > Translation Memories and Automated Translation > Auto-substitution > Measurements to make sure that the unit of measurement format setting is in ling with your preferences/requirements?
The slowness when editing terms is not really a problem (in the sense of something that doesn't work as supposed to) or incompatibility, as I've tried to explain here:
Shai Nave wrote:
The slowness that you are referring to is "by design", a side effect of adapting to Oracle's security concept. This concept requires components to be digitally signed, and the slowness occurs when the Java Runtime Environment verifies these signatures. It should be noticeable only the first time editing a term in a session, but from my experience it usually occurs for the following terms as well.
The benefit from all of this is a better integration that should reduce the amount of security prompts and tweaking - which is quite an issue for some users - and overall make the user experience more stable and reliable (the latter got off to a bad start, but hopefully this was solved).
I think that this is an acceptable trade-off in the interim, but strongly believe that SDL should drop Java altogether as a long-term security solution and for a better user experience.
| | | |
3) Numbers: Look guys you need to find a solution for numbers. Whatever setting i adopt numbers are just "numb nutty". Dates mistaken for amounts, amounts mistaken for else. I need to check numbers in most of my translations and your QA in this respect is terrible. Not only the QA, but also during translating.
I want "1,23" mm in a 20 item list, i change the first item and it's all ok; i change the second item (sometimes autopropagation doesn't work with numbers, that's another issue) as "... See more 3) Numbers: Look guys you need to find a solution for numbers. Whatever setting i adopt numbers are just "numb nutty". Dates mistaken for amounts, amounts mistaken for else. I need to check numbers in most of my translations and your QA in this respect is terrible. Not only the QA, but also during translating.
I want "1,23" mm in a 20 item list, i change the first item and it's all ok; i change the second item (sometimes autopropagation doesn't work with numbers, that's another issue) as "1,45 mm" and immediately the first one goes from "1,23 mm" to "1,23mm". I have to lock segments to make all this work.
Can you provide examples of Dates, amounts and more? This can be easily fixed in TermInjector and provides 100% matches without fail.
Cheers,
Bernard
[Edited at 2013-11-29 19:19 GMT] ▲ Collapse
| | | | Enrico C - ECLC
Taiwan
Local time: 07:39
English to Italian
+ ...
TOPIC STARTER | I have checked | Dec 1, 2013 |
[quote]Shai Nave wrote:
[quote]Enrico C - ECLC wrote:
Have you checked: File > Options > nt Language Pair] > Translation Memories and Automated Translation > Auto-substitution > Measurements to make sure that the unit of measurement format setting is in ling with your preferences/requirements?
Hi Shai, It's set on "Always add a space between number and unit". I have noticed though that sometimes it self resets for some reason i have no clue of.
The slowness that you are referring to is "by design", a side effect of adapting to Oracle's security concept. This concept requires components to be digitally signed, and the slowness occurs when the Java Runtime Environment verifies these signatures. It should be noticeable only the first time editing a term in a session, but from my experience it usually occurs for the following terms as well.
I think that this is an acceptable trade-off in the interim, but strongly believe that SDL should drop Java altogether as a long-term security solution and for a better user experience.
I read your other post on the lengthy Oracle process. However the part i don't agree on is that since this is "by design" i have to consider it as normal. I explained here (and to SDL other times) that the use of Java altogether doesn't only slow down our job with features "by design" that seem to be made to frustrate rather than to please, but also with endless bugs which most times are caused by the same Java platform. The mechanism you explain is not based on a "number of terms". It's based on time. First time it takes anything between 30 to 40 seconds to allow you to insert the term (if no error messages are displayed); past the first time if you insert terms immediately after it's quick. If you then wait X minutes between a term and the other, the issues shows up again and again and yet again. Imagine this show going on for a typical working day of 12 hours in a row when you handle big projects.
So i do agree they should trash the Java thing altogether, i have written that countless times. I don't agree on the fact that since this is by design then it's all ok. These are productivity suites; they should be designed and tested to boost it, not to slow it down.
[Edited at 2013-12-01 03:12 GMT]
| | | | Enrico C - ECLC
Taiwan
Local time: 07:39
English to Italian
+ ...
TOPIC STARTER
Bernard Lieber wrote:
3) Numbers: Look guys you need to find a solution for numbers. Whatever setting i adopt numbers are just "numb nutty". Dates mistaken for amounts, amounts mistaken for else. I need to check numbers in most of my translations and your QA in this respect is terrible. Not only the QA, but also during translating.
I want "1,23" mm in a 20 item list, i change the first item and it's all ok; i change the second item (sometimes autopropagation doesn't work with numbers, that's another issue) as "1,45 mm" and immediately the first one goes from "1,23 mm" to "1,23mm". I have to lock segments to make all this work.
Can you provide examples of Dates, amounts and more? This can be easily fixed in TermInjector and provides 100% matches without fail.
Cheers,
Bernard
[Edited at 2013-11-29 19:19 GMT]
Hi Bernard,
Dates are considered as wrong numbers during QA but no issues during translating. Numbers in general are an issue during QA (Doesn't matter which settings you pick up).
You can have Article codes for clothing for example, in forms like "ABC-23456S". It will show as an error during QA. Then with measurements you have this issue of spacing that shows pretty frequently but not always.
Checked all settings and they look ok but sometimes i see that those settings change without me touching them. I also had cases of options resetting themselves without any intervention (as if a silent update had been applied or as if the software had undergone a reset with default settings being applied without me knowing that).
| | |
|
|
|
Enrico C - ECLC
Taiwan
Local time: 07:39
English to Italian
+ ...
TOPIC STARTER | Never had this in 2011 | Dec 1, 2013 |
efreitag wrote: Enrico C - ECLC wrote:
1) Some terms that are in the MT database don't show (Random issue with random terms). The term is in the segment, it's also in the MT database i open but it doesn't show. When then i try to add it i get the usual message telling me the term is already in the database and whether i want to merge it. If it's already in (and i know it and even see it) why it doesn't show when it is supposed to do it?
This has been a confirmed bug since at least Studio 2011 (don't know if it was present in 2009 as well, but I guess so). Nothing changed so far. Enrico C - ECLC wrote:
I want "1,23" mm in a 20 item list, i change the first item and it's all ok; i change the second item (sometimes autopropagation doesn't work with numbers, that's another issue) as "1,45 mm" and immediately the first one goes from "1,23 mm" to "1,23mm". I have to lock segments to make all this work. I'm experiencing this as well. I think the reason is inconsistent usage in the source text (so Trados needn't worry )
Hi Efreitag,
I actually never had such an issue on 2011. As to numbers, i had exactly the same issues with Studio 2011 and i don't understand what you mean by "Inconsistent usage in source text"! There are options in Studio allowing you to represent the target numbers in a certain way. I set those up...they may work or not. So for me Trados does have to worry.
| | | | Enrico C - ECLC
Taiwan
Local time: 07:39
English to Italian
+ ...
TOPIC STARTER | I have this sequence | Dec 1, 2013 |
DavidSEG wrote:
I use the term base quite extensively, and before this update (after eliminating the Java 45 problem) adding terms to the termbase during the translation process worked very efficiently. Now however there is always a delay before I can confirm (Ctrl + F12), delay before the curser is available for use, the delay is sometime as much as 5 seconds, which is a real handicap.
Of course I have the Java 45, because the Java 24 no longer works, so this is definately a Java 45/Studio 2014 compatability problem. As SDL issued this update I am surprised that they did not fully check this. Or am I the only preson with this problem.
I use a DEL Precision M4400 with Windows 7.
PC used: Acer 8951G/16GB DDR RAM/2x750GB 7200RPM HDD, i7 2630QM CPU, Windows 8.1 (So no slouch!). Everything is executed extremely fast on the machine, from videogames to internet, videos, QA Distillers, name it and it's damn fast. I put on Studio and the snail thing starts
1) First TB use: 30/40 seconds to insert a term (I go watch news on the browser normally)
2) If you add a second term to MT it's reasonably fast (I know faster ones where with a key combination you add and confirm the new term in less than 2 seconds without need for F12 confirmation)
3) If you wait, say 30 mins (arbitrary time as i don't know exactly how long it takes for this to happen, except that it happens consistently so it should be reproducible) between one term insertion and the other, then the whole process described by Shai in another post starts and it's slow again.
The rest of the CAT works as fast as usual and i am happy with that. MT integration is terrible, in my opinion because it was never designed to be really integrated into the Editor interface + Java does a terrible job that prevents the CAT from shining as it should.
| | | | | Dates & Numbers | Dec 1, 2013 |
Hi Enrico,
The following lines fix the number and date issues when using TermInjector:
Monday, September ([0-9]+), ([0-9]+) lundi, \1 septembre \2
September ([0-9]+), ([0-9]+) \1 septembre \2
([0-9]+).([0-9]+)([a-z]+) \1,\2 \3
([0-9]+),([0-9]+).([0-9]+)([a-z]+) \1 \2,\3 \4
([0-9]+)([a-z]+) \1 \2... See more Hi Enrico,
The following lines fix the number and date issues when using TermInjector:
Monday, September ([0-9]+), ([0-9]+) lundi, \1 septembre \2
September ([0-9]+), ([0-9]+) \1 septembre \2
([0-9]+).([0-9]+)([a-z]+) \1,\2 \3
([0-9]+),([0-9]+).([0-9]+)([a-z]+) \1 \2,\3 \4
([0-9]+)([a-z]+) \1 \2
see screenshot:
http://s1360.photobucket.com/user/blieber45/media/Dates_Numbers_zps7ed26e7f.jpg.html?filters[user]=136107018&filters[recent]=1&sort=1&o=0
Cheers,
Bernard ▲ Collapse
| | | | Shai Navé
Israel
Local time: 02:39
English to Hebrew
+ ...
| Some comments | Dec 1, 2013 |
Enrico C - ECLC wrote:
Hi Shai, It's set on "Always add a space between number and unit". I have noticed though that sometimes it self resets for some reason i have no clue of.
So maybe Studio mishandles numbers and/or measurement units in you language pair for some reason. It has been known to have language pair specific bugs/issues (in mine there are some dating back to Studio 2009 and even Trados 2007).
I read your other post on the lengthy Oracle process. However the part i don't agree on is that since this is "by design" i have to consider it as normal.
I never argued that you should just blindly accept it. I only meant to say that the slowness has its reason and is a result of how the security mechanism works; therefore, there isn't anything to fix really because this is not a technical problem by definition, it is a user experience related issue. When looking back on Java and Studio/Trados misbehaviors I don't think that it could be claimed that in the past everything ran smoothly. Maybe the slowness wasn't there as much but there were other errors and issues that also hurt the user experience, so in a way with Java and MultiTerm its a choose your poison kind of situation when it comes to user experience.
I don't like the slowness either, and agree with you that its a nuisance, but I can live with it in the interim knowing that I don't have to compromise Java security settings in order to get it to work, and that there is far less chance of a random security prompt/error/issue popping up out-of-the-blue in the middle of a project with no apparent reason (if it does, like with the infamous Java 45 update, at least I know that something has changed and can revert back). I don't, however, think that writing off the slowness as a security "feature" is an acceptable solution in the long term because it hurts the user experience and efficiency of working with the tool.
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Studio 2014 11.0.3688.0 | 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 » |
| | Anycount & Translation Office 3000 | Translation Office 3000
Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news related to SDL Trados
