Internationalisation of ImageJ

[knut_pape]

Hello everyone,

I have noticed that there are no translations of ImageJ available. If
there is an interest in providing Translations I could provide the
necessary code changes and the base for a German translation.

I already had a look at the code and implemented a translation for the
Menu.

For this I have added a utility class named TranslationService and
introduced an enhanced class MenuItem which basically extends the AWT
class MenuItem and enhances it in a way that the label is translated
at construction time and the actionComman is still the original text
(a simple powerful approach).

Additionally I changed the class Menu to make use of the new MenuItem
and to make use of the TranslationService for the Menu itself (this
again is a simple modification).

The translation service makes use of the I18N functionality provided
by Java and basically looks for a properties file in the language of
the current Local of the user. If such a file exists and contains a
translation the translated text is used, otherwise the original
english text is used.

As said, all of this is already implemented and works well for me.

Other texts like, for example, the text in the status bar need some
more work to get translated as all of the calling sites of the
IJ.showStatus() method need to translate the text before it is
displayed (Reason: Often the text contains variables so it needs to be
translated without the variables).
Again, these are simple modifications but they will change a lot more
classes (all calling sites of IJ.showStatus(), IJ.showMessage(),
IJ.error(), ...).

If you are willing to add these changes to the main trunk I could work
on this topic and provide the necessary change set.

Any opinions, thoughts, suggestions?

What is the best way to upload the changes described above for
discussion - is there a way to attach files to a discussion?

Regards

Knut Pape

--
You received this message because you are subscribed to the Google Groups "ImageJX" group.
To post to this group, send email to ima...@googlegroups.com.
To unsubscribe from this group, send email to imagejx+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/imagejx?hl=en.

[Curtis Rueden]

Hi Knut,

Sorry for the delay in reply. As part of the ImageJDev refactoring, we are looking to use a better resource loading framework to more easily enable internationalization. Most likely this will end up being something similar to what you have already done, so yes, your work would be great as a starting point! It should be possible to upload your files to the ImageJX group through the web interface—let us know if you have problems with that.

Grant Harris can comment further, as he has been researching i18n over the past few weeks.

-Curtis

[Dimiter Prodanov]

Hi Curtis,

How are your efforts going? Do you have not a consistent v 2
architecture to be discussed by the community?

I am mostly working on the application side nowadays, i.e. writing
libraries for particular statistical applications.

I also had a discussion/disagreement with Johannes and Wayne regarding
the default class loading mechanism, which I need to override in
certain applications. My point was that the current plugin loader is
limited in functionality and can not be invoked explicitly by an
application to add classes dynamically at runtime and I needed exactly
this for one Matlab-based project.

best regards,

Dimiter

[Johannes Schindelin]

Hi,

On Mon, 7 Jun 2010, Dimiter Prodanov wrote:

> How are your efforts going? Do you have not a consistent v 2
> architecture to be discussed by the community?

Do you really think that many cooks will make a better architecture?

> I am mostly working on the application side nowadays, i.e. writing
> libraries for particular statistical applications.
>
> I also had a discussion/disagreement with Johannes and Wayne regarding
> the default class loading mechanism, which I need to override in certain
> applications. My point was that the current plugin loader is limited in
> functionality and can not be invoked explicitly by an application to add
> classes dynamically at runtime and I needed exactly this for one
> Matlab-based project.

And you still fail to address the main argument I raised: when refreshing
the menus, every of your attempts to re-fix the loading path is way too
late. What you need is a mechanism to tell ImageJ beforehand where it
should look for plugins. Not a way to mess with the load path afterwards,
when ImageJ has no chance to adjust the menu entries and the action map
accordingly.

I would still be interested in any argument you have, but "I just need it"
is not an argument I can stomach.

Ciao,
Johannes

[Curtis Rueden]

Hi Dimiter,

How are your efforts going? Do you have not a consistent v 2
architecture to be discussed by the community?

Thanks for your inquiry, and sorry for the delay in my reply. We do not yet have a new API for community discussion, but will be working on a first cut of such in coming weeks. We should have more to discuss by the ImageJ conference in October.

I also had a discussion/disagreement with Johannes and Wayne regarding
the default class loading mechanism, which I need to override in
certain applications. My point was that the current plugin loader is
limited in functionality and can not be invoked explicitly by an
application to add classes dynamically at runtime and I needed exactly
this for one Matlab-based project.

I think the class loader issue is very important. One thing we are looking at right now is OSGi, which also has more sophisticated (dangerous?) class loading capabilities. We will certainly need to compare/reconcile the different class loading approaches of ImageJ, Fiji, and OSGi, but we have not yet researched it enough to comment much further from a technical standpoint.

-Curtis