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
