ok, I'll fix these properties, run the bundlemigrator again, and commit the changes
thanks, Harry 2009/2/3 Andrew Jaquith <[email protected]> > I had not noticed that; good catch. > > That is almost certainly not the proper format. Property values, if > they span lines, need to be escaped with a \ character at the end of > the line, just before the newline character. So I would consider this > a bug in the properties file, not a bug in the code. We should fix > this. > > The re-worked CommentedProperties code, by the way, simply delegates > parsing of keys and values to the Properties superclass, so the > parsing results should be the same for both Properties and > CommentedProperties. > > On Tue, Feb 3, 2009 at 1:21 PM, Harry Metske <[email protected]> > wrote: > > One of the things I noticed (and maybe you too), is that the > > default_ru.properties contains properties whose value start on a new > line, > > for example this snippet where common.nopage has that : > > > > common.nopage= > > \u042d\u0442\u0430 \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u0430 > > \u043d\u0435 > \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442. > > \u041f\u043e\u0447\u0435\u043c\u0443 \u0431\u044b \u0432\u0430\u043c > > \u0435\u0435 \u043d\u0435 \u0441\u043e\u0437\u0434\u0430\u0442\u044c {0}? > > common.createit=\u0441\u043e\u0437\u0434\u0430\u0442\u044c > > common.more=\u0411\u043e\u043b\u044c\u0448\u0435... > > > > > > I don't understand the reason for doing this, and I'm not sure if this is > > valid Java properties format. > > Anyway, the output from BundleMigrator in this case is : > > > > > > #Copied from etc/i18n/templates/default.properties. > > common.nopage= > > > > Harry > > > > 2009/1/30 Andrew Jaquith <[email protected]> > > > >> I've checked in a new & improved CommentedProperties that preserves > >> encodings correctly. There are a few cosmetic issues that probably > >> should be fixed related to whitespace fidelity in comments, but other > >> that this, it's looking pretty good. > >> > >> At this point we can basically say, "it works." Will tweak a little > >> bit more in the next few days. > >> > >> On 1/29/09, Andrew Jaquith <[email protected]> wrote: > >> > Harry -- I've concluded that it's probably easiest just to > >> > re-implement Properties.store(). The encoding rules are fairly clear, > >> > so it shouldn't be too hard to do. I will take a whack at this over > >> > the next few days. > >> > > >> > Andrew > >> > > >> > On Thu, Jan 29, 2009 at 3:50 PM, Harry Metske <[email protected] > > > >> > wrote: > >> >> hmmm, indeed, it runs fine, a few minor differences like blanks > around > >> >> the > >> >> equals sign, and the property values convert to one line. > >> >> but the Russian and Romanian files get corrupted. > >> >> > >> >> This is something weird in java.util.Properties, I noticed that > >> >> properties > >> >> that are commented are translated fine, for example : > >> >> > >> >> # Login.jsp > >> >> > #login.error.capslock=\u041d\u0435\u0432\u0435\u0440\u043d\u044b\u0439 > >> >> \u043b\u043e\u0433\u0438\u043d > >> >> (\u043f\u0440\u043e\u0432\u0435\u0440\u0442\u0435 > >> >> \u043a\u043b\u0430\u0432\u0438\u0448\u0443 Caps Lock) #obsolete > >> >> login.error.password = ???????? ?????. > >> >> login.error.noaccess = ? ??? ??? ??????? ? ?????. ????????. > >> >> > >> >> You see that the commented login.error.capslock remains fine. > >> >> I was just on my way finding the sources of JDK5, but run out of > time, > >> >> I'll > >> >> dig further next few days (or you get there before me :-) ) > >> >> > >> >> regards, > >> >> Harry > >> >> > >> >> 2009/1/28 Andrew Jaquith <[email protected]> > >> >> > >> >>> Yes. This is one of those weird cases. We have three choices: > >> >>> > >> >>> 1. Duplicate the message key in both places > >> >>> 2. Remove the fmt:message tags in InfoContent.jsp and PageTab.jsp > (the > >> >>> ones that reference common.nopage) and refactor their functions into > >> >>> the ActionBean handler methods > >> >>> 3. Rename the key that WikiPageTypeConverter relies on, or figure > out > >> >>> a way to eliminate the reference. > >> >>> > >> >>> At the moment (1) is the best option because it is the simplest; I'm > >> >>> also investigating (3). But when we encounter stuff like this we > need > >> >>> to figure out if we can reduce duplication when possible on a > >> >>> case-by-case basis. > >> >>> > >> >>> Could you try the BundleMigrator tool to do this? The command... > >> >>> > >> >>> "java -cp build/JSPWiki.jar > >> >>> com.ecyrd.jspwiki.ui.migrator.BundleMigrator" > >> >>> > >> >>> ...should work. > >> >>> > >> >>> Note: there is one bug in BundleMigrator that I'm still trying to > >> >>> solve, related to output file encoding. If you've got any insights > on > >> >>> how to solve it, let me know... I'll be looking at this > >> >>> tonight/tomorrow. > >> >>> > >> >>> On Wed, Jan 28, 2009 at 12:04 PM, Harry Metske < > [email protected] > >> > > >> >>> wrote: > >> >>> > Andrew, > >> >>> > > >> >>> > nice, during of the tests last week I stumbled into missing > resource > >> >>> > common.nopage : > >> >>> > > >> >>> > 2009-01-26 21:51:15,780 [http-8080-6] ERROR > >> >>> > com.ecyrd.jspwiki.tags.WikiTagBase - Tag failed > >> >>> > java.util.MissingResourceException: Could not find an error > message > >> >>> > with > >> >>> > key: common.nopage > >> >>> > at > >> >>> > > >> >>> > >> > net.sourceforge.stripes.validation.LocalizableError.getMessageTemplate(LocalizableError.java:109) > >> >>> > at > >> >>> > > >> >>> > >> > net.sourceforge.stripes.action.SimpleMessage.getMessage(SimpleMessage.java:91) > >> >>> > at > >> >>> > > >> >>> > >> > net.sourceforge.stripes.validation.SimpleError.getMessage(SimpleError.java:102) > >> >>> > at > >> >>> > > >> com.ecyrd.jspwiki.tags.MessagesTag.doWikiStartTag(MessagesTag.java:117) > >> >>> > at > >> >>> > > com.ecyrd.jspwiki.tags.WikiTagBase.doStartTag(WikiTagBase.java:119) > >> >>> > at > >> >>> > > >> >>> > >> > org.apache.jspwiki.jsp.templates.default_.AttachmentTab_jsp._jspx_meth_wiki_Messages_0(Unknown > >> >>> > Source) > >> >>> > at > >> >>> > > >> >>> > >> > org.apache.jspwiki.jsp.templates.default_.AttachmentTab_jsp._jspService(Unknown > >> >>> > Source) > >> >>> > at > >> >>> > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) > >> >>> > at > >> javax.servlet.http.HttpServlet.service(HttpServlet.java:803) > >> >>> > at > >> >>> > > >> >>> > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > >> >>> > ................ > >> >>> > > >> >>> > I read the whole discussion on resourcebundles in > >> >>> > https://issues.apache.org/jira/browse/JSPWIKI-351 . > >> >>> > > >> >>> > The common.nopage is currently in default.properties, but is used > in > >> >>> > both > >> >>> > stripes messages, as in plain JSP's, what to do with that ? > >> >>> > > >> >>> > regards, > >> >>> > Harry > >> >>> > > >> >>> > 2009/1/27 Andrew Jaquith <[email protected]> > >> >>> > > >> >>> >> All -- > >> >>> >> > >> >>> >> In the process of writing the BundleMigrator tool, I discovered a > >> >>> >> serious logic flaw in the CommentedProperties class. > >> >>> >> CommentedProperties reads/writes Properties files while > preserving > >> >>> >> comments. As currently written, it doesn't correctly parse > property > >> >>> >> values that span multiple lines. So, I am re-writing it. It's > >> >>> >> actually > >> >>> >> a pretty hard thing to re-write: the original version took some > >> >>> >> shortcuts that, as it turned out, didn't work out so well. > >> >>> >> > >> >>> >> Anyway, I thought I'd let everybody, especially Harry, know > what's > >> >>> >> going on. It's blocking me from finishing BundleMigrator, and > thus > >> >>> >> from doing more JSP migration work -- so I wanted to get it > solved. > >> >>> >> > >> >>> >> Andrew > >> >>> >> > >> >>> > > >> >>> > >> >> > >> > > >> > > >
