Forum: SDL Trados support
Topic: Studio 2014 11.0.3688.0
Poster: Enrico C - ECLC
Post title: I have checked
[quote]Shai Nave wrote:
[quote]Enrico C - ECLC wrote:
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?
[/quote]
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.
[quote]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. [/quote]
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]
Topic: Studio 2014 11.0.3688.0
Poster: Enrico C - ECLC
Post title: I have checked
[quote]Shai Nave wrote:
[quote]Enrico C - ECLC wrote:
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?
[/quote]
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.
[quote]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. [/quote]
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]