I'm trying to get a basic locals sub directory system working on Nginx:

/entry - en local. /fr/entry - french translation. /it/entry ect..

Having read this knowledge base article and some other forum posts I'm still having difficulties with 404 errors when following them or duplicate '/fr/fr'/entry issues.

Do I need to use duplicate index.php files with locals declared in them if I'm adding url paths in the section admin pages? What about site baseUrls in the config file?

The documentation seems very conflicting in these cases and having tried nearly every possible configuration option my site still won't serve up different locals.

I've had the most luck with this nginx config, together with specifying the local in the section urls in the cms for each section.

server {
    listen 80;
    server_name site.com;
    root /sites/site/public;
    index index.php;
    client_max_body_size 30M;
    location /en/ {
            root /sites/site/public;
            if (!-e $request_filename) {
                    rewrite ^/(.*)$ /index.php?q=$1 last;
    location /ru/ {
            root /sites/site/public/ru;
            if (!-e $request_filename) {
                    rewrite ^/(.*)$ /ru/index.php?q=$1 last;
    location /zh/ {
            root /sites/site/public/zh;
            if (!-e $request_filename) {
                    rewrite ^/(.*)$ /zh/index.php?q=$1 last;
    location / {
            root /sites/site/public;
            if (!-e $request_filename) {
                    rewrite ^/(.*)$ /index.php?q=$1 last;
    location ~ \.php$ {
            try_files $uri =404;
            fastcgi_split_path_info ^(.+\.php)(.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include fastcgi_params;
            fastcgi_ignore_client_abort on;
            fastcgi_param  SERVER_NAME $http_host;

    location ~ /\.ht {
            deny  all;

(each index.php has its own set local var within it like so for fr):

// Path to your craft/ folder
$craftPath = '../../craft';

// Tell Craft to serve the local site
define('CRAFT_LOCALE', 'fr');

// Do not edit below this line

My General config is


 * General Configuration

return array(
    'siteUrl' => array(
        'en' => 'http://www.site.com/',
        'ar' => 'http://www.site.com/ar/',
        'es' => 'http://www.site.com/es/',
        'fr' => 'http://www.site.com/fr/',
        'hu' => 'http://www.site.com/hu/',
        'it' => 'http://www.site.com/it/',
        'ru' => 'http://www.site.com/ru/',
        'zh' => 'http://www.site.com/zh/',
    'maxUploadFileSize' => 2147483647,


This results in the server displaying the correct links to my localised articles in the menu and the en language serves up entries correctly, however other languages are found at /local/local/entitypath not local/entitypath.

Adding site_urls to my config seems to break things more, causing locals to not be served up at all.

  • As per buildwithcraft.com/help/localization, what do you have in /craft/config/general.php and /ru/index.php, /zh/index.php etc files? Commented Jul 8, 2014 at 22:40
  • Sorry, updated with more information, thanks.
    – Darren
    Commented Jul 9, 2014 at 23:27
  • Hi @user2556299! Would you mind accepting the answer that ended up being the most helpful? If there hasn't been an answer that solved your problem, it might help to update your question.
    – Matt Stein
    Commented Aug 20, 2014 at 15:30

2 Answers 2


When you are following the each-locale-gets-its-own-index.php-file pattern as outlined in the official KB article, “How do I show localized content on the front end?”, then you do not need to include the locale ID in your sections’ Entry URL Format settings.

For example if you have a News section, and you want Arabic entries to get URLs that look like:


Then the Arabic Entry URL Format should just be this:


not this:


Everything leading up to “news/{slug}”, including “ar/”, is handled by your Arabic site URL, as defined in your config/general.php file’s siteUrl setting:

'siteUrl' => array(
    'en' => 'http://www.site.com/',
    'ar' => 'http://www.site.com/ar/',
    // ...
  • I think we posted an answer at the same time... Commented Jul 10, 2014 at 0:23
  • Thanks Brandon, I thought as much but couldn't see it documented anywhere. Is there any advantage to using one approach over another? I know that some elements of the site (such as my news feed) won't be translated so is craft able to fall back to a master local if there isn't a version in the users preferred local available? I was also hoping to take a guess at the users local from their ip address and redirect them to the site for their language.
    – Darren
    Commented Jul 10, 2014 at 0:24
  • @AndreaDeMers SE says I beat you by 16 minutes :) Commented Jul 10, 2014 at 0:25
  • @user2556299 Which approaches are you referring to? The way outlined above is what pretty much everyone has done to date, that I know of. As for your other question – probably best to ask that as a separate question as the answer will be pretty involved. Commented Jul 10, 2014 at 0:27
  • I was refering to specifying the url in each section per local in craft over using the php method and specifying the local via PHP - obviously the php way seems less effort but I don't really understand why it is in the CMS if everyone just uses the the PHP override.
    – Darren
    Commented Jul 10, 2014 at 0:32

When you write:

I've had the most luck with this nginx config, together with specifying the local in the section urls in the cms for each section.

Are you referring to:

enter image description here


If so, and you put the locale, in this case: fr_ca/a-apropos, try removing fr_ca.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.