This article is for Account Owners and Project Managers using the Global Delivery Network
Disclaimer: The Advanced Integration rule editor is designed for developers who have an in-depth knowledge of your source code, site design, and the Global Delivery Network. Changes made using this tool have the ability to break functions of your translated sites, and in some cases prevent the translated sites from functioning in entirety. We recommend that you instead markup your source code using our GDN integration tags or configuration rules. If there are cases where this is not possible, contact your Customer Success Manager to discuss if this tool is right for you.
The Global Delivery Network (GDN) has a default set of rules for handling websites including behavior around HTML, JavaScript, JSON and XML. Depending how you have structured your code, it is possible that content may not be handled as desired by the GDN's default rules.
To alter GDN behaviors, it's recommended to markup your source code with GDN integration tags where possible so you have complete visibility into how your content will be handed by the GDN. Integration tags are designed to be lightweight, and easy to use. In cases where this is not possible, the Smartling offers an Advanced Integration Tool interface to manage GDN behavior.
Tool Overview
Advanced Integration Tools allow you granular control of behaviors like content capture, content parsing, pseudo-translation, redirects, and code that appears on your translated site. The tool offers two types of controls:
It is important that you are aware of the risks involved with using this tool before it is enabled for your account.
Custom Rules
This interface allows you to apply specific behaviors to files, pages or directories on your translated site. To learn more about Custom Rules available to you, see our Advanced Rule Library.
- Rule ID: A unique ID is generated automatically when the rule is saved.
- Enabled: Enables/disables the rule.
- Test mode: Will only apply the rule if parameter smartling_testmode=6 is appended to the URL. You can read more about edit modes here.
- Rule Type: A list of preset rules. Alternatively, you can use a custom rule server/location from the Advanced Rule Library.
- Domain: Limits the scope of the rule to a single domain. Leave blank to apply to all domains.
- Locale: Limits the scope of the rule to a single locale. Leave blank to apply to all locales.
- Rule Condition: Allows you to limit the scope of the rule. For example, you can limit the rule to all pages in the blog folder by using uri:/blog/. A full list of conditions is listed below:
- URI: 'uri:'
- Reponse Header: 'response_header=='
- Request Header: 'request_header=='
- Tag name: '<' or '.' or '#' (for tag name, class and id respectively)
- Content Type: 'part_ct:'
- Conditional: 'if:' (e.g. 'if: $host ~en.tests.local')
- Created by/Created: Automatically logs the user and date of when the rule was first created
- Modified by/Modified: Automatically logs the user and date of when the rule was last modified
- Rule Text: Write your rule here
- Comment: Each rule requires documentation before it can be saved.
Custom Rewrites
This interface allows you to alter specific source code as a response passes through the GDN, so a different code can appear on a translated site. It functions as a "find & replace" tool. To learn more about Custom Rewrites, see our article on Advanced Rewrites.
- Rewrite ID: A unique ID is generated automatically when the rewrite is saved.
- Enabled: Enables/disables the rewrite.
- Is regex: Indicates if your rewrite search uses regex. Enabling this for non-regex rewrites or for poorly written/greedy patterns can cause significant performance loss.
- Rewrite Type: A list of rewrite types. You can read more about the types here.
- Domain: Limits the scope of the rewrite to a single domain. Leave blank to apply to all domains.
- Locale: Limits the scope of the rewrite to a single locale. Leave blank to apply to all locales.
- Rewrite Condition: Allows you to limit the scope of the rewrite. For example, you can limit the rewrite to all pages in the blog folder by using uri:/blog/. A full list of conditions is listed below:
- URI: 'uri:'
- Reponse Header: 'response_header=='
- Request Header: 'request_header=='
- Tag name: '<' or '.' or '#' (for tag name, class and id respectively)
- Content Type: 'part_ct:'
- Conditional: 'if:' (e.g. 'if: $host ~en.tests.local')
- Created by/Created: Automatically logs the user and date of when the rewrite was first created
- Modified by/Modified: Automatically logs the user and date of when the rewrite was last modified
- Rewrite Search: The string to be rewritten.
- Rewrite Replace: The string that will replace any matches of the rewrite search.
- Comment: Each rewrite requires documentation before it can be saved.
Risks
Poorly or incorrectly written rules can have adverse effects on your GDN sites. Issues can include incorrect parsing of content (filling authorization queue with wrong strings), broken functionality or performance loss. It is ALWAYS recommended that you test your GDN rules on a staging site first.
Not using a staging environment? Learn more about using a Staging environment with the GDN.
Best Practice
- Testing for rules should always be conducted on a non-production environment first.
- When modifying an existing rule, you should always create a copy of it first. You can then disable the first rule in order to test your new rule.
- Rules can be limited to a single domain by using the Domain dropdown option within the advanced rules interface. After testing, the rule can be applied to a production environment by changing the domain.
- Rules can also be limited to specific URIs by specifying 'uri:' in the Rule Condition field. For example, if you only want the rule to apply to blog pages, you can use the following condition:
uri:/blog/
Rules are NOT backed up and can not be restored to a previous version. Smartling is not responsible for broken functionality on your translated site from rules implementing using Advanced Integration Tool.