Users quite often work with AnyTM for file based resources but when they migrate to GroupShare the feature is unsupported as result the functionality of the translation system is decreased from translator's point of view.
Hi Yuriy Belik - There is the option "AnyTM: Any server-based TM " - which works with GroupShare TMs. Is this what you are looking for, or is it something different?
The AnyTM: Any server-based TM allows ignore sublanguages only. My idea is to use en-ru TM along with ru-en as reference as it possible for file based TM.
Hi Yuriy Belik ,
I think I understand the problem now. The "AnyTM - Any server-based TM" option works in Studio and it allows you to use any GroupShare TM for your project. BUT, what it does not do, is, it does not revert the languages. So if on a project you have EN_US - RU_RU language pair and add a GS TM with RU_RU - EN_US with AnyTM, then your English text will go in the Russian part of the second TM (lookup will not look in the English part either). So this is indeed less functionality as a file-based version. However, for file-based TMs, I am not sure if you noticed, AnyTM actually creates a new TM in the background with reversed languages in the same location as the TM you are adding is located. This should be possible with GroupShare TMs technically, but not nearly as easy. One topic there would be cleanup. If AnyTM will create a new server TM with reversed language pairs - should it leave it there once you're done? What if the server TM has 1 million TUs in it? That would take a long time to create a new one with reversed languages. But, this being said, there is already an enhancement filed for this in our internal system with ID: LG-6914 (for future reference).
I'm glad to hear that the enchantment is already registered. I know how the file based tm works :) The server reversed or temporary TM could be created "on demand" for example user marks TM for reverse and if it contains more than 100k TUs the task will be send to GroupShare background tasks as for amount of disk space or quantity of TMs the some kind of life time could be set managed by user.
In our Translation Department reversing TMs is a very important feature, although all our TMs are server-based. In this case when we select Use Any server-based TM lookup does not work in reverse language, for example if we a project En-Gb - Ru-Ru we do not see segments from TM with language pair Ru-Ru - En-Gb which is frustrating. We can find segrements only using Concordance Feature selecting Search Target.
Speaking of the cleanup topic you mentioned, why should Trados create a new [reverse] TM?
Other CATools (memoQ for example) can easily read any TM, no matter what language direction it is, and such TMs are not updated but just read.
You may update 1 million-segment EN-RU TM while just reading 5 other million-segment RU-EN TMs. No problem. Why not do the same for Trados?
By the way, the same story with Termbases. You cannot use such an obvious thing as Termbase search for target terms. If your project is EN-RU, you will never find a term in Russian.
Hi Vasiliy Golovatskiy Stepan Konev , thank you for your contribution. This is very good, it helps us understand better the customer perspective. This idea is for sure a good one (I voted for it! :)). I think that for file-based TMs right Studio needs to create a reverse TM in the background due to the technology used for the TM. I don't think it is even technically possible to directly look up languages in the reverse order, so this may require a bigger change, but it is indeed a good suggestion. As for termbases, you currently can assign any project language to any termbase language and term recognition/term search will work. For more serious term management, you can use MultiTerm Desktop which will allow the search to be performed for any of the languages. Why would you need to search in the target language though in the Studio Editor? I am not a translator myself, so maybe I am missing something, but right now, if you click inside a target segment, Studio will automatically recognize all terms. Then you have AutoSuggest who will present to you the target translation of the term, so it is very easy to insert it. I am not sure when and why would one need to search in the target language?
Why would one need to search TM in its target section? But Trados still (finally) has this option.
Example: I have an abbreviation 'WPQT' that is not a term (not included in termbase) in my English source. From context, I suspect (I feel that it must be) a Russian equivalent [допускной лист] but I still need confirmation.
Now, without TB target search feature, I have to switch to Ru-En project and search for "допускной лист". After it finds a "допускной лист сварщика", I see the proper term in English: Welder Performance Qualification Test Record. Ok, from now I can safely use the suspected equivalent as true one.
I don't think Kilgray would ever add this option to their memoQ, if it was not obviously needed by translators. But they did it from their earliest versions several years ago without asking why we need it =)
Hi Stepan Konev , thank you for the clarification, it does make sense now that you have given us an example. Thank you.
I also think this is an extremely important enhancement. Not being able to benefit from work in the reverse Language pair is limiting especially for corporations who are constantly translating content back and forth related to the same topic/field. In GroupShare I know you can add several Language pairs to a TM. In the case of adding, for example, English_US > Portuguese_BR and Portuguese_BR > English_US how would you use AnyTM Server based in this case? Or do they have to be two separate TMs? What is the purpose of creating a multi-lingual TM in GroupShare if reverse languages don’t work in the same TM? I think that ideally you should define the language pairs for a TM in GroupShare and then they update between the languages automatically, but I guess this isn’t possible, right? If I’m not mistaken I remember back in SDLX you could add all your Language pairs in a TM and if you chose EN_PT it would automatically reverse your TM in a PT_EN job. Was that because it was based on access databases? In SQL wouldn’t it work the same way?