| Pages in topic: [1 2 3 4 5 6] > | Studio 2009 bugs that were never fixed Thread poster: Pavel Tsvetkov
|
|---|
Pavel Tsvetkov 
Bulgaria
Local time: 14:06
Member (2008)
English to Bulgarian
+ ...
MODERATOR
Dear All,
Here is a short list of problems with Studio v2009 that were never fixed (I bought it after the release of SP1 and have been using it ever since) - and most probably will never be - in light of the approaching release of the new v2011:
1. Java still crashes Studio
This problems goes back as far as the first version of Trados that I bought - v2007 Freelance, so it is a 4-years-old problem that SDL ... See more Dear All,
Here is a short list of problems with Studio v2009 that were never fixed (I bought it after the release of SP1 and have been using it ever since) - and most probably will never be - in light of the approaching release of the new v2011:
1. Java still crashes Studio
This problems goes back as far as the first version of Trados that I bought - v2007 Freelance, so it is a 4-years-old problem that SDL does not know how to fix. You still are supposed not to update Java or else... So all Trados users are forced to keep an obsolete version of Java on their computers to be able to use Trados.
Things have improved over the past 6-12 months, but still Studio crashes once every 3000 words translated (a rough estimate) even with all updates installed. It is a pity.
Is there a light at the end of the tunnel? Honestly, I do not think so.
2. Autosuggest crashes Studio
The heavily advertised Autosuggest feature can indeed speed up your work, but it can also crash Studio - and it does. The only known fix is to close and restart Studio - until it crashes again. SDL have been notified of the problem on multiple occasions (and by multiple customers), but simply cannot find a solution - to the best of my knowledge.
Is there a light at the end of the tunnel? Maybe v2011 will offer a fresh solution, but that remains to be seen. At this point it all sounds as unfounded optimism to me.
3. Term recognition window does not show termbase names
This problem has been around for quite awhile, but it seems that SDL is not in a hurry to fix it. It happens when the name of the termbase is longer and would need you to use the horizontal slider to see it in full. It is an annoying problem as you do need to see the name of the termbase to know where the term is coming from and decide whether to use it or not.
Is there a light at the end of the tunnel? I do not know, maybe not. Obviously SDL does not consider this to be an important problem as they refuse to invest time in solving it.
4. When adding a new term from inside Studio, it will wrongly inform you that the term is already present in your termbase if it is present in any of the secondary termbases attached (and not present in your primary one)
Well, that says it all. Generally, you cannot add a term to all your attached termbases, only to your primary one. Nevertheless, Studio will tell you that the terms is already present (while it is not) in those cases when the term is present in one of the secondary ones. It is a pain in the back, because you have to check every time to make sure and then add it again, which is a waste of your precious time.
Is there a light at the end of the tunnel? Hopefully. I have not read and SDL comment on this one.
5. You never know if your project will be set up successfully or not until the source files have been exported to translatable format. You never know if the translation will be finalized correctly.
About 60% of projects set up with Studio v2009 on Windows XP Pro and concerning the most mundane of all formats: Words *.docs, will be set up correctly - the rest will crash Studio and leave you scratching your head and biting your nails. Two are the critical points at which your work seems seriously jeopardized with Studio: the setting up of your project and the finalization of the translation when v2009 will sometimes simply refuse to export the files and that is guaranteed to play on your nerves. The reasons are indeed varied, but the result remains: you can never be sure that you will start and finish work as expected with Studio, even when translating Word files.
Is there a light at the end of the tunnel? Not really. SDL's favorite answer is: we are not responsible for people not knowing how to format Word files. But that is just a clever mechanism of guilt shifting. As a freelancer I have to work with whatever the client sends me or he/she will turn to somebody else for the service. Unfortunately, v2009 does not make it easy for me to reliably work with Word files.
Well, that is all I can think of right now. I hope that others can help fill in the list. It being so short is actually a complement to SDL, as v2009 was completely unworkable when it was initially published and sold - and it took 2+ years to get it patched up and workable.
I sincerely hope that v2011 will present us with a mature and stable product that will not require 2-4 Service Packs and a multitude of small updates to get up to speed.
Kind regards,
[Edited at 2011-08-08 09:53 GMT] ▲ Collapse
| | | | Joakim Braun
Sweden
Local time: 13:06
German to Swedish
+ ...
But the toolbar icons are real nice.
| | | | Heinrich Pesch
Finland
Local time: 14:06
Member (2003)
Finnish to German
+ ...
Of course I update Java all the time and Trados/SDLX never crash. I haven't yet used Studio yet, but I'm sure it works as it should. Last update for Java is from last week.
| | | | | On your points | Aug 8, 2011 |
Hi Pavel,
1. Java still crashes Studio
I don't know if this is a general issue that affects everyone as you have written... certainly I don't think we recommend not updating Java. However there are enough posts in this forum to see it has been a problem for us until more recently. We actually see much less of this in Support, and in the forums than we used to.
But, to answer your question. 2011 has removed relia... See more Hi Pavel,
1. Java still crashes Studio
I don't know if this is a general issue that affects everyone as you have written... certainly I don't think we recommend not updating Java. However there are enough posts in this forum to see it has been a problem for us until more recently. We actually see much less of this in Support, and in the forums than we used to.
But, to answer your question. 2011 has removed reliance on Java almost completely with some big changes to the applications (Studio and MT) and also with brand new filters that are not Java reliant at all.
2. Autosuggest crashes Studio
It would be useful to know which version you are using. We had some rare occurrences of something odd happening prior to CU13 but it was rare. Can you refer me to the reports you mean... assuming they are on ProZ?
3. Term recognition window does not show termbase names (It happens when the name of the termbase is longer...)
This is a recognised issue, and has been resolved for the 2011 release.
4. When adding a new term from inside Studio, it will wrongly inform you that the term is already present in your termbase if it is present in any of the secondary termbases attached (and not present in your primary one)
I've played with this one a little and am getting confused about where the problem actually is, unless it's because of the one above where the termbase name does not show. If I have several termbases open and the term is in one of them I can see which one in the term recognition window and so know whether I need to add it to the default or not.
I imagine it starts to get a little messy when you have lots of terminology hits for that segment so I guess you are looking for something in the message that says the term is not in your default termbase rather than something telling you it is in one of your active termbases?
5. You never know if your project will be set up successfully or not until the source files have been exported to translatable format. You never know if the translation will be finalized correctly.
I'm not sure 60% is an accurate figure for all users, but 2011 has improved on almost all of the filetypes, but one thing you could do is add a generate target translations task to the prepare project batch tasks and this will prove before you start whether the files will round trip or not.
Regards
Paul ▲ Collapse
| | |
|
|
|
Pavel Tsvetkov
Bulgaria
Local time: 14:06
Member (2008)
English to Bulgarian
+ ...
MODERATOR TOPIC STARTER | Further comments | Aug 10, 2011 |
SDL Support wrote:
Hi Pavel,
1. Java still crashes Studio
I don't know if this is a general issue that affects everyone as you have written... certainly I don't think we recommend not updating Java. However there are enough posts in this forum to see it has been a problem for us until more recently. We actually see much less of this in Support, and in the forums than we used to.
But, to answer your question. 2011 has removed reliance on Java almost completely with some big changes to the applications (Studio and MT) and also with brand new filters that are not Java reliant at all.
It is good to know that v2011 finally gets rid of Java. In my personal experience it has always been a problem with Trados. A simple search here
http://www.proz.com/?sp=forum&action=SearchForum&advanced=y
for the words "java" or "java problem" shows that on this forum alone tens or hundreds of messages have been posted concerning said problem.
Here is a very recent posting concerning Java:
http://www.proz.com/forum/sdl_trados_support/132074-multiterm_error_message:_null_then_javalangnullpointerexception_java_upgrade_to_blame.html
As you will notice it also contains the usual absurd advice: do not upgrade.
Some time ago I posted on this forum with a Java problem:
http://www.proz.com/forum/sdl_trados_support/198811-fatal_error_in_java_runtime_environment_causes_sdl_xliff_validation_error.html
...and unfortunately, the issue was never addressed. In short Java seems to be Trados's kryptonite - and has always been - for as long as I have been using the program. On several occasions I have tried to update (after reading on this forum that problems have been resolved) only to run into bigger problems than I have imagined possible. So, no thanks, I am not touching that again.
SDL Support wrote:
2. Autosuggest crashes Studio
It would be useful to know which version you are using. We had some rare occurrences of something odd happening prior to CU13 but it was rare. Can you refer me to the reports you mean... assuming they are on ProZ?
Yes, of course I can:
http://www.proz.com/forum/sdl_trados_support/195676-nasty_autosuggest_error:_parsing_\bsafe_operation_and_self_assessment_based\b_not_enough_s.html
This was posted by me and then other users posted complaining that they had the same problem and that SDL was looking into it, but was not able to find a solution. The thread was never visited by SDL support or any of the other guys on this forum who seem to know a lot about solving Trados problems. The problem still persists. I know Autosuggest is going to crash Studio, but I am still trying to use it - for as long as it remains practical. At a certain point I just get tired and switch it off. Maybe it is a problem affecting some languages only - but this does not bring relief - Bulgarian with which I work seems to be one of those, so for me - and other translators like me - it is 100% faulty. What bothers me is that: (1) There is no solution of the problem, (2) It seems that SDL is not even aware of the problem even if customers are under the impression that SDL is hard at work solving it. I hope some clarification can be provided.
SDL Support wrote:
3. Term recognition window does not show termbase names (It happens when the name of the termbase is longer...)
This is a recognised issue, and has been resolved for the 2011 release.
This is good to know, thank you. I just hope that SDL shortens the response time for addressing (solving) small issues like that. It has been 2 years! And now, if I want the issue fixed, I will have to buy v2011. This seems to have been the upgrade policy with Trados over the last 4 years (since I began using it) - known issues are left unresolved with promises that the problem will be taken care of in the next paid version. This has been the case with Java for example.
SDL Support wrote:
4. When adding a new term from inside Studio, it will wrongly inform you that the term is already present in your termbase if it is present in any of the secondary termbases attached (and not present in your primary one)
I've played with this one a little and am getting confused about where the problem actually is, unless it's because of the one above where the termbase name does not show. If I have several termbases open and the term is in one of them I can see which one in the term recognition window and so know whether I need to add it to the default or not.
I imagine it starts to get a little messy when you have lots of terminology hits for that segment so I guess you are looking for something in the message that says the term is not in your default termbase rather than something telling you it is in one of your active termbases?
I will try to explain: sometimes a term is present in one of the secondary attached termbases (for example - from other clients). As I try to keep termbases separate (one per client) I still want to get the term in question in my current primary database (for this project and client). So I am trying to add said term. Unfortunately, Studio wrongly decides that the term is already present and asks me if I want to edit the term instead:
Now, I am almost sure that the term is not part of the primary database, but you can never be 100% sure and I do not want duplicate entries (another Studio shortcoming: you cannot delete a term from inside Studio, so if a duplicate entry is created, you have to open Multiterm, look for the duplicate term and only then delete it - which is a further waste of time I should be spending on the translation). So just to be on the safe side, I click on "Yes" (to edit the supposedly existing term). As it turns out said term is not part of the database and Studio has just wasted more of my time:
I am looking for "clinker", Studio says it is already there and offers me to edit "cleaning". Is "cleaning" identical to "clinker" in any way?
When this same little exercise happens a 100 times for a medium sized translation, this is a huge waste of time and effort.
SDL Support wrote:
5. You never know if your project will be set up successfully or not until the source files have been exported to translatable format. You never know if the translation will be finalized correctly.
I'm not sure 60% is an accurate figure for all users, but 2011 has improved on almost all of the filetypes, but one thing you could do is add a generate target translations task to the prepare project batch tasks and this will prove before you start whether the files will round trip or not.
To be honest, in my case probably 80% of Word files received from clients crash Studio. Then I have to come looking for help on this forum, or send an email to you directly (and thanks God, you are able to help in most cases), but that is not how a well-engineered software costing hundreds of EUR is supposed to work.
Kind regards,
[Edited at 2011-08-10 10:08 GMT]
| | | |
Heinrich Pesch wrote:
Of course I update Java all the time and Trados/SDLX never crash. I haven't yet used Studio yet, but I'm sure it works as it should. Last update for Java is from last week.
Do you use MultiTerm? I doubt it...
Regarding the other issues, I completely agree with Pavel. Studio is very good when it works, but it's not nearly reliable enough. I'm a pretty competent computer user, so I muddle through each project, but not without a persistent feeling of uneasiness. Studio crashes, MT hits going missing, MT termbase names going missing, erroneous "already exists in termbase" messages, target file generation failing... I don't think I've ever had a project without at least one minor hiccup.
[Edited at 2011-08-10 10:36 GMT]
| | | |
I keep getting the error "Value was either too large or too small for an Int32." (which I believe is related to .NET Frame) and I haven't been able to solve it. When I try and switch to files view, Studio just crashes and disappears. So I have to select a different project, go to files view and open the original project... I still get the error, but at least I can translate the files...
I'm running the latest version + Windows XP Home Edition, Service Pack 2
| | | | | On your points | Aug 10, 2011 |
Hi Pavel,
I'll need to go through the backlog and will come back to you on this one. I don't believe this is a widespread problem but this doesn't mean we have ignored it, so I will update you in due course.
Pavel Tsvetkov wrote:
4. When adding a new term from inside Studio, it will wrongly inform you that the term is already present in your termbase if it is present in any of the secondary termbases attached (and not present in your primary one)
ok, I understand where you are coming from and can also see some odd behaviour here. Part of the problem in resolving this I believe is the definition of a duplicate? As you know Multiterm can be a little more complex than just one word, so are we referring to the same source term? Same source and target? Same source, target and fields? The entry number? etc...
I think that for this exercise, as part of a term recognition task, it probably makes sense to base a duplicate on the source term alone and then provide appropriate options to deal with it. Would that be your thinking?
Regards
Paul
| | |
|
|
|
Nora Diaz
Mexico
Local time: 04:06
Member (2002)
English to Spanish
+ ...
| Regarding Multiterm refusing to add new terms... | Aug 10, 2011 |
I have seen the exact same thing Pavel is describing, as recently as yesterday.
The termbases in question in my case are very basic (just source+target). If a term exists in one of the reference termbases, Studio won't add it to the default termbase, saying it's already "in the Active termbase" and offering to edit it instead.
I do not want to edit the reference termbase, but rather add it to the Defaul one. I can do that by choosing No, but then, as Pavel explains, t... See more I have seen the exact same thing Pavel is describing, as recently as yesterday.
The termbases in question in my case are very basic (just source+target). If a term exists in one of the reference termbases, Studio won't add it to the default termbase, saying it's already "in the Active termbase" and offering to edit it instead.
I do not want to edit the reference termbase, but rather add it to the Defaul one. I can do that by choosing No, but then, as Pavel explains, that may lead to some duplicates.
I think a good way of solving this problem in this type of scenario would be:
- Base duplicates on source+target
- If the term is found, the message should indicate where, not just say "in the Active termbase", i.e., "term X is found in termbase Y"
- Then the options of the dialog box should be: Add term X to termbase Z (presumably the default termbase); Edit term X in termbase Y; or Cancel
That would make it a bit clearer to the user, I think.
[Edited at 2011-08-11 02:04 GMT] ▲ Collapse
| | | | Pavel Tsvetkov
Bulgaria
Local time: 14:06
Member (2008)
English to Bulgarian
+ ...
MODERATOR TOPIC STARTER | Adding to the conversation | Aug 11, 2011 |
SDL Support wrote:
ok, I understand where you are coming from and can also see some odd behaviour here. Part of the problem in resolving this I believe is the definition of a duplicate? As you know Multiterm can be a little more complex than just one word, so are we referring to the same source term? Same source and target? Same source, target and fields? The entry number? etc...
I think that for this exercise, as part of a term recognition task, it probably makes sense to base a duplicate on the source term alone and then provide appropriate options to deal with it. Would that be your thinking?
Regards
Paul
Duplicates are not the issue here - they are the undesirable side effect. All my termbases are created with the default definition and the termbases I am discussing have only the source and target fields completed. But, again, that is not the issue here. Studio treats only one of the termbases as an editable one to which a new term can be added, etc. and all of the others are for reference purposes only, so why is it reporting that a term is already present in the termbase eligible to receive new terms - if is present in one of the minor termbases not eligible to add terms anyway? That is very deceiving and can be defined only as a bug - and a time consuming one. Then - when it has to actually produce the "duplicate" for editing it looks in the correct termbase (for a change) and being unable to find a duplicate, produces a "look-alike" - a word starting with the same letter, etc.
I hope this is not a difficult idea to understand: I believe both the description of the bug and the screen captures above should make it quite clear.
Nora Diaz wrote:
I think a good way of solving this problem in this type of scenario would be:
- Base duplicates on source+target
- If the term is found, the message should indicate where, not just say "in the Active termbase", i.e., "term X is found in termbase Y"
- Then the options of the dialog box should be: Add term X to termbase Z (presumably the default termbase); Edit term X in termbase Y; or Cancel
That would make it a bit clearer to the user, I think.
Thank you for your comment. The thing is, as noted above, that Studio treats only one of the termbases as editable (receiving new entries from inside Studio) and the others - as reference only. So, if no other termbase can receive new entries, then why report a duplicate can be created with the term not present in the premium termbase in the first place - obviously with the way Studio is engineered right now, it simply cannot happen. So, unless secondary termbases are also made to accept new entries (future development), there is no need to specify where the term really exists - if it is in one of the secondary "non-editable" termbases.
But you are right that it would be much better for Studio to develop its basic functionality regarding term handling. Why shouldn't we be able to also delete terms from inside Studio - and in all termbases attached to the project? Why shouldn't we be able to access and edit terms in all termbases attached - from inside Studio? Is that too difficult to implement, or too far-fetched? Alas, changes happen slowly at SDL and software decisions are often implemented in a way that defy normal human logic.
Kind regards,
Pavel
[Edited at 2011-08-11 06:43 GMT]
| | | | | On your responses | Aug 11, 2011 |
Hi Pavel,
Studio treats only one of the termbases as an editable one to which a new term can be added, etc. and all of the others are for reference purposes only, so why is it reporting that a term is already present in the termbase eligible to receive new terms - if is present in one of the minor termbases not eligible to add terms anyway?
Because you might not always wish to add the term if you have it in one of your other termbases. MultiTerm is not just a simple glossary based database. It is used by many terminologists to provide extremely rich and detailed termbases that are used not only for helping with translation but also as a tool for helping authoring and generally being able to look up information about resources within your business.
So there is a valid usecase, as part of the control for terminology to use a well managed termbase containing tens of thousands of terms (or more), and only allow these to be changed within a controlled environment.
The ability to be able to add a term you think is missing ie. not found in any of the termbases you are using for lookup is important to help enrich the breadth of material for your users, but only as a basic term that will then be addressed in a seperate controlled workflow for approval and eventual inclusion into the lookup termbases. In this workflow the lookup TMs would not be minor... they just might not be yours.
This is just one usecase. But the point I am trying to make is that we fully acknowledge that the current interaction to MultiTerm within Studio does need a little work for these types of things, but it is not as straightforward as you suggest. Your point is understood Pavel, and we will address it.
Regards
Paul
| | | | | AutoSuggest Crashes | Aug 11, 2011 |
Hi Pavel,
Pavel wrote: 2. Autosuggest crashes Studio http://tinyurl.com/43417-ASD What bothers me is that: (1) There is no solution of the problem, (2) It seems that SDL is not even aware of the problem even if customers are under the impression that SDL is hard at work solving it. I hope some clarification can be provided.
This one appears to have been resolved in Studio 2011. To make sure I don't forget if we need to come back to it the Bug number was #43417 and the thread posted was actually referred to in the development database.
Regards
Paul
| | |
|
|
|
Roy OConnor (X)
Local time: 13:06
German to English
| Workaround for adding terms to primary termbase | Aug 11, 2011 |
Here is a relatively quick workaround for adding terms to the first (default) termbase.
If Studio reports that the term is already present even though it is not present in the primary termbase, first cancel and then remark the source term say with the last letter unmarked. Then try again with this nonsense source term and just add the missing letter in the edit term box before confirming.
It's extra work, but not that much. And it saves some frayed nerves...
| | | | Pavel Tsvetkov
Bulgaria
Local time: 14:06
Member (2008)
English to Bulgarian
+ ...
MODERATOR TOPIC STARTER
Dear Paul,
First of all let me say that I am very happy that SDL did recognize the need to monitor and comment on this forum some time ago, and the person assigned this difficult task is none other than you - a patient and knowledgeable professional, who is able to address issues quickly and in most cases - provide a solution.
I do not have an argument with you - but as a customer I am not satisfied with the product design, development, update/upgrade policies and respo... See more Dear Paul,
First of all let me say that I am very happy that SDL did recognize the need to monitor and comment on this forum some time ago, and the person assigned this difficult task is none other than you - a patient and knowledgeable professional, who is able to address issues quickly and in most cases - provide a solution.
I do not have an argument with you - but as a customer I am not satisfied with the product design, development, update/upgrade policies and response times when addressing issues - on the SDL side.
Hopefully, through threads as this one such issues will be better identified by SDL, recognized as bugs / ideas for future implementation, and finally taken care of within the lifespan of purchased - not future - products.
SDL Support wrote:
Because you might not always wish to add the term if you have it in one of your other termbases. MultiTerm is not just a simple glossary based database. It is used by many terminologists to provide extremely rich and detailed termbases that are used not only for helping with translation but also as a tool for helping authoring and generally being able to look up information about resources within your business.
I understand that there may be other uses of Multiterm and Studio, as well as more complex scenarios, but I am also sure that most purchasers of the freelance version of Studio use it for translation purposes to help with their freelance business tasks. Therefore the default behavior of Studio when adding new terms should not be the one adopted now. It simply does not work for freelancers like me and whoever wants to create complex termbases can probably do so from Multiterm (not Studio) as Studio offers very limited functionality in this respect anyway. The dialogue informing me that the term is present in the primary termbase while it is not, should be edited or dropped and the behavior of Studio there should be changed.
SDL Support wrote:
2. Autosuggest crashes Studio
This one appears to have been resolved in Studio 2011. To make sure I don't forget if we need to come back to it the Bug number was #43417 and the thread posted was actually referred to in the development database.
I am looking forward to v2011 - it looks like all my gripes with v2009 will be solved then. The thing is, as noted above, that as a buyer of v2009 I have not made a promise to also buy all you future versions as part of some eternal hunt for a bug-free Trados. SDL sold me v2009 and it is supposed to work well and do what it is supposed to do error-free - and if bugs are nevertheless identified, those should be dealt with swiftly and resolved for the current version, not future ones. What happens to your customers who elect not to pay you the upgrade amount - will SDL never fix said problems for v2009 and let it customers use a buggy software, knowing full well that it affects their productivity and even threatens to destroy their work on a current project? Software deficiencies should be addressed and fixed for current versions and not used as a selling point for future versions (which, unfortunately, SDL seems to implicitly do).
Roy OConnor:
Here is a relatively quick workaround for adding terms to the first (default) termbase.
If Studio reports that the term is already present even though it is not present in the primary termbase, first cancel and then remark the source term say with the last letter unmarked. Then try again with this nonsense source term and just add the missing letter in the edit term box before confirming.
It's extra work, but not that much. And it saves some frayed nerves...
Thank you for your input, Roy - your help is appreciated! I am aware of this shortcut and have developed my own bag of tricks over the years to try and make up for Studio-Multiterm term management deficiencies. But, as you say, those are time-consuming and ultimately ineffective substitutes for features that should be present in the software, not created by users.
As the saying goes: "If you don't understand what the conversation is about, it is probably about money." The truth is that SDL want to sell two products: Studio and Multiterm, and not just one, integrated and fully functional product. It is a question of getting the extra buck, if one is willing to get to the bottom of it. There can be no other explanation as to why Studio is so ineffective in term management on its own - and so poorly integrates Multiterm, a product of the same company. Why do I have to start Multiterm separately to be able to delete a term? Why am I not allowed to also edit terms from the "secondary" termbases, attached to the project, from inside Studio? Why are termbases not created and managed from within Studio?
Kind regards,
Pavel ▲ Collapse
| | | |
SDL has no idea what it could be causing the NET Frame error? Well, I look forward to Studio 2011 too...
| | | | | Pages in topic: [1 2 3 4 5 6] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Studio 2009 bugs that were never fixed | 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 » |
| | 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
