On 2/24/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > I am probably wrong, but without spending too much time on it (and more > buying time until Howard can come in and correct me) I believe that you more > or less ~have~ to have your global il10n properties file match your > application specification file name. (Like pages and components do) . > > There is a property you can configure (in your web.xml servlet init param ) > > "org.apache.tapestry.application-specification" > > Which is a string path to locate your .application file. So, if you had an > application file named " petstoredemo.application" , your global il10n > properties file would need to be named "petstoredemo.properties" . (for your > default locale, "petstoredemo_fr.properties" for francais, etc...) > > Of course I am probably completely wrong, but that's what it looks like so > far. If the functionality was taken out I'm sure it was an oversight, or > just not known that it was needed. > > What is the "use case" more or less for renaming the file? To follow another > convention someone already has in place?
I'd prefer to name it whatever I like - for instance, with Struts this file is commonly named ApplicationResources.properties. With Spring MVC, it's commonly named messages.properties. While neither of these frameworks have a default file name, both of them allow you to customize it to whatever you want. I'd prefer to leave my files named ApplicationResources.properties so Tapestry is easier to learn for Struts users. I tried setting "org.apache.tapestry.application-specification" as an init-parameter, but if I do this, I have to change the name of my .application file as well. I tried using the following, but that didn't work either: http://wiki.apache.org/jakarta-tapestry/UsingCustomResourceSourceForLibs Here's the jist of what I'm looking for - and while Howard says it's "fixed and fixed well" - I have a hard time believing that unless the name is customizable. Here's my original desire. http://issues.apache.org/jira/browse/TAPESTRY-229 My guess is using a different filename is already possible, just not documented. Thanks, Matt > > Unless Howard either says I'm completely wrong and here is how you do it, or > says that he doesn't think this is a necessary feature, I don't see any > reason why a JIRA post couldn't make this happen in 4.0.1. > > P.S. Does this apply to .component and .page specifications as well? They > all share a lot of the same infrastructure > (application/library/page/component) for defining these > things, just wondering which pill I'm looking at ;) > > j > On 2/24/06, Matt Raible <[EMAIL PROTECTED]> wrote: > > Yeah, I saw that. I like this feature and think that smart defaults > > are cool - however, I'd like to override this and specify a different > > name. Is that possible? > > > > Thanks, > > > > Matt > > > > On 2/24/06, James Carman < [EMAIL PROTECTED]> wrote: > > > Oh, and I got that information from here: > > > > > > > http://jakarta.apache.org/tapestry/UsersGuide/localization.html#localization > > > .namespace > > > > > > > > > -----Original Message----- > > > From: Matt Raible [mailto:[EMAIL PROTECTED] ] > > > Sent: Friday, February 24, 2006 11:46 AM > > > To: Tapestry users > > > Subject: Is it possible to do a global i18n bundle with Tapestry 4? > > > > > > In Tapestry 3.0.3, I was able to specify a global properties file > > > (i18n bundle) with the following: > > > > > > <property name="org.apache.tapestry.global-properties" > > > value="ApplicationResources"/> > > > > > > I tried doing something similar in Tapestry 4.0, but no dice. > > > > > > <DEFANGED_meta > key="org.apache.tapestry.global-properties" > > > value="ApplicationResources"/> > > > > > > Is it possible to do a global i18n bundle with Tapestry 4? > > > > > > Thanks, > > > > > > Matt > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
