SDL Studio 2014 SP2 Review; or Farewell Java, it has been a roller coaster ride

Studio 2014 SP2 was officially released on November 18, 2014. The official version includes some additional bug fixes compared to the Beta version I reviewed, but not new features were added or removed.

During the typical life-cycle of any major Studio version there are two types of updates:

  1. Cumulative update: A scheduled release of hotfixes to address customer impacting bugs, as well as critical performance and/or security issues.
  2. Service Pack (SP): A collection of updates and fixes that improves the overall stability of the software, and usually introduces some new features, or enhance the functionality of existing features.

SDL was kind enough to give me access to the Beta version of the upcoming SDL Studio (and MultiTerm) 2014 Service Pack 2 (SP2), scheduled for release as a free upgrade for all current Studio 2014 users at the end of November 2014.
I have been testing the Beta version for about two weeks now, and decided to briefly go over the primary changes and give my general impression so far for the benefit of those who might be interested to know what is coming.

Enhanced Terminology Editing

The most noticeable change introduced by Studio 2014 SP2 is the long awaited departure from Java, and with the two new terminology editing commands: Quick Add New Term and Delete this Entry, this results in major overhaul to the terminology management workflow and performance.

The Removal of Java

Starting with Studio 2014 SP2, Studio and MultiTerm Desktop are no longer depend on Java. The dependency on Java was arguably the main pain point for many users, and its removal should significantly improve the overall user experience. The new Java-less Studio together with the Open eXchange Glossary Converter app simplify what was only recently a dreaded terminology management workflow almost beyond recognition.

The new Quick Add New Term option

In the traditional workflow users had to click the Add New Term button, edit the terms in the Termbase Viewer window as appropriate, and then click the Save Entry button. Even without the slowness and instability issues of Java, this multistep process is a bit cumbersome and prone to human errors (does forgetting to click the Save Entry button sound familiar to anyone?), especially when working with basic glossaries that contain only the Source and Target terms without any additional fields.
The introduction of the new Quick Add New Term option in Studio 2014 SP2 greatly simplifies this workflow and adding terms to the active Termbase on-the-fly was never easier.

Note: Users that use termbases with additional fields (such as definition or context) and want to edit these fields before saving the term in the termbase should continue using the traditional Add New Term workflow.

Deleting a Termbase entry from within the Editor window

The second enhancement to the terminology editing workflow is the addition of the Delete this Entry button to the Termbase Viewer window, for quickly deleting a Termbase entry without leaving Studio’s Editor window. A nice time saver.

Tag Verifier is now a global setting

Traditionally, the Tag Verification settings in Studio was tied to each supported filetype. Studio 2014 SP2 replaces the old filetype-specific settings with a new global tag verification settings (under File > Options > Verification > Tag Verifier).
Although it doesn’t seem like much in a first glance, I think that this is an important change that will minimize confusion and human errors.

Sorting Translation Memory (TM) Results by date

Judging by the number of times I was asked if this is possible, this new feature of Studio 2014 SP2 should be greatly appreciated by many users.

The new Show most recent translation first option sorts TM results by Match percentage > Last edited date > Last added date, thus giving the user a finer control over how the TM and concordance search results are displayed.
This is the new default setting (accurate to the time of this writing), but users that prefer the old behavior can easily switch back by going to Project Settings > Options > Language Pairs > [Relevant language pair] > Translation Memory and Automated Translation > Search and dis-selecting the first checkbox: Show most recent translation first.

Source segment editing for more supported filetypes

The source segment editing feature, first introduced in Studio 2011 SP2, could come real handy at times. It is a simple way to clean up that odd messy source segment, correct a typo, and so forth without leaving the Editor window. It also became a way to work around Studio 2014 segment merging limitations as a crude ad-hoc mechanism for making simple segment merging in poorly prepared documents.

However, source segment editing has some limitations:

  • Available only for Microsoft Office documents (Word, Excel, PowerPoint);
  • Disabled for locked segments;
  • Disabled for project packages, unless the package creator chose otherwise;
  • Disabled for documents with tracked Changes.

Starting in Studio 2014 SP2 source segment editing is available for most supported filetypes, but the other limitations in the above list remain unchanged.

Alphanumeric characters now added to the list of recognized tokens (placeholders)

This is quite significant. Studio 2014 SP2 now recognizes a combination of alphanumeric and the following characters as tokens (i.e. placeholders that are transferred directly to the target segments):

  • Uppercase letters (VGN-FW550F)
  • Numbers (M10X30)
  • Underscores (NAME_4001C)
  • Dashes (VGN-FW550F)
  • Full stops (BV0.mxm.072.531)

Activate this new option under File > Options > Language Pairs > Translation Memory and Automated Translation > Auto-substitutions, and then reindex all relevant existing TMs, otherwise the change will not apply to them and only to newly created TMs.

I tested this and it seems to work well (but don’t forget to reindex existing TMs).

Changes to the word count mechanism and search logic when handling words containing apostrophes, dashes and full stops

As SDL describes this change:

Studio 2014 SP2 uses an improved algorithm for processing words that contain dashes (-) or apostrophes (‘). This improvement translates into:
Lower word count. Studio no longer treats apostrophes and dashes as word separators, but as punctuation marks that link words together. This means that Studio counts elements like “it’s” or “splash-proof”, “NAME_4001C” as one single word.
Apostrophes that do not follow the new logic:

  • Apostrophes followed or preceded by space. For example, “the ‘90s” or “girls’ night” both contain two words.
  • Right single quotation mark (’)

Dashes that do not follow the new logic:

  • Figure dash (‒)
  • En dash (–)
  • Em dash (—)
  • Horizontal bar (―)
  • Small Em dash (﹘)
    Higher fuzzy matches. When searching for matches in the selected TMs, Studio considers apostrophes and dashes as separate tokens inside the words they link together. This means that when comparing words where the only difference is the type of dash or apostrophe used, Studio only penalizes the difference in punctuation and not the entire word.
    Important: Re-index your existing TMs before using them in Studio 2014 SP2. This synchronizes the TMs with the new logic for counting and matching words that contain apostrophes and dashes.
    These options are available on the Translation Memory view > Home tab > Import > General Import Options page.

Personally, I don’t understand the logic behind this change. A cynic might say that the lower word count and higher match percentages could benefit some more than others, but I will reserve my judgment until I’ll clarify this with SDL.

Some additional notable changes

  • A text replacement penalty is now applied to acronyms and alphanumeric placeholders. When activated, a replacement penalty could be assigned to acronyms and alphanumeric placeholders to indicate that they were transferred directly from the source segments (i.e. they match the token identification logic) and not from the active TM(s).
  • Support for the newer Adobe InDesign/InCopy CC file formats.
  • SDLXLIFF files are now always included in the return package.
  • Many more updates and bug fixes to existing features and core components that are transparent to the user but should improve stability.

Conclusion

The highlight of Studio 2014 SP2 is without a doubt the departure of Java, a major friction and frustration point throughout SDL Studio’s history. In my opinion, less dependency on external libraries is always better than being susceptible to changes made by a third-party, even if the trade-off is losing some (peripheral) functionality.

The new terminology module should significantly improve the user experience, and from my experience so far it does just that, indeed. With the addition of the Quick Add New Term option, adding new terms on-the-fly is faster, simpler and more reliable than ever before.

The other new features and improvements are generally a step forward, although their importance and impact differ depending on the workflow and use case. The only exception might be the change to the wordcount algorithm. I will attempt to get a clarification about this, but in the meantime just be aware of that.

So far Studio 2014 SP2 seems to be very stable. As can be expected from software still in Beta, there are also some bugs and quirks, but this is part of the Beta experience and I appreciate it. The most pressing bugs are likely to get fixed by the time Studio 2014 SP2 is officially released, but other bugs might be addressed only in future Cumulative Updates (CUs), which SDL tends to issue on quite a timely manner

I haven’t encountered any "showstopping" bugs or issues even in this Beta stage, so for those who tend to be early adopters I can recommend with a degree of confidence that it is generally safe to upgrade to Studio 2014 SP2 when it is released. That said, I also acknowledge that what seem to one as a minor bug could be significant another, and therefore would recommend those with a more conservative approach to upgrading to wait a few weeks — probably until the release of the first CU — before upgrading to Studio 2014 SP2.

My review and impression of memoQ 2014

Readers of this blog and those who might have stumbled upon some of my occasional posts on the subject in social media know that translation supporting technology and workflows are areas I take a special interest in. I’m always grateful for opportunities to learn about new and different approaches and tools.

In recent years memoQ has gradually risen to be one of the major commercial TEnTs (Translation Environment Tools) available on the market. Previously I only had very brief and superficial experience with older versions of memoQ, so when memoQ 2014 was released on June 2014, I was excited to take the opportunity and test it for a few months as my main production environment.

Being a relatively experienced user of Studio 2014, my original plan was to point out the similarities and differences in features and approach between the two TEnTs, but Emma Goldsmith had a similar idea and compiled an exhaustive side-by-side comparison of memoQ 2014 and SDL Trados 2014, doing a much better job than I ever could. Her comparison is a compulsory reading for anyone interested to learn about the similarities and differences between memoQ 2014 and SDL Studio 2014.

Instead, I decided to do a more general review of memoQ, starting with some of the major new features in memoQ 2014, continuing with some general features and approaches I like in memoQ, and concluding with my brief impression of memoQ 2014 after about three months of using it as my main production environment.

Note and Clarification

memoQ, SDL Studio, and most other TEnTs share the same basic concepts and workflow, which will not be covered in this post. I’m also not trying to determine whether memoQ is better or not compared to SDL Studio or any other TEnT, not least because I don’t believe in such a universal determination. The definition of ‘better’ always depends on personal preference, needs, and circumstances.

Continue reading

What can we Learn from Facebook’s Emotional Contagion Experiment?

Can emotional states be manipulated just by the use of emotion-evoking communication? This was the question that Facebook set to answer in a study that was published in the March 2014 issue of Proceedings of the National Academy of Sciences (PNAS) and erupted quite a controversy. The paper, named "Experimental evidence of massive-scale emotional contagion through social networks" (PDF file) describes a psychological experiment that Facebook had conducted during one week in January 2012 among 689,003 of its users to test how the amount of negative or positive content to which the users are exposed to affects their emotional state (i.e. mood), and their resulting behavior on Facebook.

In this blog article I don’t intend to discuss the controversy surrounding this research (here is the official reply of one of the researches to the controversy). This is and important topic that deserves discussion, but it outside the scope of this particular article.

Instead, I want to examine the results from a professional translation practitioner’s angle and suggest two lessons that I think we can learn from the study about the role of language in effective communication and social atmosphere setting.

Continue reading

The Glossary Addons: (almost) The Missing Terminology Link

One of the major complaints of many SDL Studio users is the lack of a "simple" terminology management module. MultiTerm, Studio’s terminology management environment, is a full-fledged terminology management module, but not everyone needs all the functionality it offers and some would have preferred a more simple and straightforward workflow that better suits their more modest terminology management needs.

Furthermore, MultiTerm’s traditional workflow can be a little daunting at first. Creating, importing, or exporting a termbase (the file storing all the terminology information) are not necessarily as most intuitive and straightforward as some would have preferred. And if that wasn’t enough, while Studio’s Editor environment enables the user to add and edit terms in a termbase that was added to a project, the termbase itself must first be created in MultiTerm, which is and external software package to SDL Studio. This adds another layer of confusion about how SDL Studio and MultiTerm interact with one another.

In this article I want to discuss how two Studio 2014 Open Exchange apps (for accuracy, one of them is a actually a plugin) simplify the terminology preparation and exchange workflows, and why I think their significance to the Studio ecosystem is larger than the sum of their parts.

Continue reading

TEnTs Interoperability (or how to setup a WordFast or MemoQ Project in Studio 2014)

Interoperability is a topic I took a special interest in since starting to use Translation Environment Tools (TEnTs). Most TEnTs store the data in proprietary file formats and that makes it that much harder to share or migrate information. One unfortunate results of this difficulty is the enablement of some unethical practices, and even more importantly, the creation of the feeling among users that they are held “captive” by the propriety formats and forced to use a certain tool over another regardless of their workflow needs or preferences, unless they are willing to spend time and effort applying workarounds that are almost never guaranteed to work, or worse, invest money in tools just for using their filters in the pre-processing stage. This resonates hard with me because I’m strongly against what I believe is a harmful, damaging, misleading, delusional, and near-sighted infatuation with technology that puts the technology before the human professional. I believe that the human professional is the most important element in any professional activity and that the technology is just there to help the professional as a tool. Therefore, the professional must be able to choose his or her tools by merit, experience, and expertise with as little as possible artificial obstacles influencing the decision.

In recent years quite a few advancements have been made in terms of TEnTs interoperability. It was probably promoted by the increased range of available TEnTs in the market and the emphasize that some developers have put into better standards supports and interoperability from the get go. Nowadays most modern Translation Environment Tools can exchange information via standardized file formats – primarily XLIFF (for bilingual files) and TMX (for exchanging Translation Memory information) – and some of them even offer native or extendable (via add-ons) support for reading and writing proprietary formats of other TEnTs.

In that regard it is worth noting that contrary to common belief, irritating as they sometimes are, proprietary file formats are not used just to restrict users; they allow the developers to extended the functionality of the standard file formats and add features that users need, rely on, and come to expect.
It is not the ideal situation, and there is still a long way to go in terms of improved (dare I say complete?) interoperability, but we have come a long way since just even 5 years ago.

For example, MemoQ can natively handle Studio SDLXLIFF and SDLPPX (Studio Package file format), as well as WordFast Professional TXML files; OmegaT through the Okapi Filters Plug-in can be extended to support additional file types; SDL Studio file support can be extended by installing additional File Type Definitions from the Open Exchange platform; and other TEnTs such as Fluency and Déjà Vu also offer some degree of interoperability, but I don’t have enough experience with them to comment in detail. Since XML has become the de-facto format for storing and exchanging information, the modern TEnTs can create customized XML file definitions to parse virtually any XML-based file, even when no native or extendable interoperability exist. And to complement this improved interoperability and extendability, the information can also be exchanged via the standardized file formats.
The interoperability is not flawless, and exchanging information still not always as smooth as it should be, but we have come a long way, indeed.

A couple of days ago I helped a colleague setup a WordFast project in Studio 2014 and thought to share the experience as a short case study that highlights the process and the basic approach. This process can be used to add support for MemoQ MQXLIFF files, as well as any other file type available through the SDL Open Exchange platform.

Continue reading