Pages

Pages can have multiple localizations.

There should be a global application in the app which allows the users to specify auto-generation of localizations — all localizations for all pages — or if they want to specify localizations on a page by page basis.

In the second case, this allows users to create pages specific to a particular locale/dialect. For example legal notices for one particular territory.

Internationalization vs. Localization

There are two main concepts to deal with when localizing an application. They are internationalization and localization. They are similar but different.

Internationalization simply means translating text to a particular language. Localization — which is more complicated — means customising content for a particular location. This goes beyond language, since locations that may share a language nonetheless need to see different content.

When setting up the application there is a choice between having the site contents organised by language alone, or by locale, which may also include multiple languages. Because these are conceptually different it’s worth noting that it complicates the implementation and behaviour of application slightly.

Locales

An example; Australia and New Zealand both primarily use English in spoken and written communication. However in many cases and English translation alone won’t do, since the actual content on a site may need to differ. Consider any legal requirements that may differ between the two, or perhaps idioms that are culturally specific.

What we need is content for each particular location. Localization is essentially tailoring content — and language if necessary — to a particular location. Localization may also involve multiple languages. Consider locations with bilingual groups, say Spain, which has large populations of both Spanish and Catalan speaking people. Localizing for Spain means creating and translating content for two languages.

Localization can be even more narrow. An Australian company may choose to localize content based on state — imagine a competition, which falls under different state laws.

Fallbacks

Often when localizing there will be content that can be easily shared across locales. This might include biographical or historical information which doesn’t need to change, since it’s not specific to a particular locale.

To enable this we need to be able to specify which locales to fall back to. This can be quite broad — across an entire locale — or more specific — just a specific page.

Languages/Dialects

These are stored in their own table in the DB. They specify the languages available for the site. In the simple case of internationalization, they allow us to select the appropriate language to display and make it easier to error or fallback to a default when an unavailable language is requested.

In the more complex case of localization, the dialect records are actually ignored since we’re choosing the records to present based the combination of language and locale.

Page Localizations

When in either internationalise or localise mode, each page has to be translated. This means the title and slug — the part of the URL indicating this page — can be customised for each.

Translations of the actual content are than attached to this PageLocalization.

Content Blocks and Translations

The actual content of each page is assembled from content “blocks”. These blocks may actually be any arbitrary class. The properties that distinguish a content block; it belongs to a page, it has translations which belong to page translations and it conforms to the block API. The last is achieved by mixing in the content block module, which includes methods and properties which allow the class to be ordered, updated and manipulated without custom code.

The actual language for the block translations isn’t specified directly, instead it’s implied via the page translations, which belongs to a language. This is done to make queries much simpler.