Advanced Usage
1. Previewing and Validating Translations
This assumes you have specific languages you need to translate.
This also assumes you have your own preview/staging environment to publish content to, and have included preview/staging domains in your subscription.
For example, say you have www.mysite.com and www-preview.mysite.com serving translatable content.
In the preview environment, you also have a content structure, with paths based on language code for each language translation you need to provide.
/en/articles/product-details.html
/en/company-info.html
/es/articles/product-details.html
/es/company-info.html
/de/articles/product-details.html
/de/company-info.html
etc.
To enable translations for a page (or page section), the default action is to include a data-translate attribute. This allows Dialect Ready to translate based on the user's preferred browser language. You can override this default behavior and force translation to a specific language by adding a second attribute: data-locale-<language-code>, where <language-code> is the specific language you want to translate to. Note, data-translate must always precede this attribute.
Referring to the content paths above, you can set the following in page markup for the paths prefixed with /en:
<body data-translate data-locale-en>
Then you would do the same for the other content paths, using their specific language codes in the markup:
<body data-translate data-locale-es>
<body data-translate data-locale-de>
With this setup, source content is translated to a target language, under each path. This allows each translation to be previewed and validated prior to it being promoted to production.
This offers great flexibility in content promotion and the production setup requirements. Consider these scenarios.
Scenario A
You validate translated content in a preview/staging environment and then once approved, publish the source content to production under a single content path for all users. This would use the default language detection feature of Dialect Ready in production, to translate to the user's preferred language.
Scenario B
Alternatively, you could use the same language specific content paths in production as in preview/staging and publish the translated content from preview/staging to production, in this scenario, your production pages would not use the data-translate or data-locale-<language-code> attributes.
Don't like the way a translation was done? Edit the generated translation in preview/staging and republish to production.
Scenario A minimizes the configuration requirements and allows production translations under a single content path, but doesn't permit edits. Dialect Ready is very good at translation semantics and language syntax so this would normally not be an issue.
Scenario B permits editing of translated content, but requires configuring each content path across multiple environments. You also have to limit your translations to a defined set of languages you can support. This limits the reach of your content and its audience.
As you can see, there are options to fit previewing requirements, each with their pros and cons.
2. Translating Content Fragments
Modern web sites and applications use a mix of content from multiple sources. Snippets or fragments of HTML are often generated and re-used across content trees. This re-use makes content management more efficient, reducing duplication and isolating content sections as needed.
Dialect Ready supports this out of the box!
Add the data-translate attribute to any page element to translate that specific element's content, be it a snippet or the entire page body.
Combine this with the data-locale-<language-code> and you can translate different fragments of content to different languages on the same page.
Dialect Ready was built to provide an easy to use, dependable and always available translation solution. You have configurable options for how you use the service.