[kepler-users] Where to go with the problems of internationalization or how create account into forum?

[Christopher Brooks]

Hi Anatoly,
Here's how I would approach internationalization.

1) Take a look at the Java i18n information
Start with
http://java.sun.com/javase/technologies/core/basic/intl/
The i18n tutorial at
http://java.sun.com/docs/books/tutorial/i18n/index.html
is a good start

In particular, take a look at
"Lesson: Isolating Locale-Specific Data"
http://java.sun.com/docs/books/tutorial/i18n/resbundle/index.html

2) Download the devel version of Kepler and Ptolemy and use Eclipse
for set-up:
https://kepler-project.org/developers/reference/kepler-and-eclipse

3) Eclipse has a feature which will attempt to factor strings out.
I have not tried it, but it might be a start at doing what you want,
In Eclipse, it is under Source->Externalize Strings,

It looks like what this does is create strings and a messages.properties
file that looks like:
PrintThreads.0=ThreadGroups:
PrintThreads.1=\n
PrintThreads.10=Unnamed thread
PrintThreads.11=Unnamed group
PrintThreads.12=PrintThreads.toThreadDescription():
PrintThreads.13=thread argument == null\n
PrintThreads.14=This can happen if the thread was
PrintThreads.15=killed while PrintThreads was called
PrintThreads.16=\
PrintThreads.17=\
PrintThreads.18=\
PrintThreads.19=\
PrintThreads.2=\n
PrintThreads.20=\ *
PrintThreads.21=\ \
PrintThreads.22=\
PrintThreads.23=\
PrintThreads.24=PrintThread.toThreadDescription(): Bad State\!: '

The original Java code is modified to
StringBuffer results = new StringBuffer(Messages.getString("PrintThreads.0") //$NON-NLS-1$
                 + (rootGroup.activeGroupCount() + 1) + Messages.getString("PrintThreads.1")); //$NON-NLS-1$


And a Messages.java class is created:

package util.testsuite;

import java.util.MissingResourceException;
import java.util.ResourceBundle;

public class Messages {
     private static final String BUNDLE_NAME = "util.testsuite.messages"; //$NON-NLS-1$

     private static final ResourceBundle RESOURCE_BUNDLE = ResourceBundle
             .getBundle(BUNDLE_NAME);

     private Messages() {
     }

     public static String getString(String key) {
         try {
             return RESOURCE_BUNDLE.getString(key);
         } catch (MissingResourceException e) {
             return '!' + key + '!';
         }
     }
}


What would need to be done is to look at how Locale works and if it can be made to use
the messages.properties file.  We also want to have some sort of fairly standard
way of dealing with the Messages class.  We might not want a Messages file per
package.  I'm not sure.

Also, the Eclipse conversion is brute force.  Ideally, we would
look at each file and clean up the messages so that the are all one string.

This would be a fairly large task to get right.  For me to do this, I'd
have to have funding.  However, I can provide guidance and if someone does
the bulk of the work, I can provide write access to the ptII repository
for the proper set of changes to the subset of ptII that is used by Kepler.

For me, the biggest factor in determining whether I accept changes would be
that the internationalization should follow the Java i18n features documented
in the java.sun.com tutorial above.  I'm not that interested in accepting
changes for a home grown solution - let's stand on the shoulders of giants
and use the work of others here.

I see the following downsides to internationalization:
1) The messages are separate from the source code, which means that the
messages will not be properly maintained and it makes debugging more difficult.
2) This would be quite a bit of work to get right
3) Overall, internationalization adds a level of indirection and adds complexity.

The advantage is that it would be nice to have internationalization.


So, let me know if you are interested . . .

_Christopher

Anatoly Loy wrote:
> Hi Matthew,
> 
> Matt Jones wrote:
>> In addition to what Chad said, a group in Japan worked on internationalizing
>> Kepler for scientists in Japan (contact Akiko Ogawa on this list).  They
>> might be interested in contributing to improvements that allow for general
>> internationalization. They also found it was useful to translate the
>> documentation before translating the application, and so they produced a
>> Japanese translation of the Kepler Getting Started Guide, which can be
>> downloaded from the Kepler web site here:
>>    https://kepler-project.org/users/documentation
> 
> Yes, thanks, I saw these sections. And in my eyes already have an
> example of translation.
> (Oh my God, people who write/draw hieroglyphs by hand, should be more
> revered than the artists!)
> 
> And I am ready to begin immediately to translate "Getting Started Guide"! :).
> Me to work sufficiently original pdf-file. Naturally, I fall would
> like to know how will look steps of Workflow for "publishing" this
> translation, after I finish this translation. Also, it would be nice
> to know how to build a communication in case of any questions directly
> to the translation process.
> 
>> I think it would be fantastic to build an internationalization layer into
>> Kepler that allows it to easily be used in different languages.  Once the
>> new configuration system is in place, this should be easier than it would be
>> today.  Nevertheless, it will be a lot of work to factor out all of the
>> English UI elements into resource files and replace them with other language
>> resource bundles.  Any help you might provide would be greatly appreciated.
> 
> Nevertheless, I think that our team can work with the Kepler 1.0.0
> release, making changes in local copy. And in parallel, we will
> propose solutions for the new "super-puper" system configuration.
> Hopefully, with new version our translated resources/sources in the
> new version of the system simply change their location.
> 
> Sincerely yours,
> Anatoly Loy
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users

-- 
Christopher Brooks (cxh at eecs berkeley edu) University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480