On 24.01.2008 23:15:09 Andreas Delmelle wrote:
<snip/>
> > Of course, we could add these message templates as javadoc tags (like
> > the Blammo proposal, but in all languages) but that puts everything in
> > one file which I'd like to avoid. As long as there are only English  
> > it's
> > fine, but if the community starts producing all sorts of  
> > translations it
> > could get messy.
> 
> Agreed, although, OTOH we should precisely encourage the community to  
> bundle their efforts in providing FOP with default messages for the  
> different languages. I guess this is what you mean by "An existing  
> translation file is merged automatically so existing translations  
> aren't lost."

Sometimes, I'm too minimalistic. :-) What I mean by that is:

The translation files will live in some directory in SVN (i.e. not under
build/something). Suppose you have:

translations.xml
  trans1: blah
  trans2: blah blah
  trans3: blah blah blah

...and you now add a new event method to one of the EventProducer
interfaces. This adds a new translation to the XML file:

translations.xml
  trans1: blah
  trans2: blah blah
  trans3: blah blah blah
  trans4: <empty>

SVN will notice the file has changed and you will notice in the diff before
committing that you have to add a missing translation. If you still
forget it, you'll get an error message first time FOP is run and the
translations are loaded.

I do want to encourage that the community contributes translation files.
It's a very easy way to contribute with no need for Java knowledge. Of
course, as the stuff grows we will not always immediately have a
translation for all new events which makes the fallback to English
important.

> In time we could also serve standard sets of FOP  
> resource JARs containing pre-generated XMLs that users can add to  
> their environment. Keep English as the only 'bootstrapped' language,  
> and offer the rest as optional (?)

That's a possibility and easy to do but I'd really like to keep the
translations in FOP's codebase. The thing with hyphenation is suboptimal
enough.



Jeremias Maerki

Reply via email to