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

<?php

/**
 * 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? – Andrea DeMers Jul 8 '14 at 22:40
  • Sorry, updated with more information, thanks. – Darren Jul 9 '14 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 Aug 20 '14 at 15:30
up vote 4 down vote accepted

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:

http://www.site.com/ar/news/my-entry-slug

Then the Arabic Entry URL Format should just be this:

news/{slug}

not this:

ar/news/{slug}

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... – Andrea DeMers Jul 10 '14 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 Jul 10 '14 at 0:24
  • @AndreaDeMers SE says I beat you by 16 minutes :) – Brandon Kelly Jul 10 '14 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. – Brandon Kelly Jul 10 '14 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 Jul 10 '14 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 acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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