[ImageJ-devel] [fiji-devel] i18n support for fiji et al

[Curtis Rueden]

Hi Johan et. al,


I have gotten a user who is concerned about supporting multiple languages.
> What is the status in the fiji/imagej2 camp?


I agree with the other comments that i18n is an extremely hard problem.
Here are a couple of articles that give a mere taste at the complexity
involved:

  * The Turkey Test:
http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html
  * A Localization Horror Story (cpan.org): http://bit.ly/3h8gMo

That said, the current plan for ImageJ2 is to pursue it at some point, once
we are past some of the more urgent development tasks. The feature ticket
is here:
    http://trac.imagej.net/ticket/37

But you'll notice there are no task tickets linked to it yet.



> I can see some long-term benefits in using the same translation system for
> endrov, ij2, icy et al.


I definitely agree.



> I guess the main concerns are
>
> * user interface for translators. has to be good if we want contributions
> * modularity. each plugin should have its own translation table
> * not too intrusive on the code
>

I agree about the system being unintrusive, particularly to plugin
developers. Most plugin developers will not want to translate their
plugins. That task will often be left to dedicated localizers, or else no
one will do it. Localization metadata must be separate from the plugin
itself, so that localization packs can be delivered independently of the
components they are translating.

Lots of people have thought about i18n and beyond in Java, for many years,
so surely there are a few good building blocks out there. But I have not
had time to research much yet.

As a start, perhaps we should merely target language translation of string
resources, rather than all the other issues that go along with different
locales. But even focused *solely* on language translation, it can be
extremely difficult, as the "Localization Horror Story" above describes.


So: Johan, if you feel up for it, go ahead and design a way to induce i18n.
>

Johan, if you need an i18n system now, go for it. There is certainly the
potential for a big contribution to the IJ2 project here. Please feel free
to stay in touch with progress and items for discussion, and maybe we can
design something that will eventually be usable by all our projects!

Regards,
Curtis


On Tue, Mar 13, 2012 at 9:15 AM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:

> Hi all,
>
> On Tue, 13 Mar 2012, Gabriel Landini wrote:
>
> > On Tuesday 13 Mar 2012 10:39:27 Jean-Yves Tinevez wrote:
> > > Mu humble opinion is strongly against investing the energy into
> > > supporting multiple languages.
> >
> > I agree that currently are better things to divert efforts into.
>
> This is maybe the reason why we indeed put our efforts into other
> directions...
>
> > The main problem I see in this case is that translation is not affecting
> > only the UI appearance, but the UI also forms part of a recording
> > mechanism for design of workflows and scripts.
> >
> > A nasty side effect of translating plugin interfaces is that you might
> > end recording macros with parameters in a language that others will not
> > understand, or that I am unable to understand when recorded by another
> > user using a language I can't read.
>
> Right. Our plan for IJ2 is to record real calls into the API; the UI is
> well separated from the processing part.
>
> So: Johan, if you feel up for it, go ahead and design a way to induce
> i18n.
>
> > And if the recording of, let's say, macros was designed be done in the
> > default (English), then a user might not understand what they end up
> > recording as the UI and the code do not match anymore.
>
> Once I come around to pick up working on it again, IJ2's version of the
> macro language (sans some backwarts-compatibility that's too hard to
> maintain) will be a Beanshell-based beast.
>
> Newly recorded macros will actually be Beanshell scripts, using the Java
> API, fully in line with what I always claimed: if your API is
> well-designed enough, there is no reason why you should not share it
> between macros and Java classes.
>
> > Being practical, there are innumerable cases where translation of
> > technical terminology is extremely confusing and the proof is the tons
> > of technical words which are imported into other languages and the
> > translations (even when they exist) are not used at all.
>
> I agree, this is a very real problem...
>
> Ciao,
> Dscho
>
> --
> Please avoid top-posting, and please make sure to reply-to-all!
>
> Mailing list web interface: http://groups.google.com/group/fiji-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120320/1a0f56a2/attachment.html>