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: [email protected] > > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > > Searchable archive: > > http://www.mail-archive.com/[email protected]/ Dev site: > > http://dev.catalyst.perl.org/ > > _______________________________________________ > List: [email protected] > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
