OpenWGA 7.3 - OpenWGA Concepts and Features

Publishing

Language choice

As an Web Content Management System allowing multi-language contents OpenWGA in some situations will need to make an automatic choice what language to show to the user. (Some of) these situations are:

  • An URL to a page is called with a valid, but incomplete content id that does not contain a language identifier. For example: Struct key or unique name only
  • A context change is done in WebTML to a different page, again without a language identifier, and the language of the source context is not available on the target page
  • An URL to a different page should be generated but the page is not available in the language of the source context

Generally the following concepts apply to these situations:

  • When an URL without language information is called OpenWGA will compare the languages that are configured to the users browser with those languages that the addressed resource is available in. The best match is chosen. If no match could be found OpenWGA will return the resource in the default language of the application. If even this is not available OpenWGA will return an HTTP error 404.
    • When the URLs points to a page then the browser languages are compared to the languages of the published content documents on this page
    • When the URL points to a design (a "contextless" request) then the browser languages are compared to the language definitions in the OpenWGA content store of the addressed application

  • In a WebTML page OpenWGA will generally try to address other resources in the same language as the current context. This includes generating URLs to other documents and changing contextes in-page. If this language is not available then the configured "Language Behaviour" of the application is responsible for eventually choosing other languages. The language behaviour is configurable as "Publishing option" on the application:

    • The default language behaviour is called "Static". It does not allow any other language than the one of the current context. This is to ensure integrity of language display per WebTML page, i.e. the page will only contain one language. The language can only be changed in-page by an explicit language choice on a WebTML context change, by using the "<language>"-Syntax in an context expression.

    • Another possible language behaviour is called "Dynamic". It always tries to find any language match that might make sense. If a resource is not available in the source context language it allows the following other languages:
      • The main context language (i.e. the language of the resource called by URL)
      • All browser-configured languages
      • The database default language
    • As far as possible this behaviour is also enforced when executing database queries. The queries return results for all possible language choices and then filter out the best choice per page. For performance reasons this is only possible on query types that only return content keys rather than complete documents. These query types are: "hql" and "lucene". On other query types only the "best" language is queried and also returned.

    • A third available choice is "No multi-language content". It is the behaviour that will automatically be chosen if an application has disabled multi-language content (see chapter below). It will only return contents in the databases default language. It should not be configured directly via publishing option. You should rather disable multi-language content for your OpenWGA design or manually per application as publishing option "Multiple languages contained".

Disabling multi-language content

The configuration of an OpenWGA design offers a checkbox called "Multi language content" which is checked by default. The same setting can be accomplished (or overridden) by publishing option "Multiple languages contained". Its point is to disable the multi-language behaviour of OpenWGA for certain applications that do not need it or even have trouble with it. For this you need to uncheck the design setting or set the publishing option to "false".

While these "non-multilanguage" applications still need a (single) language definition document in their OpenWGA content store to have content documents the disabled multi-language support will prohibit OpenWGA from interpreting this language as a real language code. Instead it will always return contents in this single language no matter what language might be requested either by browser configuration or WebTML source context. The content of this application is regarded "international". 

This has the following further implications:

  • The default language that must be configured on multi-language applications will not need to be configured here. OpenWGA will automatically find the language that is defined and use it.
  • URLs that are generated for this application will have "int" (for "international") as language identifier, no matter what the real language code of the language definition might be

Disable multi-language support for applications when the following conditions match:

  • Your application only holds one language definition or no language definition (and therefor no content) at all
  • You want to serve content or designs from this database no matter what language might be requested

WebTML labels language choice

A language choice not yet treated is the choice of a language in WebTML design itself, which currently only involves WebTML labels. On WebTML labels language choice is evaluated for each and every single label requested, as the languages in which labels are available may differ between individual label keys just as they may differ between individual pages.

In an OpenWGA application with enabled multi-language support the choice of WebTML labels will closely adhere the language behaviour that is also configured for contents. So on "static" language behaviour it will only allow the language of the current context. On "dynamic" language behaviour it will try the same other choices that are valid for content documents.

In an OpenWGA application with disabled multi-language support however WebTML labels still may be available in multiple languages, even if the contents of the application is not. Therefor OpenWGA here compares browser-configured languages with available labels, choosing the best match.

The administrator has some ways to customize this behaviour via publishing options:

  • An option "WebTML labels force language" may be configured to force the display of WebTML labels always in the same, preconfigured language. This prevents mixed label display.
  • An option "WebTML labels fallback language" may be configured containing a language that OpenWGA should choose when there is no label available for the other valid language choices. If this option is not configured it defaults to "en" (english language) on applications with "dynamic" language behaviour or with disabled multi-language behaviour. On application with "static" language behaviour there is no default meaning there is also no label fallback language.

Changing contexts between applications

A special situation is when an OpenWGA application changes the context into the OpenWGA content store of another application. This may be done by simply querying this other application or by explicitly running a context expression that points to the far database.

When OpenWGA now selects contents from this far database it has to choose which language behaviour is in charge, either the one of the "calling" OpenWGA application (the one whose design holds the current executing WebTML/TMLScript code) or the "target" application whose content store is addressed. The following rules apply:

  • If both applications have multi-language support enabled then the language behaviour of the "calling" OpenWGA application is in charge. This is to keep the integrity its the configured language display behaviour.
  • If one of these applications has multi-language support disabled then the language behaviour of the "target" application is in charge. In either case the language behaviour of the calling app is not transferable to the the target app.


Including designs from other applications

Another special situation is when an OpenWGA application includes the design of another OpenWGA application. By doing this the calling application effectively hands over control to the called application. This is why language choices in this situation exclusively use the language behaviour of the called application.