Project

General

Profile

Bug #2449

Updated by Alexander Watzinger about 2 months ago

I noticed at the demo versions that when an URL without language is provided that it gets redirected correctly, e.g. 

 https://frontend-demo.openatlas.eu/entity/2936 -> 
 https://frontend-demo.openatlas.eu/en/entity/2936 

 but then a page not found error is shown (tested with Firefox and Chromium). When refreshing the page it works. 
 For now I "fixed" it in the demo versions with adding the language part to the resolver URL in the backend so that at least the backend links aren't broken. 

 I tried the same at a different project (MAMEMS) but there it seems to work in general without a language part in the URL and there are no issues. 
 URLs without the language part should always work as expected because these are also provided with the citation button. 

 *Update* (in progress) 
 For the specific situation of using the (more) static deploy version (without the Node.js server) via Apache and using multiple languages for the presentation site (like in the demo versions) this could be solved with adding following to the Apache config. 
 <pre><code class="shell"> 
 <VirtualHost *:443> 

         ... 

         <IfModule mod_rewrite.c> 
                 # Already localized? do nothing 
                 RewriteCond %{REQUEST_URI} ^/(en|de)(/|$) [NC] 
                 RewriteRule ^ - [L] 

                 # Bypass static & API 
                 RewriteCond %{REQUEST_URI} ^/(assets|dist|_nuxt|static|img|images|css|js|fonts|favicon\.ico|robots\.txt|sitemap\.xml|api)(/|$) [NC] 
                 RewriteRule ^ - [L] 

                 # Fallback to English 
                 RewriteCond %{REQUEST_URI} ^/entity/([0-9]+)$ 
                 RewriteRule ^/entity/([0-9]+)$ /en/entity/%1 [R=302,L,QSA] 
         </IfModule> 

         ... 

 </VirtualHost> 
 </code></pre> 

 The available languages and the default language have to be adapted when needed. It's a simple approach that works. 
 See e.g. https://frontend-demo.openatlas.eu/entity/2936 
 More complex functionality might be possible (e.g. detecting cookies, browser settings, ...) but beside being way more work and need for testing just for a very specific scenario I'm also not convinced that these issues should be solved at the Apache config level.

Back