Publisher is EE6 compatible, but it does not support the Fluid field. Please do not contact asking when support will be available.

If you purchased an add-on from, be sure to visit to add the license to your account here on

Ticket: Custom multiple fallback languages for each available language

Status Resolved
Add-on / Version Publisher
Severity Trivial
EE Version

Es Kay

Dec 21, 2012

Hi there!

I know it’s a little bit early for the development state of Publisher (..still in Beta) but please at least consider the following feature for the future:

For each available language, the user would have the ability to select any (none or many) other languages as fallback languages and even provide the preferred sort order.
In addition he would be able to select an extra option of “no fallback language”.
When the system hits the “no fallback language” then it doesn’t show any content, as though the entry (at the front-end) or the field content (at the CP) never existed.
The fallback language selection mechanism should work for both the CP (while editing an existing or publishing a new entry)
and for the front-end.

For example:

  - No Fallback

  - Fallback 1: English
  - Fallback 2: No Fallback

Spanish (Spain)
  - Fallback 1: Spanish (South America)
  - Fallback 2: English
  - Fallback 3: No Fallback

Spanish (South America)
  - Fallback 1: Spanish (Spain)
  - Fallback 2: English
  - Fallback 3: No Fallback

  - No Fallback

  - Fallback 1: Danish
  - Fallback 2: No Fallback


In such setup each language becomes the center of attention for the system when selected with no site-wide default language
(..yes, as you named it, a “multi-tree” concept..)
Every language is the default when selected as the “display language”.
And has it’s own tree of fallbacks for both the CP and the front-end.
When the “No Fallback” tree node is hit, then the system returns no content.

At the CP, while translating an entry, the system should provide content for each field based on the fallback language tree for the selected display language. If the field has no content in the 1st fallback language then it should check for the next available fallback. If none is found then none it returns.

Similar is the behavior for the front-end. The only difference with the CP is that the system should not be able to mix n’ match field content from multiple translations / fallback languages. If a translation of the entry is found while checking the hierarchy of the current fallback tree, then this is displayed at the front-end. Even if some fields have not been translated these are not taken from the next fallback. They just stay blank.
All I mean is that it’s important for the front-end to display a translation as a whole set of fields (even if some of them are empty) from the same fallback language. While at the CP the need is different. Populate as many fields as possible from any fallback language while respecting their sort order (so that editors have at least something to translate).

This way, more complicated website data architectures could be achieved.
For example a news portal or magazine website that has different entries for each language/region but can also opt-in to have some entries translated to multiple languages/regions so that viewers from different regions and languages can have access to.

I believe that such a setup would definitely elevate Publisher from a “translation” module to a true “multilingual” module with no language centers predefined. And multi-language website solutions that currently require MSM just for the language differentiation (..not always translation..) of the content, would be easily set up with just one EE app with a LITTLE help of Publisher!..

Just give it a though


BoldMinded (Brian)

Dec 23, 2012

I will give this some thought, but I can’t imagine this being a typical scenario.

Login to reply