Paulo, Great to hear from you.
On Mar 13, 2008, at 1:27 PM, Paulo Jobim wrote: > Hi Scott > I have applied the changes made about an year ago, after a long > change of email in Manakin discussion lists, to dspace-xmlui in > dspace-1_5_x > these changes refer to problems in the search and browse that > happens when you continue a browse with more than one page of results. > I am aftaching the patches I made. > > There are still some issues in the submission aspect when you upload > a file with some UTF-8 accented characters. The name of the file > changes the encoding. Can you provide an example? What is the name of the file you are uploading? What is the contents of the file? > > There is also a serious bug in the JSPUI interface where browsing > anything from the first page takes about ten times more time than in > the XMLUI interface. > If you put a version of the JSPUI in your test site at tamu we could > see this delay because the other test sites have only small > collections to browse. > > I have a test instance here where you can compare any browse in the > front page of xmlui and jspui > another issue is that since your recent change in the language > system the locale is not beeing changed by the browser settings or > even appending ?locale=en to the URI > also in xmlui interface I miss the language attribute to the eperson > so the language can be changed according to the user (if available) Have you added "en" the the list of supportedLocales? The purpose of the parameter is to limit what locales are available in the interface. For example if you have a translation for a local but don't want it to be used then you omit it from the supportedLocales list. By default when you build manakin it will download the latest set of translations available and put them into your webapp. However just because they are there you may not what to let users use them because they you would have to maintain support for those translations in the future. SupportedLocales give the ability to limit what locales you support. I have added a patch which changes the default behavior of this parameter. Previously if it was not defined the only the default locale would be supported. I've changed it so that if it is not defined then any locale is supported. I think that should address your issue. > > Thanks > Paulo > < > artifactbrowser > .sitemap.patch.text><aspect.patch.text><structural.patch.text> As for the patches, what problem are you trying to solve. The search forms should be POST. Using GET will place the parameters in the URL string which is not what the user expects when the click a submit button. Individual aspects should not be changing the encoding for the request because this will effect all the other aspects in the chain. So, if the character encoding needs to be explicitly set the we need to do it outside of the aspect and make it part of the general framework. What is the problem you are trying to solve? There have bee some i18n patches specifically for non-us-ascii characters applied since beta1. Are you still seeing problems with these characters on a clean version after beta2? I just tested things here on several platforms and the character encodings were all correct. If you are still having problems please let me know and provide the following information: - What field is not presenting properly? - What browser/OS are you using? - What version of Tomcat are you using? - What characters don't work? are they in the latin character set (iso-8859-1) or in a higher set like UTF-8? Thanks, Scott-- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
