Dynamic Content Support (DCS) is a JavaScript library designed for translating dynamically generated website content. As a feature of Smartling's Global Delivery Network, it works in harmony with the translation proxy.

While the GDN translation proxy is used to translate content as it is transmitted to a browser, DCS captures source text that is rendered in the browser by JavaScript and related frameworks (e.g., React).

Here are some actions that DCS will take:

• DCS detects new source material as the localized page is loaded and browsed. Content that is rendered in the browser during interaction with page elements is also captured.
• DCS then sends that content to your existing GDN project in Smartling for translation.
• Once the translation process has been completed in Smartling, DCS inserts the published translations the next time the page loads.

Benefits of using DCS

Dynamic Content Support (DCS) works in combination with Smartling's GDN web proxy.
While the GDN web proxy translates content being sent to the browser and builds the structure of your localized website, DCS automatically captures dynamic content rendered in the browser, without requiring a complex configuration to detect or handle the content.

Most modern websites utilize JavaScript to create dynamic, interactive features, such as animations, media playback, in-browser games, and real-time updates, which make websites more engaging and interactive. This creates challenges for translating content during its journey to the browser, as translatable text is often scattered across multiple areas of the JavaScript code and may only be assembled into legible text or sentences when displayed to an end-user visiting the site.

DCS solves this challenge by detecting and extracting content when it is rendered in the browser. This ensures that text, regardless of how it's generated, can be accurately and seamlessly translated.

By combining the capabilities of the GDN web proxy and DCS, you gain a powerful and flexible solution for translating web content without relying on files, APIs, or custom connectors.

Key benefits

• Improved content ingestion and string parsing
  The GDN web proxy processes content "in transit" to the browser. When it does, it may ingest incomplete sentences or fragmented strings due to how the content is structured in the website's code. DCS solves this by capturing the fully rendered text, exactly as it appears to the user after the page has loaded in the browser.
• Fewer rules to maintain
  Traditionally, the GDN proxy has supported capturing dynamic content with the assistance of advanced rules and configurations. These rules are effective for capturing content from JavaScript and JSON data sources; however, if your website's code or structure changes, you may need to update these rules accordingly. DCS eliminates the need to define or manage static rules that depend on specific URLs or source code structures. DCS will continue to work and capture dynamic content as your website evolves, thereby reducing the effort required to maintain your translated website.
• Support for third-party content
  DCS can ingest dynamic content from third-party platforms, such as forms hosted externally, even if the rest of your site is translated using the GDN web proxy. 

How to enable DCS

Dynamic Content Support is enabled by default for all GDN projects created after August 2023.

If DCS is not suitable for your specific integration, the Smartling team may have disabled it. This is done by applying a rule to your project configuration that overrides the default setting and deactivates DCS.

Tip: If your GDN project was created before August 2023 and you are interested in using DCS, contact your Smartling Solution Architect to discuss a migration plan. If your current GDN integration uses advanced rules to capture dynamic content on your website, those rules will need to be reviewed and updated with the assistance of Smartling Professional Services.

How to determine if DCS is enabled

DCS is enabled by default for all new GDN projects. To verify that DCS is enabled for a page:

1. Open the translated page in your browser.
2. Open your browser's developer tools. 
3. Select the Console tab.
4. Look for the message: Smartling DCS library - [version number]
   
   
   
   If this message appears, DCS is enabled. 

Info: Once enabled, the proxy will automatically inject the necessary elements into your web pages, and DCS will run whenever a user visits your localized site(s). The process of managing and configuring your localized domains and pages remains unchanged.

How DCS works

DCS captures translatable text by detecting changes in the Document Object Model (DOM) when a page is rendered. It can identify and translate any content rendered in the DOM, ensuring users receive a fully localized experience.

When changes are made to the DOM (e.g., by loading in new text without refreshing the page), they are automatically detected by DCS and captured for translation.

When a user visits a localized page, DCS works through the following steps to detect, look up, and apply translations.

1. Content detection
   As the page loads and the user interacts with it, DCS monitors the DOM for any new or changed text. When content is rendered in the browser, whether on initial load or triggered by a user action, DCS detects it and extracts the translatable strings.
2. Translation lookup
   Each extracted string is checked against a Translation File: an encrypted file hosted on the Smartling CDN that contains all published translations for your project. This file is downloaded once when a user first visits the localized page and cached in the browser's local storage for up to 30 days, so subsequent lookups are fast.
   • If a translation exists in the Translation File, it is applied to the page immediately.
   • If no translation exists, the source string is sent to your Smartling project for ingestion, where it can be authorized for translation.
3. Applying new translations
   Once a string has been translated and published in Smartling, it is added to the Translation File. The translation will appear on the page the next time it loads.
   Note: New translations can take up to 20 minutes to be added to the Translation File after they are published in Smartling.

Timing and bleed-through

Because DCS looks up translations at render time, there is a brief window during which newly ingested strings may appear in the source language before a translation is available. Once the string has been translated and published, it will appear correctly on the next page load.

The Translation File rebuilds approximately every 20 minutes, so translations published after the last rebuild will appear on the next cycle. In some cases they arrive sooner: if DCS encounters a string during a page visit and a translation is already available in Smartling, it is returned immediately and applied without waiting for the next rebuild. When a newer translation arrives by either path, it automatically replaces any older version in the browser cache.

To minimize source language bleed-through, you can enable site-wide machine translation, which provides a provisional translation for each string until the final published translation is ready. See Preventing bleed-through: Site-wide machine translation for details.

What does a page translated with DCS include?

A page using DCS loads at least two files in the process of rendering the localized page:

• A JavaScript file to translate the content (the DCS library)
• A Translation File containing the published translations from your Smartling project
• Depending on how your website is configured, a third custom JavaScript file can be included to define any non-standard translation behavior. For example, a request to implement a "noingest" rule.

Tip: If a large portion of your site is translated using DCS, it can generate a larger Translation File, which may affect page load times. If you're using DCS to translate significant portions of your site, contact your Smartling Solution Architect for guidance.

Composite strings

During ingestion, Smartling parses your website content into translatable strings. These strings are the individual translation units that are translated in your GDN project.

When sections of content contain inline elements, they may be split into multiple strings during ingestion. This can cause sentences to be broken unnaturally and make it more difficult for translators to preserve context and produce natural translations. Composite strings help preserve the full context by treating these sections as a single translatable unit. This results in more accurate translations and better handling of phrases and idiomatic expressions.

When a page contains a parent element with a mix of plain text and inline child elements, DCS treats the entire parent element as a single translatable unit. This is called a composite string.

Instead of extracting each piece of text separately, DCS captures the parent element's content as a single string, preserving the context and word order translators need to produce natural translations. This is especially important for languages whose sentence structure differs significantly from English.

Example:

A parent element like this in the DOM:

<!-- DOM -->
<div>
  <span>Results not found, </span>
  below are your previous results.
</div>

Is treated by DCS as one string: "<span>Results not found, </span>below are your previous results."

What prevents composite strings from forming

Composite strings only form under certain conditions. If you notice that related text on your page is being translated as separate strings rather than as a single unit, it may be because:

• The content spans a block-level element (such as a <div>, <p>, <li>, or heading tag). Composite strings only form across inline elements (e.g. <span>, <a>, <strong>); block-level elements break the grouping.
• The content sits inside a zone excluded from translation, such as an element with the notranslate class or a translate="false" attribute.

If you have a specific case where you expect content to be grouped as a composite string but it isn't, contact your Smartling Solution Architect for guidance.

Handling structure differences

Occasionally, translated content may not map cleanly back onto the original HTML structure. For example, if a translation reorders words in a way that doesn't align with the original inline elements. When this happens, DCS attempts to adjust the original element to accommodate the translated structure. If that isn't possible, it falls back to replacing the content directly.

In rare cases, this fallback behavior may result in minor formatting differences between the source and translated versions of a page. If you notice this happening frequently on your site, contact your Smartling Solution Architect.

What DCS captures and doesn't capture

DCS works by intercepting native DOM methods and property setters at the time they are called by the page or its JavaScript frameworks. This means no changes to your site's code are required; all content capturing happens transparently.

Some sites do use optional DCS configuration properties (see Key configuration properties below) to fine-tune behavior for specific frameworks, such as React or Web Components, but this is configuration, not a change to your site's own code.

What DCS intercepts

DCS hooks into the following DOM methods and property setters:

Certain element types have additional handling: <option>, <optgroup>, and <input> (for value, defaultValue, and placeholder on submit/button types).

What DCS does not capture

Important considerations

For the most part, content ingested with DCS is managed in the same way as strings ingested by the GDN translation proxy. However, there are some important considerations to bear in mind.

Translation file security

The Translation File that DCS downloads to the browser is encrypted using AES (Advanced Encryption Standard). The encryption key is derived from the original source text, which means no external key management is required. This approach is designed to protect published translations from casual inspection.

Before any content is sent to Smartling, DCS automatically masks personally identifiable information, including emails, phone numbers, and credit card numbers, replacing them with placeholders. The original values are never transmitted or stored, and are restored automatically when the translated content is displayed.

Identifying content captured with DCS

Strings captured by DCS are uploaded to your regular Smartling GDN project, which is also used for the GDN proxy. You can identify these strings in the Strings View by looking for the /origin-pjs/ prefix in the ingestion URL. 

Example:

When searching for a specific URL in the Strings View and using an "Exact Match" filter, please bear in mind that strings captured by DCS will only be returned if the prefix /origin-pjs/ is added to the URL you are filtering for.

Example: 


Similarly, when creating a Jobs Automation Rule with a content filter, the prefix /origin-pjs/ must be added to include/exclude strings captured by DCS. Alternatively, use a wildcard to include/exclude both strings captured by DCS and strings captured with the proxy.

Example:

 

Visual context

DCS does not provide visual context for the strings that it captures. This means that some additional configuration is required to display visual context for content ingested with Dynamic Content Support.

Tip: Consult your Smartling Solution Architect, who can advise on the best way of uploading visual context to your Smartling project.

Content swaps and rewrites

Dynamic Content Support cannot be configured to create locale-specific content, such as advanced rewrites and content or image swaps.

Tip: To set up customized content for your localized domains, please speak to your Smartling Representative about combining Dynamic Content Support with Smartling's GDN web proxy.

Supported rules

Most GDN rules and advanced rules are not supported for content captured with DCS.

Currently, DCS supports the following rule types:

• "Do Not Translate" rules - see below for more information
• "Mask" rules to automatically turn elements such as numbers or dates into placeholders

Tip: If you would like to apply a rule which is not currently listed as being supported for DCS, please speak to your Smartling Solution Architect.

Excluding content from translation

By default, all content detected by DCS will be uploaded to Smartling for translation.
HTML elements that should remain untranslated can be excluded from the translation process by applying a "translate=no" HTML attribute.

Alternatively, you can use dashboard rules to keep portions of a page from being translated. Currently, DCS only supports "Do Not Translate" rules created in the Smartling dashboard.

These "Do Not Translate" rules can be set to avoid capturing the following attributes:

• Page URL
• HTML Class
• HTML ID
• CSS Selector

Note: Any "Do Not Translate" rules created for your Smartling project are universal and will apply both to content captured with the GDN proxy, and to content captured with DCS.

Placeholder patterns

Similarly to placeholders in resource files, pattern matching rules can be used to help reduce the cost of translating repetitive text on your website that contains dynamic variables, such as order numbers or prices.

The following is an example of a string ideal for pattern matching:

Pattern matching will ensure that instead of the actual number, a placeholder is used:

Patterns can be created via the Smartling dashboard as shown here. A placeholder will then be applied to any new strings matching the same pattern.

Note: Patterns will also apply to any new strings detected by DCS. The same patterns that were created for strings ingested with the proxy will also apply to content captured by DCS.

Alternative ways of applying placeholders

An alternative to creating patterns in the dashboard after text has been ingested is to edit your site code to include in-line No Translate tags. These will work similar to patterns and have the same net effect of reducing the ingestion and translation of repetitive strings that contain dynamic elements.

DCS also supports "Mask" type rules, which will automatically turn elements such as numbers or dates into placeholders.

Preventing bleed-through: Site-wide machine translation

To provide a seamless experience in each target language, a provisional machine translation can be displayed for each translatable string on your website. This helps prevent bleed-through of source language text on your localized pages.
Once the strings have been captured and fully translated, the machine translation is replaced with the final published translation from your Smartling project.

Site-wide machine translation also works on content that will be captured with DCS.

Tip: You can find more information on setting up site-wide MT in our video tutorial.

Advanced configuration and technical details

The following sections cover implementation details for Dynamic Content Support (DCS), including DOM attributes, configuration properties, and debugging tools. These topics are intended for users who want a deeper technical understanding of DCS. If you have specific questions or need assistance, contact your Solution Architect or another Smartling representative.
 

DCS attributes in the DOM

When DCS processes a composite string, it automatically adds the following attributes to the parent element. You may notice these when inspecting the DOM:

• sl-html-hashcode: a unique identifier that DCS uses to match the element to its corresponding translation in the Translation File.
• slCompositeString: marks the element as a composite string, indicating that its contents should be treated as a single translatable unit rather than individual fragments.

These attributes are added automatically by DCS and do not affect the appearance or behavior of the page.

Shadow DOM and Web Components

Content rendered inside a shadow root (used by Web Components and frameworks like Lit) is picked up by DCS by default as of DCS library version 62.

If your site uses an older version of DCS, or if content inside Web Components isn't being translated on your site, contact your Solutions Architect or another Smartling representative for assistance.
 

Key configuration properties

Only uid and locale are required. All other properties are optional and fall back to safe defaults.

For a full property reference or help with a custom configuration, contact your Smartling Solution Architect.

Debugging DCS

If you are experiencing issues with DCS, debug logging can help identify why content is not being captured or translated as expected.

Enabling debug logging

You can enable debug logging directly from your browser's developer console without making any changes to your site. Open the console on the localized page and run:

// INFO level
localStorage.setItem("slDebugLogs", "true");
// Or set a specific level (0-4)
localStorage.setItem("slDebugLogs", "4"); // most verbose

Then refresh the page. To disable logging, run:

localStorage.removeItem("slDebugLogs");

The following log levels are available:

Log namespaces

When debug logging is enabled, filter the browser console by the following prefixes to focus on specific areas:

• [NoTranslate]: explains why a particular string was skipped and not sent for translation. Useful for diagnosing missing strings.
• [Pattern masks]: shows which placeholder masks were applied to a string. Useful for verifying that pattern matching rules are working as expected.

Extending DCS with custom hooks

For edge cases that standard configuration and rules can't address, DCS supports a set of extension hooks that let specific parts of the translation pipeline be customized at the element level. These hooks are implemented by the Smartling team as part of your DCS setup, based on your specific requirements.

Some examples of what custom hooks can do:

• Block ingestion on specific pages: prevent any content on a page from being sent for translation, useful for internal or staging-only pages that shouldn't be localized.
• Force an element to be treated as a composite string: group content together for translation even when it wouldn't normally qualify (see What prevents composite strings from forming).
• Mark specific content as non-translatable: exclude particular elements or text nodes from translation beyond what standard "Do Not Translate" rules cover.
• Control translation of specific HTML attributes: allow or block translation of attributes on a case-by-case basis, beyond DCS's default attribute handling.
• Skip translation of dynamically appended content: prevent specific child elements from being translated when they're added to the page after load.

If you have a use case that isn't addressed by standard configuration, rules, or the examples above, contact your Smartling Solution Architect to discuss whether a custom hook can help.

Troubleshooting & FAQ