Hi,<br><br>I looked today over the XWikiMessageTool class, and I must say that I&#39;m not quite satisfied with it.<br><br>First, there was XWIKI-919, which I implemented. OK, I understand that files stored on disk should be charset independent, so only ASCII characters are supported by the ResourceBundle class (jvm) .But, when I can edit a wiki document for storing bundles, I expect it to accept all the characters the wiki supports (in my case, it was an UTF8 instance). I had some troubles fixing this, since the JavaDoc says that bundles accepts only ASCII characters, but it understands and parses unicode references ( \u0123 ). Maybe I did something wrong, but doing 
content.replaceAll(&quot;\u0139&quot;, &quot;\\u0139&quot;) resulted in the string u0139 being displayed in the page. So I had to trick it into believing that the component bytes of the encoding are ASCII characters and manually restore the multibyte chars.
<br><br>Second, I don&#39;t like the fact that XWIKI-921 was not already implemented.<br><br>Third, I don&#39;t like the cache refresh mechanism. It retrieves the XWikiProperties-&gt;documentBundles property for each request, and It retrieves the bundle documents for every request and checks if it must be refreshed or not. Why isn&#39;t the 
com.xpn.xwiki.notify package used? It allows registering callback handlers for specific document changes. How I see it:<br>- at startup, register a handler for XWiki.XWikiPreferences (so that we know when the documentBundles property might change). 
<br>- remember the list of document bundles, don&#39;t ask it for each request<br>- also register handlers for the current bundle documents and load the strings from these documents<br>- when XWikiPreferences is changed, if the documentBundle property is also changed, remove the unused bundles and build the new ones
<br>- when a undle document (or a translation for it) is changed, rebuild the bundle for that document<br clear="all">This should speedup the code a bit, it makes use of a nice, but mostly unknown feature, it doesn&#39;t log an error for each request when a specified document is not found in the wiki, and it doesn&#39;t require so many variables (previousDates, docsToRefresh).
<br><br>Fourth, as I said above, if a document is specified in the documentBundles property, but it does not exist in the wiki, for each $msg.get call an error is logged. And there are a lot of calls for each request.<br>
<br><br>Now, in my opinion this is a nice way to get in the core of XWiki for a newcomer, so does anybody want to write the changes I mentioned? Also, this is a good occasion to document the event notification mechanism, in JavaDoc and on 
<a href="http://www.xwiki.org">www.xwiki.org</a><br><br>Regards,<br>Sergiu Dumitriu<br><br>-- <br><a href="http://purl.org/net/sergiu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://purl.org/net/sergiu
</a>