Hopeless. Attachments are available here: http://www.jeanjean.ch/lift/0001-POM-Fix-test-plugin-dependency-problem-org.scala-too.patch http://www.jeanjean.ch/lift/0002-PROBLEM-Reproduce-the-resource-filtering-problem.patch http://www.jeanjean.ch/lift/0003-FIX-A-solution-is-to-use-a-distinct-path-for-filtere.patch http://www.jeanjean.ch/lift/0004-OK-Excluding-src-main-resources-filtered-directory-f.patch
On Dec 11, 11:50 am, Jean-Adrien <jean.vauc...@gmail.com> wrote: > Hello, > > Sorry for the delay. > I worked a bit on the issue, and, in order to reproduce, I propose to > generate a lift-basic from scratch and to apply some patches: > > $ mvn archetype:generate -U -DarchetypeGroupId=net.liftweb - > DarchetypeArtifactId=lift-archetype-basic -DarchetypeVersion=1.1- > SNAPSHOT -DremoteRepositories=http://scala-tools.org/repo-releases- > DgroupId=liftgroup.rsctest -DartifactId=rsctest -Dversion=0.1-SNAPSHOT > > Note that in my case (I mirror all the remote repos, and therefore I > bypass repos declared in poms), I have a dependency problem with > test dependency org.scala-tools.testing:specs because I can't find a > transitive dep: javax.script:script-js:1.0 > I found 1.1 here > :http://developer.jasig.org/repo/content/groups/m2-legacy/javax/script... > but that's all. Anyway, my first patch disable the tests and the > problematic dependency: > > 0001-POM-Fix-test-plugin-dependency-problem-org.scala-too.patch > > In order to reproduce the problem, I create a translation properties > file, and setup simple localisation. > I ask maven to filter my resources in order to allow > HelloWorld.version snipet to dump the current webapp version > > 0002-PROBLEM-Reproduce-the-resource-filtering-problem.patch > > Build and run the project, and you can observe > 1) The version number in the page footer > 2) The French version of the page has a char encoding problem, as > explained, it comes because maven filters the translate_fr.properties > file using UTF-8 encoding, but this one is encoded with ISO-8859-1 > [http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html] > > 0003-FIX-A-solution-is-to-use-a-distinct-path-for-filtere.patch > > A solution to have both features working is to use distinct > directories for filtered and non filtered resources. > But another problem happens in this case: The yuicompressor:compress > goal erases the filtered resources (why ?) > Test it : > $ mvn clean resources:resources > It creates target/classes/filtered/other.properties with the correct > content > then > $ mvn yuicompressor:compress > It ereases the content of the file > > Since yuicompressor:compress is binded in the build lifecycle, the mvn > package result makes the version number feature not working > > 0004-OK-Excluding-src-main-resources-filtered-directory-f.patch > > I exclude the filtered directory from yuicompressor. And both version > number and encoding features work > > = Conclusion = > > The problem here comes from my initial configuration. But in my sense > it is not a good idea to store i18n data in another format than UTF-8. > Maybe lift should not use java.util.Properties to handle i18n strings. > Moreover keys in properties file does not allow spaces, and the > feature to use S ? "a key with space that will be used as a default > value" does not work. Another approach would be to use > java.util.Properties in its xml form: > <entry key="key">value</entry> > this one supports UTF-8, but once can find it too versatile. > > ... Now I hope it is possible to attach my patches ... > > Have a good day. > > -- Jean-Adrien > > On Dec 8, 3:44 pm, Indrajit Raychaudhuri <indraj...@gmail.com> wrote: > > > On Dec 8, 7:31 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote: > > > > On Tue, Dec 8, 2009 at 6:27 AM, Indrajit Raychaudhuri > > > <indraj...@gmail.com>wrote: > > > > > Good catch! I'll take a look. > > > > > Jean, can you please send a zip of your project (just enough to recreate > > > > the scenario, no sensitive code necessary)? > > > > And perhaps something that we can add as a test to the Lift build process. > > > ;-) > > > Yes, indeed. Let me first find the culprit behind this ;) > > > > > Cheers, Indrajit > > > > > On 08/12/09 3:48 PM, Timothy Perrett wrote: > > > > > Ahhh! That is interesting... i'd not thought of that :-) > > > > > > You'll need to specify a proper encoding type for sure otherwise maven > > > > will just assume your platform default... for example, MacRoman. > > > > Perhaps IRC > > > > or Josh will be able to advise... > > > > > > Cheers, Tim > > > > > > On 8 Dec 2009, at 10:02, Jean-Adrien wrote: > > > > > >> Ah ! > > > > > >> In fact the problem did not appear when I upgraded to 1.1-SNAPSHOT > > > > >> but > > > > >> when I enabled maven resource filtering (which assumes all files use > > > > >> UTF-8). > > > > >> Anyway I'll look for a correct setting to have both ISO 8859-1 > > > > >> properties file and maven resource filtering enabled. > > > > > >> On Dec 8, 10:41 am, Jean-Adrien<jean.vauc...@gmail.com> wrote: > > > > >>> Hello, > > > > > >>> I have a char encoding problem, using the localization feature of > > > > >>> lift. > > > > >>> I use the ? method of the S object in order to translate strings. > > > > >>> The > > > > >>> localized values are in a translate_fr.properties file in the > > > > >>> resources of the project. > > > > > >>> Until I upgrade from lift 1.1-M6 to 1.1-SNAPSHOT everything was ok, > > > > >>> but now it seems that the following happens: > > > > >>> As specified in the java doc, the properties file is encoded using > > > > >>> ISO > > > > >>> 8859-1. All xhtml templates in lift use UTF-8, and are interpreted > > > > >>> in > > > > >>> UTF-8 by the browser. But it seems that the the string loaded from > > > > >>> properties file are badly translated to UTF-8 (?) > > > > > >>> I.e. "é" is 0xE9 in ISO 8859-1 and should turn when loaded in a > > > > >>> String > > > > >>> by java properties into the UTF-8 bytes 0xC3 0xA9. But it is > > > > >>> interpreted some way in � (0x EF 0xBF 0xBD) > > > > > >>> I tried to encode my properties file in UTF-8 but I have the UTF > > > > >>> encoding (0xC3 0xA9) interpreted in ISO 8859-1. "é" become é > > > > >>> (famous > > > > >>> French letter) in the webpage. Behaviour I understand since java > > > > >>> loads > > > > >>> properties String using ISO-8859-1 charset > > > > > >>> Does anyone observed the same ? > > > > > >> -- > > > > > >> You received this message because you are subscribed to the Google > > > > Groups "Lift" group. > > > > >> To post to this group, send email to lift...@googlegroups.com. > > > > >> To unsubscribe from this group, send email to > > > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com > > > > > > > > > . > > > > >> For more options, visit this group at > > > >http://groups.google.com/group/liftweb?hl=en. > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > Groups > > > > "Lift" group. > > > > > To post to this group, send email to lift...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com > > > > > > > > > . > > > > > For more options, visit this group at > > > >http://groups.google.com/group/liftweb?hl=en. > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "Lift" group. > > > > To post to this group, send email to lift...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com > > > > > > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/liftweb?hl=en. > > > > -- > > > Lift, the simply functional web frameworkhttp://liftweb.net > > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > Follow me:http://twitter.com/dpp > > > Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
