Answers.Body: <p>I think the issue is that your first <code>RewriteCond</code> only excludes the language prefix in the path with a trailing slash. The regex matches <code>/en/</code> and <code>/fr/</code>, but not <code>/en</code> and <code>/fr</code>. To fix this, make the trailing slash optional:</p>
  <pre><code>RewriteCond %{REQUEST_URI} !^/(en|es|de|it|fr)/?
  </code></pre>
  <p>As an alternative, we handle this on the application layer. On a site with a similar site setup, we have this in our main Twig layout file:</p>
  <pre class="lang-twig prettyprint-override"><code>{%- if craft.app.response.isOk and
      currentSite.primary and
      craft.app.request.fullPath|split('/')|first != 'en'
  -%}
      {%- redirect siteUrl(craft.app.request.fullPath) 308 -%}
  {%- endif -%}
  </code></pre>
  <p>This will redirect the primary site to the canonical URL if it's visited without the language prefix in the path. But it will <em>not</em> redirect any URLs that lead to a 404 page, which you can't do on the server.</p>
  <p>Having the redirect on the application layer makes it part of the business logic, instead of the infrastructure. Probably not advisable if you're experiencing high server loads, as redirecting through the server is more efficient.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-12-08T08:32:55.227Z
Answers.Text: This is a lovely solution, thank you. I never considered how the redirects might have an effect on error page templates. I will be going with the Twig solution 
Answers.UserDisplayName: Mark Notton
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-12-07T15:29:42.253Z
Answers.LastActivityDate: 2023-12-07T15:29:42.253Z
Answers.UserDisplayName: MoritzLost
Body: <p>I'm working on a Craft 4 project with five languages set up as separate sites. The primary site is configured to use 'en-GB' as the language and 'en' as the handle.</p>
  <p>Currently, when I access the home page of my site using <code>https://my-website.local/</code>, it correctly displays the English site. The same happens when I use <code>https://my-website.local/en/</code>.</p>
  <p>To avoid canonical issues caused by having duplicate pages under different URLs, I want to ensure that every page automatically includes the primary language handle ('en') in the URL, if one's not already present.</p>
  <p>I haven't found a setting in Craft CMS that allows for this type of redirection. It seems I might need to handle this via .htaccess. I tried the following configuration:</p>
  <pre><code>RewriteCond %{REQUEST_URI} !^/(en|es|de|it|fr)/
  RewriteCond %{REQUEST_URI} !^/(index\.php)
  RewriteRule ^(.*)$ /en/$1 [R=301,L]
  </code></pre>
  <p>However, this approach leads to an incorrect duplication in the URL, such as <code>https://my-website.local/en/en/</code> or <code>https://my-website.local/en/fr</code>, regardless of the RewriteCond conditions.</p>
  <p>Does anyone have experience with a similar setup or suggestions on how to properly configure the .htaccess file to achieve this without causing URL duplication?</p>
  <p><a href="https://i.sstatic.net/I6IkP.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/I6IkP.jpg" alt="Example Sites" /></a></p>
  
Tags: <localization><multi-site><htaccess>
Title: How to use the primary locale handle as a fallback in the url?
ThreadText: # How to use the primary locale handle as a fallback in the url?
  
  (Asked by: username_0 on 2023-12-07)
  
  I'm working on a Craft 4 project with five languages set up as separate sites. The primary site is configured to use 'en-GB' as the language and 'en' as the handle.
  
  Currently, when I access the home page of my site using `https://my-website.local/`, it correctly displays the English site. The same happens when I use `https://my-website.local/en/`.
  
  To avoid canonical issues caused by having duplicate pages under different URLs, I want to ensure that every page automatically includes the primary language handle ('en') in the URL, if one's not already present.
  
  I haven't found a setting in Craft CMS that allows for this type of redirection. It seems I might need to handle this via .htaccess. I tried the following configuration:
  
  ```
  RewriteCond %{REQUEST_URI} !^/(en|es|de|it|fr)/
  RewriteCond %{REQUEST_URI} !^/(index\.php)
  RewriteRule ^(.*)$ /en/$1 [R=301,L]
  
  ```
  
  However, this approach leads to an incorrect duplication in the URL, such as `https://my-website.local/en/en/` or `https://my-website.local/en/fr`, regardless of the RewriteCond conditions.
  
  Does anyone have experience with a similar setup or suggestions on how to properly configure the .htaccess file to achieve this without causing URL duplication?
  
  [![Example Sites](https://i.sstatic.net/I6IkP.jpg)](https://i.sstatic.net/I6IkP.jpg)
  
  **Tags:** localization, multi-site, htaccess
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-12-07. Score: 2 | Accepted answer
  
  I think the issue is that your first `RewriteCond` only excludes the language prefix in the path with a trailing slash. The regex matches `/en/` and `/fr/`, but not `/en` and `/fr`. To fix this, make the trailing slash optional:
  
  ```
  RewriteCond %{REQUEST_URI} !^/(en|es|de|it|fr)/?
  
  ```
  
  As an alternative, we handle this on the application layer. On a site with a similar site setup, we have this in our main Twig layout file:
  
  ```twig
  {%- if craft.app.response.isOk and
      currentSite.primary and
      craft.app.request.fullPath|split('/')|first != 'en'
  -%}
      {%- redirect siteUrl(craft.app.request.fullPath) 308 -%}
  {%- endif -%}
  
  ```
  
  This will redirect the primary site to the canonical URL if it's visited without the language prefix in the path. But it will *not* redirect any URLs that lead to a 404 page, which you can't do on the server.
  
  Having the redirect on the application layer makes it part of the business logic, instead of the infrastructure. Probably not advisable if you're experiencing high server loads, as redirecting through the server is more efficient.
  
  > **Comments:**
  > **username_0**: This is a lovely solution, thank you. I never considered how the redirects might have an effect on error page templates. I will be going with the Twig solution   
  
  ---
  
  