Enterprise Workbench Extension

Owned by Aaron Sakievich (Unlicensed)
Last updated: Feb 28, 2024 by Kenny Teves
5 min read

Overview

Enterprise supports in-context translation in the Workbench for specific file types automatically (INDD, IDML, InDesign packages, and HTML files). We need to reference the source web page for other file types to provide the functionality described on the In-Context Translation page. You need to have the Enterprise Workbench Extension installed while working in the new Workbench, and In-context translation will work if your webpages and sites are configured appropriately (see more details below). 

Installing Enterprise Workbench Extension

  1. Select this link to open the extensions page directly or

    1. Go to the Chrome web store. 

    2. Search for Enterprise Workbench Extension (Beta).

  2. Select Add to Chrome.

  3. Chrome will ask you to confirm your decision. Select Add Extension.

  4. You'll receive a notification when the extension is added to Chrome. 

  5. Open the new Workbench, and the Context Window will automatically open for any of your assigned tasks created with a source URL. 

  6. If the source segments in our source file match the text on the web page, then all the functionality described here will be available. 

What our Extension Does

Please note this is not a perfect process. Occasionally the source text on the page differs from the source segments we are provided, or the structure of the site could interfere with segment matching. 

  • Once the Workbench loads the Source URL into our Context Viewer, the extension matches the source segments' text on the loaded web page. 

  • It creates links between the segments in the Workbench and the source text on the webpage. This enables you to click on the web page text and be taken to the matching segment in the Workbench and take you to the correct location on the web page as you are navigating through segments in the Workbench. 

  • This linking also allows the extension to take any translations and display them instead of the original text, allowing you to see your translations in real-time. 

Access

Linguists will need to have access to the webpage to view it in our context viewer. We support SAML 2.0 single sign-on for customers. 

Security Headers

X-Frame-Options and frame-ancestors are used in HTTP headers to control when and if a webpage can be loaded into an iframe. These are valuable tools to ensure your content is secure. However, your webpages must be set to allow our domain to load your webpages in an iframe if you want linguists and internal-reviewers to view the webpage in our Workbench.  

If these security headers are not configured appropriately, users can still load the webpage in a new window without losing any functionality described here. 

X-Frame-Options

Example: Will not load in the Context Viewer
<system.webServer> ... <httpProtocol> <customHeaders> <add name="X-Frame-Options" value="SAMEORIGIN" /> </customHeaders> </httpProtocol> ... </system.webServer>

  • X-Frame-Options directives can only be set to SAMEORIGIN and DENY. Because of this, it is not possible to employ X-Frame-Options and load a webpage into our iframe (but they can be loaded into a new window where users can perform in-context translation).

  • X-Frame-Options are obsolete for most browsers and can safely be replaced by frame-ancestors. 

  • See this external documentation for more information about X-Frame-Options. 

Frame-Ancestors

Example: Will not load in the Context Viewer
Content-Security-Policy: frame-ancestors 'self'
Example: Enterprise Whitelisted
Content-Security-Policy: frame-ancestors 'self' https://*.lingotek.com

  • Frame-Ancestors can be configured to allow other domains to load your webpage in their iframes. If you configure your Frame-Ancestor like the example above, linguists will be able to load your web content in our iframe. 

  • See this external documentation for more information about Frame-Ancestors. 

Do I have Security Headers? 

If you are unsure if you have security headers enabled or what kind you have set up, you can find them by:

  1. Open your browser's dev tools.

  2. Open your source URL in your browser.

  3. In the Network tab of your dev tools, select the call to the URL.

  4. Look under your Headers tab. 

  5. Under the Response Headers, check to see if there are X-Frame-Options or Content-Security-Policy headers.  

Insecure HTTP URLs and Redirects

Please see the following information about loading Chrome blocking mixed-content. 

  1. We load the provided source URL into our context viewer, which is a secured iFrame. Chrome does not allow Insecure URLs (which begin with HTTP instead of HTTPS) to be loaded in a secured iFrame. 

  2. If you are provided with an insecure URL, you have the option to load the page in a new window in Chrome, where you can open insecure URLs (insecure content can't be displayed in an iframe on a secure page, but it can be displayed in its own window). The source segments should still match the source content on the page, and translations will still be injected. 

  3. If you provide a secure URL (HTTPS) that redirects to an insecure URL (HTTP) at any point in the redirect process, you will not be able to load the URL in our iFrame, even if the final result is a secure URL. 

  4. If the source URL redirects too often, it may affect the extension's ability to link to the final source page. We have provided a Retry Segment Matching action in the Context Viewer settings if it appears that matching should have occurred but was not successful. 

For users to access content behind a login, your site’s cookies must be set to SameSite=None; Secure. The main cookies that need to be set correctly are the ones that indicate to the server that the user is logged in and any that are necessary for the operation of the site. You can have many of these with different names.  

Are my cookies set up correctly?

To check your cookie settings:

  1. Open your browser's dev tools.

  2. Open your source URL in your browser.

  3. In the Network tab of your dev tools, look for the response that contains a set-cookie header. Select ctrl (command) + f in the network tab, then search for "set-cookie" to see all the network requests that set cookies. 

  4. Look under your Headers tab. 

  5. Under the Response Headers, look for Set-Cookie and check to see if your Cookies are set to SameSite=None; Secure.

Custom Security Measures

Since custom security measures can be implemented in infinitely different ways, we cannot always auto-launch the context viewer in a new window. If your development team has introduced custom security measures that are not listed above, we can help you whitelist our tools, or you can load the context viewer in a new window.

Loading the Source URL in a Separate Window

  • Please note that when launching the source URL in a separate window, the extension may fail to connect when it first loads. When this occurs, we provide a message letting you know of the failure and a Retry button to select when you know you are on the correct page.