Hi Johan et. al,<br><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I
have gotten a user who is concerned about supporting multiple
languages. What is the status in the fiji/imagej2 camp?</blockquote><div><br>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:<br>
<br> * The Turkey Test: <a href="http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html" target="_blank">http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html</a><br>
* A Localization Horror Story (<a href="http://cpan.org" target="_blank">cpan.org</a>): <a href="http://bit.ly/3h8gMo" target="_blank">http://bit.ly/3h8gMo</a><br><br>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:<br> <a href="http://trac.imagej.net/ticket/37" target="_blank">http://trac.imagej.net/ticket/37</a><br><br>But you'll notice there are no task tickets linked to it yet.<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can see some
long-term benefits in using the same translation system for endrov, ij2,
icy et al.</blockquote><div><br>I definitely agree.<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I guess the main concerns are<br>
<br>* user interface for translators. has to be good if we want contributions<br>* modularity. each plugin should have its own translation table<br>* not too intrusive on the code<br></blockquote><div><br>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.<br>
<br>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.<br><br>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.<br>
<br><br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">So: Johan, if you feel up for it, go ahead and design a way to induce i18n.<br></blockquote>
<br>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!<br>
<br>Regards,<br>Curtis<br><br></div></div><br><div class="gmail_quote">On Tue, Mar 13, 2012 at 9:15 AM, Johannes Schindelin <span dir="ltr"><<a href="mailto:Johannes.Schindelin@gmx.de" target="_blank">Johannes.Schindelin@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<div><br>
On Tue, 13 Mar 2012, Gabriel Landini wrote:<br>
<br>
> On Tuesday 13 Mar 2012 10:39:27 Jean-Yves Tinevez wrote:<br>
> > Mu humble opinion is strongly against investing the energy into<br>
> > supporting multiple languages.<br>
><br>
> I agree that currently are better things to divert efforts into.<br>
<br>
</div>This is maybe the reason why we indeed put our efforts into other<br>
directions...<br>
<div><br>
> The main problem I see in this case is that translation is not affecting<br>
> only the UI appearance, but the UI also forms part of a recording<br>
> mechanism for design of workflows and scripts.<br>
><br>
> A nasty side effect of translating plugin interfaces is that you might<br>
> end recording macros with parameters in a language that others will not<br>
> understand, or that I am unable to understand when recorded by another<br>
> user using a language I can't read.<br>
<br>
</div>Right. Our plan for IJ2 is to record real calls into the API; the UI is<br>
well separated from the processing part.<br>
<br>
So: Johan, if you feel up for it, go ahead and design a way to induce<br>
i18n.<br>
<div><br>
> And if the recording of, let's say, macros was designed be done in the<br>
> default (English), then a user might not understand what they end up<br>
> recording as the UI and the code do not match anymore.<br>
<br>
</div>Once I come around to pick up working on it again, IJ2's version of the<br>
macro language (sans some backwarts-compatibility that's too hard to<br>
maintain) will be a Beanshell-based beast.<br>
<br>
Newly recorded macros will actually be Beanshell scripts, using the Java<br>
API, fully in line with what I always claimed: if your API is<br>
well-designed enough, there is no reason why you should not share it<br>
between macros and Java classes.<br>
<div><br>
> Being practical, there are innumerable cases where translation of<br>
> technical terminology is extremely confusing and the proof is the tons<br>
> of technical words which are imported into other languages and the<br>
> translations (even when they exist) are not used at all.<br>
<br>
</div>I agree, this is a very real problem...<br>
<br>
Ciao,<br>
Dscho<br>
<div><div><br>
--<br>
Please avoid top-posting, and please make sure to reply-to-all!<br>
<br>
Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel" target="_blank">http://groups.google.com/group/fiji-devel</a><br>
</div></div></blockquote></div><br>