Thank you for your reply, Paul.

as usual, complete and exhaustive. Your explanation about licensing and default settings activation has explained my doubts.

Regards,

Claudio

Good morning Paul,

First of all, let me once again thank you for your incessant patience, not only with me but with everybody else who asks clever or not-so-clever questions on the Community Forum.

It is probably best to first explain where I am coming from. On 24 July, Jerzy Czopik responded to somebody and stated that, in his personal opinion, only 0.0001 % of translators will pay attention to proper segmentation. I wrote to him as follows:

Sorry to bother you, but I am writing to you about your response to Stepan Konev, less than an hour ago. I did not think it to be right to respond on the community forum.

Granted, you write that it is your personal experience that only 0.0001 % of translators will pay attention to proper segmentation. Are you sure about that percentage, though? For the life of me, I cannot believe it. Are you and I the only ones, then?

In my personal experience, it pays to do thorough pre-editing of files to be translated. Many authors of documents do not seem to know Word very well. It means that I remove excess spaces, remove paragraph endings where they do not belong and convert tabbed entries to tables. I add full stops where they are missing, so that the next sentence will not start in the same segment and I ensure that outlines are properly applied or, if they do not exist, I introduce them, so that I do not run the risk of TOC entries differing from the actual chapter headings and have no chapter numbers and paragraph numbers in the sentences to be translated.

Additionally, because 70 % of my source text is German, I restructure sentences a bit by bringing a verb trailing after an enumeration to the introducing sentence, except when the target is Dutch, because then the trailing verb is rarely a problem. You referred to this yourself, in your recent seminar.

The result is that I hardly ever have any post-editing to do. At worst, I may have to play with spacing here and there, to keep the pagination right. So, the extra time that I spend up front, I get back afterwards. But, and this is important, I end up with very clean entries in my TM and benefit greatly with subsequent, even unrelated, jobs. It has happened that 70 – 80 % of files ended up with 100 % matches or even perfect matches. It has happened with AGBs and with tenders.

The disadvantage is that files in packages can be a problem. I resolved that by simply not accepting packages. But when I get an SDLXLIFF as input, I can extract the source and still do my pre-editing.

I hardly ever get any complaints from customers.

Thank you for your always very helpful responses and comments.

In his response, he increased the percentage to “1% or 2%, but really not more”, and complemented me.

With regard to my remark about receiving an SDLXLIFF, there is an exception. Right now I am working on an SDLXLIFF that was made from an IDML file. Since I don’t have InDesign, because it is prohibitively expensive for most freelance translators, I could not do much about automating the chapter and paragraph numbering. So, I am keeping the translated segments far from my main TM, so as not to contaminate it.

Now, having explained my way of working to you, I only need the ability to create and use file-based translation memories, perhaps by using AnyTM. All the remaining functionality is totally superfluous for me. WorldServer Components are also not needed, I think. About two months ago, I actually uninstalled the WorldServer Components through the Programme Manager (or whatever it is called these days) and did not experience any adverse effects. However, SR1 reinstalled them. And I don’t think that I need the Legacy Compatibility Module. I have not un installed it, but I only use the most recent file formats for input. If I do receive an RTF or DOC or something like that, I first convert it with the relevant Office product to the latest format, before doing anything else. I only keep a copy of the original for the purpose of exactly mimicking the original lay-out. Which brings me to another point.

When installing MultiTerm, I get the chance of selecting the components that I want to have installed and where they should be installed. When installing Studio, no such chance is offered. As a habit, I install 64 bits programmes on the C drive and 32 bits programmes on the D drive. Even though I have plenty of disk space, I do so to balance out disk utilisation. 32 bits programmes tend to be more bulky than 64 bits programmes.

I do not see the need for logging on from within Studio. There is automatic checking for updates anyway and if I get a notification of a new service release, I use my browser to go and get it.

So, to summarise, I think I can do without:

• WorldServer Components

• Legacy Compatibility Module

• Server-based translation memory

• SDL BeGlobal enterprise

• Google Cloud Translation API

• AnyTM: any server-based translation memory

• Log-on facility

If the names are slightly off, it is because I am reading them in German.

This could be easily achieved by allowing to select which components I want to have installed during setup. So, the setup package as such would not need much changing (I think; I am not a developer).

With regard to new functionality, I don’t have so much of a problem. A lot of it is indeed not needed by me, but I find out about that in the webinar that always follows new releases and updates. I am looking forward to next week’s webinar on upLIFT.

A minor point. More one of beauty than of usability. I have a setup with four monitors. I use monitor 2 for Studio, monitor 3 for my browser, monitor 4 for Outlook and monitor 1 for sundry windows. The functions I use most are terminology recognition and ‘search in the active file’. I have their respective windows permanently displayed on monitor 1. However, I never get to see them first time off after starting Studio. I must minimise Studio and maximise Studio again, before they appear.

Finally, I hope you do not mind me mentioning one major peeve about the setup procedure (in addition to not being able to select the D drive): already during DOS days I learnt the hard way that it is insane to keep any user files on the C drive. Upon reinstalling the operating system, whether the various versions of DOS (PCDOS, DRDOS, MSDOS) or the early versions of Windows (my first one was Windows 3.1), anything on the C drive would be irretrievably lost. I suppose that is why backup software came to be promoted so rigorously. Anyway, I believe in both back up daily and in not storing any user files on the C drive. Since the past several years, Microsoft offers the possibility of relocating the default folders for documents, images, downloads and some others. I do that and relocate the documents folder to the D drive and it will automatically be correctly pointed to in the registry. However, Studio does, apparently not read what the default locations are and creates another documents folder on the C drive. The logic of that escapes me.

Further background: I finished my professional career in international banking (foreign exchange and money markets) in 2007, after 43 years. I started translating in 2009, in order to have something to do. I experimented with various bits of software, bot free (OmegaT, Anaphraseus, Across) and non-free (Alchemy, Swordfish, memoQ, Déjà Vu and a couple more), but for more than five years now, I exclusively use Studio. I refuse jobs, where I cannot use Studio or no CAT at all.

I did also once experiment with BeGlobal or one such service. But the costs rose too fast. That is because I quite often reimport the source, after making some structural changes, which then causes the entire file to be (quite unnecessarily) reanalysed.

Feel free to ask any further questions. And tell me, if you want me to put some of this response on the forum, please. [Posted at Paul's request.]

Another minor beauty point: the icon on the task bar is empty. It does not display the Studio logo, like before.

Best regards,

Just chiming in to say that, on the contrary, I like that there are many functions and options within SDL Studio itself. Many others can be added through the installation of 3rd party plug-ins, but I don't like relying on those as I don't know for how long they will be supported, or if in case of issue a fix will be released, and also because they may be paid plugins on top of Studio's price tag.

Each on of us has his/her unique translation needs and it's hard to have a translation tool 'one size fits all'. Also, I like that Studio differentiates itself from the growing crowd of basic, unrefined, and limited-function CAT tools which are growing in popularity among translation agencies and newbies because of their cheaper cost (they are usually cloud CATs). They are a pain to work with and lack of the professional features that pro translators use. I consider them as 'enablers' for newbies who don't have the experience or don't want to make any financial investment in translation as it is not yet their profession.

Studio, instead, has been implementing a strategy in the opposite direction: a refined, and thus complex, CAT tool for professionals who would like to work better, with less effort (autosuggest, uplift, termbases) and better quality (QA, auto-substitution).

If you want a simpler and leaner software, then Wordfast would be a good option. Give it a try and you'll appreciate Studio as it is :D

Thanks for posting your thoughts Willem Dubelaar 

On these points:

Unknown said:

So, to summarise, I think I can do without:

• WorldServer Components

• Legacy Compatibility Module

• Server-based translation memory

• SDL BeGlobal enterprise

• Google Cloud Translation API

• AnyTM: any server-based translation memory

• Log-on facility

When I look at these I can't help wondering how omitting them would actually make the product "cleaner"?  They are all pretty much unseen and none of them apart from the login name clutter up the user interface.  So I really don't understand how this would be worth creating another edition of Studio.

And the login name... well this is part of the work we are doing in preparation for further enhancements that will make it possible for users to a lot more things in the future with cloud solutions, the appstore etc.

Unknown said:

Another minor beauty point: the icon on the task bar is empty. It does not display the Studio logo, like before.

Don't you see this?

Thanks for posting your thoughts Willem Dubelaar 

On these points:

Unknown said:

So, to summarise, I think I can do without:

• WorldServer Components

• Legacy Compatibility Module

• Server-based translation memory

• SDL BeGlobal enterprise

• Google Cloud Translation API

• AnyTM: any server-based translation memory

• Log-on facility

When I look at these I can't help wondering how omitting them would actually make the product "cleaner"?  They are all pretty much unseen and none of them apart from the login name clutter up the user interface.  So I really don't understand how this would be worth creating another edition of Studio.

And the login name... well this is part of the work we are doing in preparation for further enhancements that will make it possible for users to a lot more things in the future with cloud solutions, the appstore etc.

Unknown said:

Another minor beauty point: the icon on the task bar is empty. It does not display the Studio logo, like before.

Don't you see this?

Unknown said:

And the login name... well this is part of the work we are doing in preparation for further enhancements that will make it possible for users to a lot more things in the future with cloud solutions, the appstore etc.

How exactly is this going to work with LSPs where the account used to buy/manage dozens of licenses is 'owned' by some manager and the actual workers (i.e. engineers actually using Studio) have no access - and never ever get access - to the account login?

Unknown said:

How exactly is this going to work with LSPs where the account used to buy/manage dozens of licenses is 'owned' by some manager and the actual workers (i.e. engineers actually using Studio) have no access - and never ever get access - to the account login?

It's never going to be a single solution for everyone Evzen.  But that doesn't mean we should not try to support the vast majority of users who do have their own account.  You do raise a good point though and even now it's an area some companies struggle with just being able to roll out apps from the appstore.

One solution we have been looking at is to make private appstores.  So a company with admins who control the installation of the products would have their own internal store where their translators/engineers could take the approved apps without having to own their own licensed copy of Studio.

So still things we are thinking about, and you do raise a valid point.  If you have a better idea of how to control this we're all ears as it is a conundrum and what works for one company doesn't work for another.

Unknown said:

One solution we have been looking at is to make private appstores.  So a company with admins who control the installation of the products would have their own internal store where their translators/engineers could take the approved apps without having to own their own licensed copy of Studio.

Bad idea. Admins have absolutely NO knowledge of CAT tools, therefore they are completely WRONG people to do this.

Unknown said:

Bad idea. Admins have absolutely NO knowledge of CAT tools, therefore they are completely WRONG people to do this.

Well, we don't choose who the admins are!

Unknown said:

So my suggestion is - stop wasting resources and money by this hopeless fight (people not willing to pay for software will NEVER pay for it anyway, and will ALWAYS find their way) and better focus on making the software actually useful... and also more affordable.

Thanks Evzen, we'll definitely take your wisdom on board.

Unknown said:

Well, we don't choose who the admins are!

Neither do we engineers. That's why we need solution which is actually useful IN REAL LIFE.
And as I said, the solution is easy - stop pointlessly overcomplicating things and follow the KISS principle.

Good morning Paul,

Indeed, I do not see that icon. It appears briefly as the programme is starting up, but when it is running, I do not see it any more. It turns white. It is the bottom icon on the attached image.

With regard to some of the reactions: the proposal was not for one configuration for everyone, but rather for letting everybody choose what he or she actually needs. As explained, my situation is that I work purely locally. Where on-line connections are not absolutely necessary, they should be avoided.

I believe the point is not whether a functionality is 'seen' or not, but that the fewer background processes there are, the better a system will run and the less chance for unwanted interactions, leading to undesirable results.

The suggestion I saw that somebody, who does not make full use of all the functionality, should opt for different software, is plainly ridiculous. Personally, I do not like salt. Should I therefore refrain from eating potatoes?

Best regards,