• State Suggested Answer
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 434 subscribers
  • Views 11659 views
  • Users 0 members are here
Options
Related

How do clients "start" translation and other questions from a Web Content Management perspective

Alvin Reyes

I'm coming from an SDL Tridion perspective. suggested I could ask about how SDL clients choose their source and target translation language (pairs).

In SDL Tridion (Web Content Management), our settings are fairly straight-forward and include settings for TMS or WorldServer for where Translation Manager, the connector between Tridion and translation management systems, sends/receives translations to be stored in Tridion items (technically XML that we call Components).

But usually the languages and regions/countries are already chosen (e.g. English for the US as a source with maybe Spanish for the US as an initial target) when it comes time to Tridion configuration. I'm interested in learning about what's practical or common so I can recognize patterns and gotchas when say a US client says they want to "add translation" to their sites.

So some questions I have are:

  1. Where do clients start? Do clients typically know how they're going to handle translation (and market localization)? Do they seek out help from vendors or consultants? Seeing customer examples, I've learned it's not just English, but English for a given country. In addition, customers need to keep in mind everything from localizing a message to a given market or region, as well as handling jargon and product-specific terms (Barbie's expression "Cra Cra" comes to mind).

  2. Is "translation" (sometimes/often) a company-wide project? I see translation from the Web side (specifically with SDL Tridion where target content is sent/saved from XML, but "templated" into appropriate website markup), but noticed at least one customers that wanted to somehow combine their offline, product information translation process with their Web content translation. At least from the Web Content Management side, the internal users select items to translate and based on the (Tridion) "BluePrinting" settings, the translations are sent and come back after being translated into the correct websites.

    Is translation something companies handle from a company-wide perspective? I'd suspect "translation projects" might start in separate silos in business, at least based on how I see content handled (separate systems handle internal content, Web content, documentation, etc.). I'd guess there's some history involved where translation for product manuals and printed materials, for example, have a much longer history than the Web?

  3. SDL software ecosystem? Maybe I should also start with a fairly newbie technical question: are SDL WorldServer or SDL TMS related to the SDL Open Exchange? Or if so, how are these related? I understand "what is this" type questions can be very open-ended--links to resources or documentation are also appreciated. Maybe related to this is where and how SDL software is used. For example, SDL Tridion is used by large corporations to manage their websites with dozens to hundreds of internal system users.

Any feedback, leads, or even questions on the Web Content Management (Tridion) side appreciated. As a Web Content Management "professional" I'm not looking to understand everything, but I do want to be a little more familiar with what SDL clients face when they start "translation" projects.
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
  • 0

    Unknown said:
    SDL software ecosystem? Maybe I should also start with a fairly newbie technical question: are SDL WorldServer or SDL TMS related to the SDL Open Exchange? Or if so, how are these related?

    Hi Alvin,

    It seems you've asked a few tricky questions, so I thought I'd answer the third one at least, The first two are really better answered from people with experience working with organisations at that level.

    The SDL OpenExchange is part of the overall SDL Language Platform.  It essentially comprises two parts:

    1. it gives access to the APIs and SDK to allow developers to integrate their own products and processes with the SDL products, and
    2. it provides a platform for developers to share their solutions (if they wish) with users of SDL products, for free or at a cost

    At the moment the solutions on the OpenExchange available for sharing are predominantly solutions for the Translation Productivity users.  So this would be SDL Trados Studio, SDL MultiTerm, SDL GroupShare and SDL Passolo.  But we are beginning to see some applications created using APIs for SDL Language Cloud.

    So, where does SDL WorldServer and SDL TMS fit into this?  Studio (I'm dropping the SDL part of the name now) is the desktop client used by Translators, Reviewers, Post-Editors and Project Managers when working on projects that might have originated from WorldServer or TMS.  So many SDL customers working with these products use the OpenExchange to create specific solutions for themselves, solutions that are never made available for download by other users.  These solutions might be as simple as automating access to internal databases to help provide better context, integration with internal data management systems such as Sharepoint or to customised machine translation engines developed with any technology and not just SDL Language Cloud or BeGlobal.  They might provide customised views and functionality within Studio itself using resources that are only available within their own organisation.

    So the OpenExchange is a complementary solution provided to all licensed users of the SDL Language Platform, and as this grows we'll see a wider range of solutions available.  It could be used for solutions made specifically for WorldServer or TMS too, but as these tend to be very customer specific it's a little less likely that we'll see them being made available for anyone to download.  It's the desktop products used by everyone where the shareable value is greatest.

    Hopefully that provides the sort of answer you were looking for, and maybe someone will be able to give you an experienced response to your first two questions... or add to my thoughts on the last one.
  • 0
    Hi Alvin,

    Great questions, and happy to help from the perspective of the language/technology side of the business (I'm the Translation Productivity Sales Engineer for US/Canada). My answers may be more oriented to Translation Productivity solutions, but our tools work in conjunction with the Enterprise tools of TMS and WorldServer - maybe one of my colleagues working on those tools can fill in anything I've missed.

    Paul hit the nail on the head for #3, so let me help provide some background for numbers 1 and 2.

    #1
    It would be great for us if all clients started out with translation in the same way! But as you've suspected, it's different for every client. I recently worked with a client who wanted to start using terminology solutions, and they hired a terminology consultant to help them with everything (technology, process, training, etc). Other clients realize a need to translate when they start going global, and they contact a language services provider and outsource everything. Yet other clients have resources internally who either officially or unofficially do one-off translations for the company and then decide to bring technology in-house to help them (and then expand their group to include speakers of other languages). It depends on the size and budget the organization has and obviously the number of clients/users/etc that they have in other countries; once a company starts selling in another country, they quickly realize the need to speak that country's language and culture, so any number of the above (or other) solutions are usually thrown together to make that happen. Local regulation may also play a factor into this; for example, by law in Quebec, everything has to be translated into both French and English, so companies wanted to expand to that geography have to abide by this. Keep in mind, too, that companies may need to mind the locale of a country - for example, a company wanting to expand into Brazil wouldn't (or shouldn't!) use a translator from Portugal, and vice versa; so finding the right resources and understanding the need for why the right resources are necessary sometimes takes an internal "champion" for language.

    #2
    Translation projects usually start in silos. Per the above, a company may need or want to translate into one language, so that project is thrown over the fence to someone internally or externally who can help them get there. Ultimately what organizations realize, however, is that translation can be expensive and time-consuming, so they start looking for tools that can help them do it faster. The concept of "translation memory" becomes key here, because translation memory is a growing database that constantly learns from a translator and - most importantly - allows for the same sentence/phrase to never be translated (and paid for) twice. Using your example, this means that the translations or terms used from a company website could be reused in product documentation. We have tools for translation memory in SDL Trados Studio. We also have MultiTerm tools in SDL MultiTerm. While all of our tools can be used or at least benefit everyone in a company, one of our MultiTerm tools specifically helps companies initiate company-wide terminology efforts involving all of their employees; it's called MultiTerm Workflow, and it's a web-based software that allows users to look up and also submit suggestions for terms (and their translations). This process can involve engineer, subject matter experts, marketers, and other folks who aren't usually tasked with translation or globalization but who may have knowledge into the correct functional or marketing terms that they want others in the company to use.

    Hope this helps! Feel free to reach out to me if you have any other questions. (I'm lktaylor@sdl.com in case you post here and I miss it).

    Best,
    Lindsay
  • 0 in reply to Paul
    Thanks for the explanation, Paul. That's great context for OpenExchange and fits the "Orchestrate" part of the Customer Experience Management story as I understand it. On the Web Content Management side, Tridion has features to integrate with an ecosystem external systems and also tend to be customer-specific, though we're seeing customers adopt open source frameworks based on SDL Tridion.

    I can see how customers would bring similar systems to the translation process with Studio and now separately with the SDL Language Platform.
  • 0 in reply to Lindsay Taylor
    Thanks, Lindsay--I've coined a phrase called "The Midas Rule" that echoes your responses: "Whoever touches something first and cares the most gets to decide what to do with it." I see how it fits organizations starting on "translation" where whoever has the biggest problem (or maybe resources to solve the problem) might start a translation project.

    We mention Translation Memory when explaining Tridion integrations with TMS and Worldserver. I even seen customer s"warm up" Translation Memory by sending Excel spreadsheets to get matches outside of the CMS.

    I understand Translation Memory is specific to a given organization, right? Would a customer only have one Translation Memory (database?) and does it apply across SDL (or other vendor) products? For example, would SDL MultiTerm's Translation Memory be separate from TMS or Worldserver?

    Nice point on local regulation--this probably explains at least part of the Tridion setup for any SDL customer with content for Quebec (there's always a Publication for English and French. :-)
  • 0 in reply to Alvin Reyes
    I like that phrase! I may steal it...I'll give you credit though.

    You are right that a Translation Memory is specific to a given organization. Think of a translation memory like any other company-specific database that contains confidential information and which you would consider an asset. However, customers can have as many or as few translation memories as they'd like. You'd have one translation memory per language, and sometimes (often for larger companies) you would have several translation memories broken out by functional area (i.e. an "IT" translation memory or a "Marketing" translation memory). You don't need to have more than one but many organizations do. Other organizations just have one "main" translation memory per language.

    The translation memory can be managed by a company and then used by their language service provider (for example, SDL Services). The customer would coordinate that with their LSP.

    To be clear, MultiTerm does not have translation memory; only SDL Trados Studio has translation memory (on the desktop tools side). On the Enterprise side, WorldServer or TMS users would create/manage their translation memories excelusively through their enterprise technology (so through WorldServer or TMS) and then they would allocate access to that translation memory to their translators or language service providers, who can "plug into" the translation memory via SDL Trados Studio. You wouldn't likely manage some translation memories on WorldServer/TMS and some off WorldServer/TMS; they would all likely be managed on those exclusively on those platforms, if you own one of those tools.
  • 0 in reply to Lindsay Taylor
    Ah, I should have caught that MultiTerm was for terminology.

    I'm seeing there's a lower-cased "translation memory" that refers to the process of capturing and storing translations, as an industry term, and the upper-cased "Translation Memory" specific to an an organization and/or technology. The same distinction applies to a CMS and Tridion-as-a-CMS.

    Borrowing a metaphor from say, dancing, I see a parallel with a ballroom dance syllabus, which is a manual of the dance steps for a given dance studio or franchise. There's the concept of recording steps into some type of re-usable repository, and then there there's the explicit syllabuses from Arthur Murray, Fred Astaire, or DVIDA. :-)

    By the Midas Rule, feel free to use the Midas Rule. It even has an Urban Dictionary entry. http://www.urbandictionary.com/define.php?term=Midas+Rule :-)
  • 0 in reply to Paul
    Hi,

    I agree with Paul on number 3 so like Lindsay allow for me to expand on 1 & 2.

    For your reference I am purely corporate client focused which ultimately means they are the ones who are managing the creation of source content and I come in at the point of localizing their l content via our TP Solutions.

    Whereas other BC’s have LSP’s as their cliental , giving them great insight into the complexities of managing someone else’s content given LSP’s don’t generally create content but assist with the location workflows (assuming corporate needs to outsource).

    1. With regards to where clients start:

    As you had used the phrase “it's not just English, but English for a given country” I take your concern may be less about localisation workflows but more about source content creation and how this then affects translation workflows??

    I have had mixed scenarios depending on clients maturity and/or content regulations been imposed (example pharma) alongside any content creation strategies that may/may not be adopted within their organisation.
    This is in comparison to those who are struggling to overcome matters that revolve around resources such as money, current systems, vast working partnerships, type of business, full corporate alliance etc.

    Some clients are already aware and sophisticated with regards to the importance of high quality source content.
    Others have more difficulties which is where your "its English but not English" does become a problem.

    One example I had was - product parts were developed in Japan with content to support the parts.
    But Japanese English was is not satisfactory for the English market’s comprehension, so source harvesting in this case is a 2 step phase which includes the retranslation of Japanese English content.

    Another example I recall is one part of a business based in Germany believed they are the source originators due to product development notes been authored in Germany.
    Although UK felt they were the source originators due to them been the ones who created the product user guides and supportive notes.

    I recently attended TC world which is aimed at tech doc writers and was able to confirm my long term suspicion which is - writers (content originators) are working independently to localisation teams and vice versa. Even though it’s the same corporate client you will be amazed how one half of the business is not aware of the other half’s daily operations (SDL also falls into this trap on occasions).
    Therefore no feedback is achieved with regards to each other’s difficulties and successes of a handing over content writers and translators, all of which can add to the difficulty of effective content handling and appropriate corrective actions.

    I think it’s important to confirm that from my experience I have spoken to content writers who are working in development, marketing, support, official content writing departments etc.
    This means that depending on content purpose and client setup, writers are not always fully qualified and/or dedicated to content origin and there may not always be awareness in authoring with localisation in mind.

    A common problem as a result is context, which is always top of the list when it comes to why problems occur in the mind of managing localisation content and in addition quality of translation is discussed.

    To aid context and to ensure the translators correctly morph their interpretation (translated content) in line with the intentions of the source authors - can partially be achieved by terminology management. As you mentioned the handling of jargon and product-specific terms.

    However, I visited a client recently which as the first client in over 2 years of consulting, which actually has the title terminologist :)
    Regardless the biggest problem is harvesting terms, getting the right parties to agree/reference the terms in question and for this process to be managed effectively.

    A process which conceptually does not sound overly complicated using our solutions, but in practice offers various acceptance and implementation issues.
    This is further complicated due to most "term" conscious users been placed under various aliases such as "power user", "head of marketing/translation act", "product development"

    We are in an age where ideally corporations have an international English as a basis for content. We are therefore no longer simply translating the content so its linguistically correct, but also regionally correct.

    Translation is therefore moving into an era of regional interpretation. (not applicable to all translations depending on content)

    2. Is "translation" (sometimes/often) a company-wide project

    I know there is a law in the EU that states that if you wish to offer your services/product in an EU country, you need to support that country in question with local content translation. So if you wish to be EU wide, that’s 23 languages you need to support and manage.

    We have had many opportunities grown from this fact. Saying that, we then hear that the client (parent level) already is part of the SDL family whereby users are potentially using our CAT tool but in a different country.

    This is great news as it means we have a direct referral but it also suggests that although the company is international, divisions may very well be working in silo, as Lindsay had said.

    Again referencing my previous response, “Even though it’s the same corporate client you will be amazed how one half of the business is not aware of the other half’s daily operations”

    Biggest question for global companies would be, is your CMS system central? In which case yes I could be forgiven to assume that translation is something a company may handle from a company-wide perspective.

    Alternatively, are the systems more local even if it was to support EU only.

    I had once example where the client had a central CMs system that was to feed websites and documentation.
    However not all the content with in the CMS system was up to date and relevant, so manual authoring was still taking place.
    What was important for the client was at the time of translation, their CMS system was been updated with this “new content” for appropriate reuse. As a result it was less about helping with the source accuracy/reuse but more about storing of translation.

    I trust this helped, more than welcome to have a coffee discussion over the phone and exchange experiences.

    Take care, Lydia
  • 0 in reply to Lydia Simplicio

    Great insights, Lydia, and thanks for sharing. I might ping you for other questions, but I appreciate having the points available here to anyone interested in learning about CMS and translation. :-)

    Regarding "English for a given country," yes I was thinking about source content and its impact on translation. But I've also seen customers deal with translation from English for the US to English for the UK. Interesting note on pharmaceuticals. I imagine the regulations aren't necessarily related to translation as much as they're country-specific (which means they impact translation).

    Let me follow up with a semi-technical question on Single vs. Multiple Source Translation Setups and some parallels with the rest of your response. Basically I see the same themes in enterprise Content Management. :-)

    Translation Setups

    In our documentation we describe scenarios of taking source content in one language (Japanese was one example), translating it to international English and then to other languages.

    Single Source

    The single content source setup should be familiar to Tridion customers and consultants:

     Translation Manager configures Tridion with source and target languages. In this example, English Content (say for the US) acts as a source for German, Dutch, and French Publications. These then feed into German, Dutch, Belgian (Dutch), French, and English (US) Websites.

    The Tridion setup is on the left (English for the US is missing at the top). On the right is one of the three Translation System options (SDL TMS, SDL WorldServer, or SDL BeGlobal). The configurations differ, but functionally they all end up providing translated content in various target languages. Each customer will have its own set of languages and setup.

    Multiple Source?

    What I haven't seen yet is taking this translated content and re-translating it to other languages (multiple source). 

    Does this scenario come up where content translated from French for France gets translated to English for the US, and then back to French or another language? The diagram can also cover scenarios where three groups of authors originate content in different languages, which then goes to English, which sort of acts as a "Single Source."

    I have a hypothetical example that might fit where someone might change a description of a holiday to a region-specific version (Halloween, All Saints Day, and/or Día de Muertos). But then you might also want these translated descriptions available in other languages.

    This is related to your description of "linguistically correct, but also regionally correct" content. SDL Tridion has a "localize" feature to take any source content and change it in a different Tridion Publication (the largest folders in the CMS as seen in the above diagrams). We have to be careful with this term though, because it could mean either linguistic translation and/or a change for a given region or market. Tridion's "agnostic" of how you use a given Publication setup (which we call a BluePrint).

    Do you have more on "authoring with localisation in mind?" That could be a blog title! :-)

    Big Organizations and Context

    I've seen similar challenges with content management, including confusion on who owns content. Usually it's in the form of one group thinking another group produced or owned something. We find out later it's much more involved and there's an ecosystem of authors, approvers, and tools.

    Rather than groups believing they are the source originators (or wanting to be the source), the groups I work with sometimes want someone else to own either the creation or publishing of some content. After a few years of enterprise consulting, I admit being less amazed now about how parts of a business are not aware of the rest of the business. :-) 

    Like any other large organization, I think SDL faces the same challenges. But things that show we hopefully "get it" more than others include:

    • A familiar user interface and experience across SDL products (see Philipp Engel's presentation on the process).
    • An interview with CEO Mark Lancaster describes the challenges with aligning an organization. I can see changes made a year or two ago having an impact today.
    • SDL Community -- we've historically had active communities, it's great having a combined location to learn about each other now.

    Also, I like promoting the Marketing template and style guide so we're seeing consistency across SDL (Web) Professional Services . I know a few of my colleagues could write their own style guides and templates, but why spend the extra effort to be different when someone's already created a template, prototype example, and recommendations on how to use them? :-)

    New Roles for New (the same old) Challenges

    Interesting that you found a Terminologist. I've seen something similar on my side and found one person with the title Content Strategist. We almost always have power users, who tend to see everything right and wrong in an implementation, but don't always have the power to influence the requirements or implement changes (to the setup, to code, etc.).

    Too Much Software

    As a CMS, SDL Tridion might be as central as a company would like. But with any software it's very easy for a department, or even an individual, to choose the tool they like. For example, I've seen a dozen tools in a company to make PDFs. For CMS, there's Tridion, but also legacy systems, competitors, SharePoint, the internal CMS, Word documents, Excel spreadsheets, and so many others. Occasionally even one of my colleagues might suggest yet another tool for a project, and I'll suggest we use one of the existing options. :-)

    Tridion attempts to "play nice" with these and can make external content libraries visible to CMS users to place on pages or publish. Tridion can also add anything during publish (it's a corporate team player).

    The "orchestrate" part of the Customer Experience Management story probably won't ever go away. 

    Terms?

    To make sure I follow, do I have the terminology right?

    • TP = Translation Productivity?
    • LSP = Language Service Provider
    • BC = Business Consultant
    • What's TC World?
    • CAT?

    Feel free to comment or ask about anything in this post. My only real question is if translating back-and-forth between language is a common setup? I've yet to design a Tridion BluePrint based on this, but maybe it happens before or after the CMS.

    Thanks!