I’ve recently taken a deep dive into multilingual site building. The site I’m working with is a simple brochure site, http://mezzaninetulum.com/. The site uses content translate, and the i18n module to help with menu and path translation. The setup was fairly straight forward to get the node translation in place. However. there were a few issues with multilingual menus and path.
The issue that we identified with the menus was different language detection rules for administration and content and was a quick fix. The path translation was a stickier issue. Paths generated by Path Auto inherit the language of their node. If your language is detected as English and you try to load a non-english URI you get a 404. The issue was resolved by a custom module which changes the behavior of Path Auto and set the language of the generated Paths to All. I do not feel enabling/disabling paths/URL Aliases based on a detected language is a good practice.
Here are my expectations of how the path system should work. Let’s take an example from the mezzanine site.
Given:
Detected Language: EN
node:2 english language Accomodations Page
node:3 spanish language Accommodations Page, Hospedajes
node:2 and node:3 are in a translation set.
URL Alias /accommodations redirects to node:2 for all languages.
URL Alias /hospedajes redirects to node:3 forspanish.
When Requesting URL Path /accommodations Then I expect to see node:2
When Requesting URL Path /hospedajes Then I Expect to see node:3,
and for the detected language to be set to ES for this page load.
This can be facilitated by replacing the path translation functionality with a Path Language Provider. The process is complicated a little bit because the core Path module is language aware, so a custom path look up must be used.
function path_language_provider_language_info() {
return array( 'path_language_provider' => array( 'callbacks' => array(
'language' =>'path_language_provider_callback_language',
'switcher' => 'path_language_provider_callback_switcher',
'url_rewrite' => 'path_language_provider_callback_url_rewrite' ),
'name' => t('Path Language Provider'),
'description' => t('Sets the language based on the language of the current URL alias'),
'cache' => 0
);
}
function path_language_provider_callback_language($languages) {
$query_args = array(':alias' =>$_GET['q']);
$result = db_query("SELECT language FROM url_alias} WHERE source = :alias",$query_args);
return $result->fetchField(); //TODO: Switcher and URL Rewrite callbacks.
}
I think this calls for some rethink of the core Path module and how it implementslanguage awareness. I believe the core Path module should store a language, but not filter on language by default. It should be able to tell me the language for a given URL Alias (potentially even all URLS), It should be able to give me all the language alternates for a URL and the specific alternate if given a URL and target language. If you’re interested in supporting furthering work in this direction please contact me.