Trados Business Manager
Speech to Text
Managed Translation - Enterprise
Translation Management Connectors
Language Weaver Connectors
Language Weaver Edge
Tridion Docs Developers
RWS User Experience
Internal Trados Studio Ideas
RWS Community Internal Group
RWS Access Customer Portal
RWS Professional Services
RWS Training & Certification
RWS Enterprise Technology Partners
Trados Academic Partners
Trados Approved Trainers
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic Tridion Docs User Group
Tridion Docs Europe & APAC User Group
Tridion UK Meetup
Tridion User Group Benelux
Tridion User Group New England
Tridion User Group Ohio Valley
Tridion West Coast User Group
WorldServer User Group
Trados GroupShare Ideas
Trados Studio Ideas
Language Weaver Ideas
Language Weaver Edge Ideas
RWS Language Cloud TMS Ideas
RWS Language Cloud Terminology Ideas
RWS Language Cloud Online Editor Ideas
Managed Translation - Enterprise Ideas
Tridion Docs Ideas
Tridion Sites Ideas
LiveContent S1000D Ideas
Events & Webinars
To RWS Documentation
To RWS Support
Detecting language please wait for.......
It is very tedious to go through false positives for a large document to check only the changes or new content I have translated.
There is a filter for new translated content, but it seems it doesn't filter out old messages about old content when I run Verifiy (F8).Is there a way to filter the verification messages for only new translated content or colour them differently?
(Similar to the filtering in Passolo where it is possible to check and spellcheck only newly translated content?
If not, that would be a feature worth adding considering how many times the word "productivity" features on the SDL web site.
While I'm here and if a developer reads this (probably not), mouse wheel scrolling doens't work for translation matches, it works for concordances, but needed to click in the window.
Also congratulations to the development team to finally put the Open project dialog on top of the main window instead of hiding it in the background. It took five versions, but hey, great!
I generally translate files in "batches" of 300 to 500 words, i.e. I translate a batch of segments, read through them again and make any changes needed, and then perform a spellcheck and verify.
After this, the segments in the current batch have the status of "Translated".
I then temporarily change their status to "Translation Approved" and lock them so that they will not be verified again until the end of the translation. (Because I have checked "Exclude locked segments" in Project Settings -> Verification -> Segments to Exclude, the verification only checks the current batch of translated segments, not the segments in previous batches that I have locked.)
When I have finished the whole file, I unlock all the "Translation Approved" segments and change their status to "Translated". Just to be safe, I then run another verification for the whole file.
Another advantage of this procedure is that I can immediately see how many words I have translated in the current batch, since previous batches have the status "Translation Approved".
If you don't care about seeing the size of the current batch of translated segments, then you don't have to change their status to "Translation Approved". Simply locking them will prevent them from being verified again until they are unlocked. (Make sure you "Exclude locked segments" in the verification settings, as indicated above.)
Hi Bruce Campbell and Thomas LoobWhen I read the scenario that Thomas mentioned, using segment status against checked segments alongside settings that control what gets verified is exactly what I was about to suggest. Well done for the suggestion.While we can support multi-select segment status change from translated to locked -I would appreciate if some felt this was click heavy. Especially if you do want to revisit the target translation at a later date, as it then requires unlocking then locking again.While we want to protect key workflows where translation approved is heavily relied on and already very well established for many, without adding confusion, we could think about supporting some segments marked as "QA Checked". Regardless of segment status its then excluded from ongoing verifications.If anyone has other ways in which we can better support the scenario's explained so well above, please do comment. A big however would be, why are you getting false positives? I know they happen but in an ideal world we address them. So Thomas Loob, could you please expand on your examples in more detail as we could review the built in QA behaviour and sensitivity - or perhaps there is already QA app that will reduce your false positives.
I just want to spellcheck my current work and not involve already approved and/or locked content.Very easy to implement and should be done ASAP. Use Passolo filtering as a suggestion. Easy.
The possibility to use the scroll wheel to browse in the translation fuzzy match window should be implemented ASAP. The earlier version had it and it is strange it was removed.
Hi Lydia Simplicio
I think what Thomas was referring to with "false positives" is the following: You run a verify, check through all the messages, correct those that need to be addressed and then are often left with a long list of "errors", "warnings" and "notes" that are actually okay. You purposely want to leave those segments unchanged as there is nothing really wrong with them. So, since Studio falsely identifies something as an error, warning or note that is actually okay, they are "false positives".
Then you do some more translation and run another verify. All of the previous messages naturally pop up again, so you have to wade through a list that gets longer and longer as you continue translating. You have to go through the same "false positives" that you checked the last time, and the time before that, and the time before that, and the time before that.
That is why I lock the previous segments before I do the next verify. Because it is tedious and a waste of time to go through the same long list of messages looking for one or two new messages scattered somewhere throughout the list that you had from the last verify.
That is the process I use.
I don't know what you mean when you say "in an ideal world we address" false positives.
Since it appears that the verify command was designed as something you use once when you have finished the translation, are you saying that in an "ideal world" we run a verify once we have finished the translation and then "address" all of the messages and somehow eliminate all of them? I run verifies all the time, and it is very rare that I eliminate all the messages. I guess I don't live in an ideal world.
So how could Studio handle this better for me?
Let's take a look at the long list of possible "segments to exclude" in the Studio settings: perfect matches, exact matches, fuzzy matches down to, new translations, repetitions, confirmed translations, locked segments, target segment identical to source, segments in the following contexts (whatever that is).
The only one that I can control (i.e. "turn on and off"), which makes it the only one that is useful to me, is "locked segments", which is why I use it.
What else would I find useful? As I mentioned above, once I have run a verify, I select all the translated segments and change their status to translation approved. It would be nice if I didn't have to lock them, i.e. if I could exclude segments that have a status of translation approved from the verify.
What the heck, why not go all the way and let people also exclude segments with a status of signed-off, translation rejected or sign-off rejected?
Of course, I generally do a spellcheck before I perform the verify, so it would also be nice to be able to ignore segments with these kinds of status when doing a spellcheck. Currently you can only ignore locked, 100% matches, and context matches and perfect matches. That means the only way I can currently control which segments are ignored during spellcheck is to lock them.
And when I translate a batch of segments, I sometimes leave some segments in draft status. To me, draft status means I want to go back and check the segment again, so I don't really want it to be included in the spellcheck or verify. That means if I have a large number of draft segments, I might also lock all of them before running the spellcheck and verify, because it is tedious to have to wade through verify errors and spelling errors for a draft segment that might just consist of a few notes to myself to help me remember something when I am finally ready to translate the segment.
So why not also add the possibility of excluding draft segments from the verify and spellcheck along with all of the other kinds of segment statuses. After all, segment status is the only thing you can really control (i.e. by selecting segments and using the "Change Segment Status" batch command).
I guess it is nice to have all of those other segment types that Studio currently allows me to exclude, but to tell you the truth I have never used any of them. And if I did use them for the verify, it would be irritating if I couldn't exclude the same segments from the spellcheck.
Thank goodness Studio allows you to exclude locked segments from both the verify and spellcheck. That little bit of consistency keeps me sane.
And if Studio is changed to add the different segment statuses to the list of possible exclusions for the verify command, I might not use them if I they aren't also made available for excluding segments from the spellcheck.
Of course, you could say that I am using the segment status for something it was never designed for.
That is because what I would really like to see is the ability to assign an arbitrary label to a group of segments. Since I can't do that, I just use what is available, even though it was never intended for that use.
For example, if a document has a number of sections, I might want to assign different labels to the segments in each section and then see the different wordcounts show up in the analysis for each label (i.e. section). If I could assign labels to groups of segments, then I wouldn't have to use the segment status as an ad hoc "label".
And, believe me, sometimes I end up using all of the available statuses as labels for different groups of segments that I want to handle at different points during the translation. It would be nice to have even more "labels", but they just aren't available, and I have to make do with what Studio provides.
So that is my opinion about the irritating "false positives" that Thomas mentions.