ResourceBundleMessageSource vs ReloadableResourceBundleMessageSource

With the treatise submission roughly one week away, I wanted to post a small segment that people might find useful for their own work because the issue had me confused for some time.
It relates to the difference between ReloadableResourceBundleMessageSource and ResourceBundleMessageSource.

Firstly, due to the nature of server caching, the files can no longer be stored in the default classpath and as a result must be moved and the basenames property updated as in the snippet above. The second issue is less well known and careful scouring of the internet combined with a forum post on forums.springframework.org shed no light on the matter. Using a custom read/write of the properties files and the non-reloadable configuration it was possible to read in the file and then write out to the same file with whatever changes necessary. However, with the reloadable configuration the same process would result in the file being blank. This may have resulted from the way in which the server now handled the files in terms of regular caching. This would have been an application breaking issue as the ability to be able to edit and then have the server update these files is at the core of the project. It would be no good using a non-reloadable source but being able to update the files because the server would not render a different view unless it was restarted. Fortunately it was discovered that writing the updated properties file to a temp file and then back again was a method to overcome the issue.

Partial Draft Thesis

The Partial Draft Thesis is due this Friday (Sept 5th)

I've written most of this up, I probably just have a couple of more days work to put into it before I can get back to the actual development side of things.

The core of the draft will be as follows:

Chapter 2: Background

• i) Current i18n via Message Sources & JSTL
• ii) OpenACS solution, ACS-Lang Package, Message Key Translation Interface
• iii) Google-Translate-Java-API
• iv) Encoding
• v) Databases
• vi) Translation Management Services/Applications

Chapter 3: Own Work

• MessageTag Extension - Spring.TLD
• Sessions - login with 'translator mode'
• XML I/O
• Error messages
• Consider Tiles for layout ability
  

Minor Breakthrough / Idea ??

One of the issues I was having is how I was going to be able to provide links to a page for each message key that are only available when translator mode is enabled.

A possible solution that I'm looking into is either rewriting or extending the Spring MessageTag definition so that if the user role is 'translator' or translator mode is toggled on then each message key will effectively be marked up.

Each message item will end up with a link to a translation page which is passed the particular message key reference.

I will probably just write my own TranslatorMessageTag.java and point Spring.tld to that.

If this all goes as planned the final step of this stage will be to update the relevant message.properties with what is input on the translation page.

Old-School i18n

In order to get a better understanding of the current/traditional Spring i18n technique I implemented it in my ELEC5619 tutorial application.

The application already had a messagesource in the form of

<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basenames">
<list>
<value>messages</value>
</list>
</property>
</bean>

I had to declare an interceptor and then a resolver.

<bean id="localeChangeInterceptor" class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor">
<property name="paramName" value="siteLanguage">
</property>

<bean id="localeResolver" class="org.springframework.web.servlet.i18n.SessionLocaleResolver"></bean></bean>

and add the interceptor to the urlMapping

The project already had message.properties so I added a new localised message-set for French as messages_fr.properties

Then add the spring taglib to include.jsp

<%@ taglib prefix="spring" uri="/WEB-INF/spring.tld" %>

and finally update the jsp so use the spring taglib instead of jstl. So for example

<spring:message code="title"></spring:message>

Changing the language setting inside the browser to French resulted in the output being localised for Fr_fr -> SUCCESS!

Now I need to move forward onto a translation interface, however I'm seeing a few complications as I'm not sure how to go about a few things. Namely, I need to be able to add links of some form to all the message.keys in translator mode. When translator mode is enabled the controller could redirect to a different jsp and manually add a traditional link for each message.key but this is going to result in a lot of tedious re-coding. I'm hoping to just be able to render the jsp and add the link somehow without requiring a different jsp for when translator is enabled.

The other issue I need to consider is how to interface to simply localise any text pulled from a database.

Moving towards Draft Treatise submission

Friday 5th September, 2008 Hand in your partial treatise draft

The draft submission consists primarily of Chapters 1+ 2, Introduction + Background. I have some work to do to complete my Introduction based on the plan submitted a couple of weeks ago and then develop the full Background chapter.

Other developments:

Completed introductory Spring readings and ELEC5619 lab. This enables me to start playing around with other Spring examples so that I can begin designing my own solution.

I will look closely at examples implementing Security and also read the chapters on Security and Web in Spring in Action. This should enable me to understand interceptors and how it might be possible to intercept a JSP, translate it and output a new version to the browser.

I am interested in the potentials of integrating Google's translator. There is a Java client available as per http://code.google.com/p/google-api-translate-java/

Readings, Thoughts, Project Plan!

I've been doing a lot of reading over the past week on the following topics:

• Translation management - i18n & l10n.
• Spring Framework.
• Current Java i18n/l10n solutions.
• ACS-Lang by OpenACS.

In my readings I came across encoding, which I hadn't yet considered. It looks like it shouldn't be a problem because everything should support UTF-8 which will cover all the characters required. I will probably devote at least a small section of the final thesis document to encoding as it is both relevant to the topic and interesting.

Other difficulties that I hadn't previously considered also arose:

• Versioning - what happens when the core text changes?
• Left to Right text!!
• Text on images.
• The importance of tracking the author and the translation history of the text.
• Nuances in languages, different ordering of sentences.

These considerations are going to factor heavily on what limitations I put on the scope of the project.

My proposed solution, 'very' broadly will be to develop a webapp similar to that of the ACS-lang demonstration but using Java/Spring. These design should be such that the translation management objects are independent and can be used in other projects. Unfortunately, I'm still not 100% clear how I'll actually go about the design at this stage.

Project Plan due Friday 1st Aug!
Structure will be as follows:

• Title & Project Brief
• Description of Project
• Introduction

1. What is Spring?
2. What is internationalisation?
3. What is localisation?

• Overview of relevant research

1. OpenACS solution
2. Existing Java solutions
3. Other research
4. Questions raised by research and my thoughts

• Proposed procedure
• Timetable
• Bibliography

How to Write a Thesis

I felt it important to do a bit of a review of the Thesis/Project process/structure and get my head around it a bit more as well as get something down on paper that I could refer back to in the weeks ahead.

I have summarised some information from How to write a better thesis, 2nd Ed, David Evans, Paul Gruba, Melbourne Univ. Press 2002.

Making A Strong Start

It is essential that the thesis be structured in such a way that the reader is taken from the aim to the conclusion in the clearest possible way, and by the most direct route.

The Standard Structure

4 Parts:

1) Introduction

· Introduce the research

· Outline the problem

· State the aim

· Limit the scope

· Overview of what lies ahead

· 3-5 pages should suffice

2) Background

· Position own study in the context of what:

i. Has gone before

ii. Is currently taking place

iii. How research is conducted

· Brief historical review

· Describe study area and its characteristics

· Usually a chapter reviewing current theory or practice

· Possibly preliminary experiments

3) Own Work

· Own response

· “This is mine”

· Design of experiments, surveys or reviews to test hypothesis or answer questions developed from the background

· Results and critical analysis of results

4) Synthesis

· Develops own contribution to the state of knowledge and understanding of the topic

· Compare own results with previous state (part 2)

· Evaluation of model

· Conclusion

· Respond directly to aim

· Neglecting any of the 4 areas will cause strife.

· The issue to be careful of is the differentiation of part 1 & 2, how to explain the problem without detailing what has been done before.

· Need to find some thesis examples for structure.

· Don’t ignore the need for critical thought!!!

Possible Project Plan Structure

· Title of Thesis

· Description of Research Project

o Introduction

o Overview of relevant research

o Questions raised by this overview

· Proposed research procedure

o Research methods

o Data sources & Data collection

· Research Timetable

· Bibliography

First piece of research:

· Review of existing work

· Don’t ‘data dump’

· Try look at chronological development.

· Should help understand topic and put limits in place.

· Will help find the real unanswered questions.

· Expect to have to modify introduction later.

· It would be useful to have a folder, broken up by chapters and sections. Then, as pieces are written, build each section.

· Finally, be sure when writing to link the chapters for the reader.