This will be up to developers to determine, based on their needs. For instance, are you going to provide subdomains for each language, or is it going to just be subfolders used to organize the tree? These kinds of questions need to be answered in order to determine how you are going to "switch" contexts, or even if you need contexts (using subfolders wouldn’t require having separate contexts, though you may want to isolate the content and settings this way anyway). You could use a plugin to detect the subdomain from the http_host setting, or a particular subfolder in the requested URL, and switch to a particular context based on that information. Or you could create physical subfolders with custom index.php files in each one to prevent loading the main ’web’ context on each request and then switching (i.e. directly initialize a particular context).
But then how do I provide a link to switch between the contexts I created? How to find the URL of the page corresponding to the current one in the new language? The documentation doesn’t seem to explain this part yet.
You could use a plugin to detect the subdomain from the http_host setting, or a particular subfolder in the requested URL, and switch to a particular context based on that information. Or you could create physical subfolders with custom index.php files in each one to prevent loading the main ’web’ context on each request and then switching (i.e. directly initialize a particular context).Can you elaborate on that? Which solution is the best?
This is managed by Content Type in Revolution. The suffix and prefix from Evo are no longer applicable and are retained there only for the interest of migrations.
(BTW, is there a way to remove the ".html" suffix? I changed the corresponding system property with an empty string, but it doesn’t seem to have any effect)
Which is best really depends on your hosting situation. For instance, if you have full control of a dedicated server or VPS, and need more scalability for a large volume of traffic, then using custom index.php’s that directly invoke a specific context will be your best option. This customization is as simple as copying the index.php in the root directory to an fr/ folder and changing the call to $modx->initialize(’web’) to $modx->initialize(’fr’), though you will also need to copy the config.core.php file and make sure the values are correct for the new location. A quicker and less complex solution would be to have a plugin which detects the requested subfolder and switches to the appropriate context from the main ’web’ context.
You could use a plugin to detect the subdomain from the http_host setting, or a particular subfolder in the requested URL, and switch to a particular context based on that information. Or you could create physical subfolders with custom index.php files in each one to prevent loading the main ’web’ context on each request and then switching (i.e. directly initialize a particular context).Can you elaborate on that? Which solution is the best?
And what about finding the corresponding translated node/URL ?
This is managed by Content Type in Revolution. The suffix and prefix from Evo are no longer applicable and are retained there only for the interest of migrations.Ok, I see.
Which is best really depends on your hosting situation. For instance, if you have full control of a dedicated server or VPS, and need more scalability for a large volume of traffic, then using custom index.php’s that directly invoke a specific context will be your best option. This customization is as simple as copying the index.php in the root directory to an fr/ folder and changing the call to $modx->initialize(’web’) to $modx->initialize(’fr’), though you will also need to copy the config.core.php file and make sure the values are correct for the new location.I’ll try this solution, as I don’t know how to write a plugin yet. If I understand correctly, I’ll also have to change my rewrite rules in .htaccess to map the virtual language folders to the physical ones?
As for linking related nodes across translations, there is nothing built-in for this in 2.0. Again, this depends on your needs and I expect that several solutions to this will materialize as developers implement similar solutions. This could be as simple as creating a TV on the main page which has a comma-delimited list of translated nodes (and possibly a second TV on the translations that point back to main node), or as complex as creating a custom table to map the relations explicitly.Thanks for the hints. I’ll post back here once I’ve made all this stuff work
Once we get to our initial RC releases of Revolution, I’m sure we will be providing sample solutions for these issues. For the time being, your exploration of the subject is a pioneering effort, though greatly appreciated.
Good point; actually, it may be better to leave the rewrite rules alone for now. We should focus on solving the problem, and then optimizing in this case. You need a plugin to detect the first segment of the requested URL, which will be rewritten into the $_GET[’q’] variable (though ’q’ is configurable in Revolution via $modx->getOption(’request_param_alias’)) when using friendly_urls with mod_rewrite. A plugin like this might be used to do the context switching, assigned to the OnWebPageInit event:
I’ll try this solution, as I don’t know how to write a plugin yet. If I understand correctly, I’ll also have to change my rewrite rules in .htaccess to map the virtual language folders to the physical ones?
<?php $lang = 'en'; $pos = strpos($_GET[$modx->getOption('request_param_alias')], '/'); if ($pos > 0) { $lang = substr($_GET[$modx->getOption('request_param_alias')], 0, $pos); } switch ($lang) { case 'fr': $modx->switchContext('fr'); break; default: // by default, don't do anything break; } ?>
In the same plugin, set the locale; the top-level container in the tree represents the language, so once you detect the top level parent, you know the language. This is no different than in 0.9.x/1.0 (aka Evolution).
If I don’t use contexts then how do I associate a language/locale to a sub-tree? I still need this for the translated chunks that use lexicons -- at least.
setlocale(LC_ALL, ...)