Pascal, It should not be to hard to create an outer Join form between the "User" form and the "AR System User Preference" form so that you can do a one time back fill of any missing records. (And keep the join around.. "one time things" tend to end up being handy more than once. :) Then as you say you could add workflow (on submit to the "User" form) that would auto create the "AR System User Preference" record.
As far as the Login page goes.... I think the requirement is to always use a specific local. So ... If you have already customized the login.jsp then I would suggest that you simply break the look ups as you do not want to be tied to any session variable changes that BMC makes in the future and you likely already have your own look and feel that you want to use anyway. (Which will likely not change at the same release cycle as BMC's patch maintenance of the Mid-Tier. :) Or you might poke around in the session variables and see if you can find where the local is being set. Then simply override the value by hard coding it to the "correct string" ( that should be a one line change ) and leave the rest of the page alone. I guess if you wanted to get really tricky... you might try this... (But this may break the users ability to use any local other than English even with a preference record change too.) Alter the mapping of locals in the <mid-tier_install>/WEB-INF/classes/locale.properties file. Or for that mater you could simply replace all of the <mid-tier_install>/WEB-INF/classes/LocalizedMessages* files with the content from the LocalizedMessages_en.properties file. (That should prevent the system from having different strings for any standard message for any locale that the user is using.) However, it may not prevent the system from displaying OOB Application Error messages in different locals. (But that my be ok... it all depends on your needs.) Personally I think that overriding the Login page is the best idea. I would even think that if you already have workflow that builds the "AR System User Preference" at user login, then you could also present the user with a message and tell them that they need to "Login again" because their account was not setup correctly, but has been corrected now. It seems like a small, one time price to pay. (or build the workflow on Submit to User. Either should work. Some might find one or the other more appealing.) Maybe one of those ideas help. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Thu, Jul 31, 2008 at 5:16 AM, Tournier, Pascal <[EMAIL PROTECTED]> wrote: > Hi thanks for your response, > > Changing the locale to "en_US" in the User Preference records will > effectively force the language in English... > > But assuming that there is one newly created user who is connecting ARS > via the Web. The user do not have yet one entry in the AR System User > Preference form. I create a workflow so that this entry is automatically > created when he get connected the first time and also set then the > locale to en_US. But this change will only be taken into account the > next time he is logging. Until then the language will still be the one > defined in the browser. So I assume that I should change that and > automatically create this entry in the User Preference when a new user > is created in the user schema ? > > Furthermore, even if the locale is set to "en_US" for all user, when we > get access to the login page (login.jsp), this page is also set to the > one defined in the browser (French in my case) and I will also enforce > this page to be in English. > > Do you have any idea on how to fix both problem ? > > Thanks & Regards > Pascal > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black > Sent: Wednesday, July 30, 2008 3:04 PM > To: [email protected] > Subject: Re: Force Language settings to English > > Pascal, > > I am not sure what you meant by "default directly on the server > itself"... but I am sure that if you tried hard enough you could find > the JavaScript that the browser is using to determine the language > that the browse is using and then short cut it to always return the > right value for "English". > > However, I think a much more sustainable approach is to add User > Preference records for all of your users and set the Language settings > there. This way you maintain the data and do not have to much with the > vendor supplied code at all. ( And set your Mid-Tier to use the > preference server where your maintaining that data. I also have to > mention that I HOPE that the preference record setting would be used > over any browser detection value, but I have not verified that > behavior.) > > Hope that helps. > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > > On Wed, Jul 30, 2008 at 6:49 AM, Tournier, Pascal > <[EMAIL PROTECTED]> wrote: >> ** >> >> Hi, >> >> >> >> We have recently migrated to Remedy ARS version 7.0.1 on HP UNIX and > wanted >> to go to the Web access interface via Mid-tier. My question concern > the >> language settings, is there a way to force the locale language to > English... >> >> >> >> If I'm using Firefox for example, ARS is taking the language > configured for >> the browser, so the login page is in french in my case and also for > each >> form the web tool bar associated is also in French.. I have noticed > that we >> can change this settings per user in the "AR System User Preference" > schema >> but I was wondering if we can setup that per default directly on the > server >> itself so that only English is used independently from the browser > language >> settings. >> >> Thanks >> >> Regards _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
