Multilingual Static Endpoints

Last Updated: Aug 9, 2021
documentation for the dotCMS Content Management System

When Push Publishing to Static Endpoint, there are some special considerations, parameters, and configurations that will change the end result of your staticly produced site. To learn how to configure a Static Endpoint properties, please see the Connecting Remote Servers documentation. The image below shows a proper Static Endpoint configuration that includes both the language and date properties.

Note: Static Endpoints are only supported in dotCMS Enterprise editions for customers with a Site License (Platform level license). Please see the list of dotCMS versions for more information on features supported in different version of dotCMS.

Expected Multilingual Static Push Behavior

When the {languageIso} property is configured on a Static Endpoint, then a separate static site will be created for each language in which mulilingual pages exist. The “en-us”, “es-es”, etc., will be seen within the name of each static bucket, for each page language version. For the default settings to work optimally, each static site (in each language), please refer to the following requirements and recommendations:

  1. Every page must exist in each language version (Creating pages in only the default language will not create multi-lingual static sites)
  2. Content must be translated on each page in all languages to avoid blank static pages*.
  3. URL mapped content pathing will be created, however, do NOT nest URL maps under anotehr page, as they will not work. Example: Do NOT create a page called “news” and then create a pattern with that page in the stem “news/url-title”. Static publishing urlmaps expects /news to be a folder, not a page.
  4. Static does not care about ?params. When using dotCMS restful image apis and place all args in the uri path and not in ?param
  5. Always end a restful image call with the filename at the END, e.g.
    rather than

Multilingual Endpoint Naming Strategies

dotCMS supports multiple **prefix strategies” configurations for multilingual static endpoints:

Example 1: (example config using bucket prefix- creates a folder for each language under each host bucket)


or Example 2: dotcms-bucket-en-us-/pages/my-page.html



Example 3: dotcms-bucket-/en/pages/my-page.html


Additional variables, such as {languageCountry}, can also be found in the connecting to remote servers documentation.

Endpoint Recommendations

  1. It is recommended that CDNs be used for common libraries, js, fonts, etc. This will help reduce the amount of local file dependencies for static page rendering.
  2. Pushing to both static and dynamic push publishing endpoints can be separated into separate environments, depending on your implementation needs. Static and Dynamic endpoints don't need to exist in the same push publishing environment.

Configurable Content Fall Thru Behavior

To avoid *blank static/dynamic pages where all content has not yet been fully translated, a property exists inside the file which, if set to true, can trigger the default language version of the content to persist, even if the page has no content translated for the language version of the site being browsed.


If this property is set to TRUE, then as long as a secondary language version of the PAGE exists, then the secondary language version of the content on the page will display, ELSE the default language version of the content will display - thereby avoiding blank pages. For example: If the default language is set to English, and a page exists in both English and Spanish, but a piece of content only exists in English, then both the english and spanish static sites will have the page, but on the spanish page, the default english content will display instead of leaving the page blank.

The following image shows to different language versions of the demo site pushed statically, and served, on Amazon AWS services.

On this page


We Dig Feedback

Selected excerpt: