There's always a language pair, a source and a target, when it comes to "translation." And a language consists of the language and where it's spoken, which might be referred to as its locale. For example, consider English spoken in the US versus English spoken in the UK. Though this is something I was already aware of, I'm losing count of the number of times this point is missed or assumed when talking about an application, integration, or translation request.
So rather than "Spanish translation," it's more accurate to say, "translation from English for the US to Spanish for the US, as well." Because it could be a different English or perhaps Spanish for Spain, Spanish for Latin America, or Spanish for Mexico.
Why does it matter? Costs, translation memory leverage (which deserves its own post), system integrations, and the actual linguists you need all rely on the source and target language.
Regardless of the software, and especially for enterprise software, it's almost impossible for anyone to know all the features and capabilities of the system. First of all, a given implementation is exactly that—an implementation—of a system, configured and possibly customized to the customer's need on that particular version.
There's a difference between working with the same setup for several years versus time spend across different versions and implementations. I quite enjoy being able to share the tips, tricks, features, and capabilities for the software I'm most familiar with. For example, I've been able to recently highlight the Custom URL feature in Tridion Sites that lets you link the description of a content field to some documentation or customized GUI pop-up. For those familiar with Tridion Sites, I'm sure you have similar stories with the BluePrint viewer, (advanced) search, or the checked-out item list. Or maybe you know it all, already? :-)
Now I've also had to pleasure to learn from my colleagues and latest projects. And beyond the features and capabilities of our on-premise platforms, I'm also finding it impressive at how quickly our cloud platforms, especially Trados Enterprise (powered by RWS Language Cloud) can improve, with multiple, regular updates and enhancements to the product system. Look, ma, no hotfixes!
Yet Another "Multi..."
In the enterprise content management space, especially with Tridion Sites, you might have heard us mention "Multi, multi, multi," which refers to some ordering of multi-lingual, multi-regional, multi-channel, and maybe multi-market (or maybe not). With content and especially language technology, you can also have the internal equivalent with multi-vendor setups.
Really, going global means solving local problems and challenges, which can include large-to-smaller LSPs helping you scale, meet deadlines, and cover all the language (pairs, people!) needed.
On my first language technology project last year, I was quickly setting up the translation resources for a large multi-national organization. It was new yet familiar in ways. But a key and fascinating point was the fact that the visibility and access of information needs to be distinctly separate, especially for a multi-vendor setup. This is where an organization will have multiple language service providers (LSPs) to translate content from and to various languages, perhaps around the World.
When working on a multi-vendor setup, it is critical to keep vendor-specific information confidential, especially since the processes and costs are specific to the source and target language and vendor. You'll see this built into translation management technology, where visibility of translation resources is given to items lower and nested in the organizational hierarchy, but not to higher items, which is similar to scope for developers or BluePrinting for Tridionauts.
These are new, or perhaps old, lessons in new contexts. I have lots more to learn and share across content and language technologies. Oddly, I also need to learn what you're interested in. What would you like to know about? Got anything new to share from your latest projects?