Matt, The i18n process can be "interesting". This particular project has lots of different views(pods) that can be put into many places so each event can have all kinds of different views accumulated and there's no one bundle that makes up all the views in a given event. Which is why we have a different properties file for each view and it's loaded into request scope (hence the preView event usage I was originally talking about)... Plus it's one install of the app so it has to allow for dynamic switching of the locale.
An event might say: Event: dashboard -view: search -view: task list -view: project tree -view: recent contacts Etc. etc. Event: showProjects -view: search -view: task list -view: project list So on and so on. I figured that I can't really do a bundle for each event... Who knows what the event might need. But a view knows what it needs. Loading the whole friggin thing into app scope could be putrid because there are hundreds of views (RAM issues). The request scope was so natural for each view and didn't involve any issues other than a lot of files but it was fairly simple to manage. I will be very interested to see the structure of boardfusion and MachBlog. Anywho... Thanks for the great insight. :) -greg -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Woodward Sent: Tuesday, May 23, 2006 5:28 PM To: [email protected] Subject: Spam:*****, Re: [CFCDev] Re: MachII Plugin... On 5/23/06, Greg Brown <[EMAIL PROTECTED]> wrote: > > > Peter, > > Sounds like you're loading all the bundles into the app scope at startup? If by "all the bundles" you mean all related to a particular language, then yep, that's what we're doing. In other words in our case we limit the blog to run in a single language, and the RB for the language is loaded at application startup. If you needed to be able to switch languages on the fly you could load all the bundles, just realize on big apps you might be using a fair amount of RAM. > That's probably workable and would eliminate the need for view > specific files. Seems to me if you're doing language-specific view files that quickly becomes a maintenance nightmare. Much easier to use RB tools and just manage the RBs and have a single view that just reads in the appropriate data from the RB. > this would load a page like this: > > <cfscript> > request.properties["someString"] = "Hoyven Mayven pickle matrix"; > request.properties["someOtherString"] = "All work and no play."; > </cfscript> Ah, OK--I see what you're doing now. Still seems to me that having multiple views wouldn't be the way to go. Using RBs for everything would mean you just have a single view and adding another language is as "easy" (relative term of course) as adding another RB. I'm by NO means an i18n expert but I'm learning a ton about this from Paul Hastings who's a big part of the BoardFusion project (http://www.boardfusion.org). This app is also Mach-II and with Paul's help it's i18n by design, so once it's done it should provide a good example of how to approach these issues. MachBlog will come a lot sooner than BoardFusion but definitely won't be as complete/correct from an i18n perspective on day one. Matt -- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
