[Catalyst] [Absolute Beginner] Navigation Q Part II i18n and URIs

[Ekki Plicht (DF4OR)]

Thanks  Mike, that looks promising. But as of now I have problems getting I18N 
to work at all. See other message.

Cheers,
Ekki


Am Samstag 21 August 2010, 16:43:09 schrieb Mike Raynham:
> Hi Ekki,
> 
> I'm quite new to Catalyst too, and purely out of curiosity, I have
> recently been looking into I18N.  I thought that you might find
> Catalyst::Plugin::I18N::Request useful - it might be just what you are
> after.
> 
> Regards,
> 
> Mike
> 
> Ekki Plicht (DF4OR) wrote:
> > Hi Robert,
> > your comments were most helpful, many thanks!
> > 
> > As it is so often - after sending the message I did some more thinking
> > and started to realize that my approach - starting with the controller -
> > is probably not the best way to design this app.
> > And your comments encourage me that I have to think about the model much
> > more and probably first.
> > 
> > What do you charge for a day of consulting? :-) It's time that I visit
> > Hamburg again...
> > 
> > 
> > Some details from your reply:
> > 
> > Am Samstag 21 August 2010, 00:46:14 schrieben Sie:
> >> Some things to consider:
> >> · Should the user be able to override the language?
> > 
> > Of course.
> > 
> >> · Do you want to separate language by domain or URI part?
> > 
> > URI part or parameter, undecided.
> > I have never done this until now, but I want to extract the preferred
> > language from the header, if set and if supported. If not an app wide
> > default kicks in, which the user can override later on, this override
> > value is persistent by a cookie, session racking or some such.
> > 
> >> What would happen if someone who only accepts DE as language requests
> >> the EN page?
> > 
> > Customer is king, she gets what she wants.
> > 
> >> Browser language detection is pretty easy with the I18N
> >> plugin, but the implementation of the language logic is dependent on
> >> what you want to happen.
> > 
> > I will look at that, tnx.
> > 
> >> Both the language and the article to display are variables in the
> >> process of displaying the page. The language can come from a cookie, the
> >> browser language setting, a query parameter, the domain name, a part of
> >> the URI, or multiple of those using the first it can find.
> >> 
> >> I'd always advise to build the actual business logic of the application
> >> outside of the web front-end.
> > 
> > Absolutely, that's why I decided to go with Catalyst :-)
> > 
> >>> What I am envisioning is a central file where I (somehow, XML?,
> >>> database?) maintain a navigation tree (ok, 5 or more), mapping menu
> >>> entries to URIs. Some process then maps these entries to actions. But
> >>> how?
> >> 
> >> As a model. Look at Config::Any (already used by Cat) for loading of
> >> configuration files. For a database model I'd point you towards
> >> DBIx::Class, but mostly because of community-size and personal
> >> preference. There are other solutions, but I feel it is a good start.
> > 
> > Yes, I am already working through some light weight examples with
> > DBIx::Class, that's most likely the way to go.
> > 
> > 
> > [...]
> > 
> > And all the rest, as I said helpful. Many thanks.
> > 
> > Gruß,
> > Ekki
> > 
> > _______________________________________________
> > List: Catalyst at lists.scsys.co.uk
> > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > Searchable archive:
> > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site:
> > http://dev.catalyst.perl.org/
> 
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/