Language Detection & URL Structure 2.0

[twiro]

I'm currently working on a major update of this extension and one of my main goals is to offer more flexiblity regarding frontend language detection and the possibilities to structure URLs.

While this extension always did a great job regarding how to manage and process multilingual content I often missed some flexiblity in the above-mentioned aspects and had to help myself with hacks to face the requirements of different scenarios.

Having just adopted the repo from Jens and working on a current project with quite specific requirements regarding multilingualism I thought it would be a good idea to avoid another short-time-hack and start working on a more robust solution that offers the desired flexiblity to cover the needs of all the use cases and scenarios I have faced over the last years.

The following comparison between 1.X and 2.X is mainly a first draft for documentation, but any feedback or additional ideas are welcome.

The other main goal I have for 2.X is more flexiblity regarding "redirecting" - will post a separate issue for that soon...

Version 1.X

Version 1.X relies on the following methods for frontend language detection:

1. detect language by URL Path (e.g /en/page/)
2. detect language by Browser Preferences (HTTP_ACCEPT_LANGUAGE)
3. fall back to default system language.

These detection methods are executed in chronological order - the first one returning a valid match with one of the registered languages will define the value of the $language -parameter.

Version 2.X

For version 2.X I'm planning to implement the following "language-detection-stack":

1. URL query string (e.g domain.com/page/?language=en)
2. URL Path (e.g /en/page/)
3. URL (Sub)Domain (e.g domain.co.uk/page/)
4. Cookie
5. Browser Preferences (HTTP_ACCEPT_LANGUAGE)
6. Fallback Language

Like in version 1.X these methods will simply be executed in chronological order - meaning you don't have to tell the extension how you set up your URLs (except for mapping domains in method 3) and you can also "combine" different methods if necessary (think of de.domain.com/?language=en)

1. URL Query String

While not the recommended way to build your multilingual URLs this method comes handy for debugging as it has the highest priority and therefore will overwrite any other language that might be defined in the url path or domain. Might be useful in some other scenarios too.

2. URL Path

The "conventional" and therefore default way to set up multilingual URLs for projects in Symphony CMS. This method will work as it did in version 1.X but will be extended to not only "understand" page paths defined in Symphony (or a routing extension) but also paths that rely on additional htaccess-rules - thus making it compatible with other extensions that tackle multilingualism.

3. URL (Sub)Domain

Besides using the URL path language-specific domains (domain.co.uk) or subdomains with gTLDs (de.domain.com) are considered the best options for structuring multlinguals URLs. A setting in the extension configuration will allow to map languages to domains or subdomains.

4. Cookie

Whenever one of the 3 "URL-methods" succesfully detects a language the language-code will be saved in a cookie. While this offers the possibility to serve multilingual content without a multilingual URL-structure (and use the cookie-value to get the current frontend-language) you seriously shouldn't do this. Instead the cookie is meant to be used for redirecting purposes only.

5. Browser Language

The method of analyzing browser-information to check if the preferred language of a visitor matches one of the configured languages already exists in version 1.X. Version 2.X will extend this method by not only analyzing the first 2 characters of the http_accept_language- header but the complete string. Meaning language detection will not immediately fall back to the default language if a visitors first prefered language does not match any of the configured languages but try to find a matching language in all of the visitors accepted languages.

6. Fallback Language

If none of the 5 methods above return a valid match the extension will fall back to the configured default language.