Bug #86205 for Catalyst-Plugin-I18N-PathPrefix: Fallback language without prefix?

Mon Jun 17 13:24:12 2013 jibrvi [...] gmail.com - Ticket created

Subject:	Fallback language without prefix?
Date:	Mon, 17 Jun 2013 19:23:56 +0200
To:	bug-Catalyst-Plugin-I18N-PathPrefix [...] rt.cpan.org
From:	jibrvi [...] gmail.com

Hi, nice plugin!! You stated that it is an ALPHA version, but it runs pretty good for me. I have a request (or maybe I do not know how to accomplish it). For Google SEO it should be great if the fallback language is just the default url, without language prefix. I am using uri_for(), so every link gets its language prefix: http://www.mysite.com/es/contact http://www.mysite.com/en/contact http://www.mysite.com/pt/contact But if the first, main, fallback language for the site is spanish, for example, it is cleaner without the prefix. http://www.mysite.com/contact http://www.mysite.com/en/contact http://www.mysite.com/pt/contact Surely I can do it building urls by hand in the templates, but everything is done with uri_for(), as it is said as a "good practice" in Catalyst. Regards: Ignacio

Thu Jun 27 16:17:41 2013 MENDEL [...] cpan.org - Correspondence added

On Mon Jun 17 13:24:12 2013, jibrvi@gmail.com wrote: Show quoted text

> But if the first, main, fallback language for the site is spanish, for > example, it is cleaner without the prefix. > > http://www.mysite.com/contact > http://www.mysite.com/en/contact > http://www.mysite.com/pt/contact

Hi Ignacio, C:P:I18N::PathPrefix does not support that functionality (yet?). But before going on with the discussion of how to accomplish that goal, I'd like to point out what it currently does if the URL contains no language selector path prefix (ie. the http://www.mysite.com/contact case). In that case it makes Catalyst::Plugin::I18N auto-detect the user language (using the Accept-Language HTTP header), and then uses either that language, or the fallback language if auto-detection fails or returns a language not in valid_languages. Then it fakes as if the original request contained that language selector path prefix (ie. as if it was http://www.mysite.com/XX/contact). I chose that behaviour because it deemed to be the most useful for our use-case: when a user first arrives at the site through some language-independent URL (most likely by just typing the domain name in the browser location bar), we have a chance to auto-detect his/her language. I also see your point, if auto-detection is not used, then omitting the default language from the path may make sense. Which sounds like a new configuration parameter to switch between the two behaviours. Now i just need some round tuits.. :-) or a patch from you. ;-) norbi

Thu Jun 27 16:17:41 2013 The RT System itself - Status changed from 'new' to 'open'