[kepler-users] Where to go with the problems of internationalization or how create account into forum?
Christopher Brooks
cxh at eecs.berkeley.edu
Tue Sep 22 07:58:17 PDT 2009
Hi Anatoly,
I agree that using better named constants for the strings
would be a good idea. It would be nice if the name meant something.
I do like using hierarchical names where the first part of
the variable name is the class name and the second is more descriptive.
So, instead of:
PrintThreads.10=Unnamed thread
We would have
PrintThreads.UnnamedThread=Unnamed Thread
I think that starting with Eclipse and doing a few files might
be a good start, though it might be easier to just convert the
files by hand.
The main thing is that we often split up long strings into multiple
short strings for readability in the code:
if (thread == null) {
return "PrintThreads.toThreadDescription(): "
+ "thread argument == null\n "
+ "This can happen if the thread was "
+ "killed while PrintThreads was called";
}
This would change to:
if (thread == null) {
return Messages.getString("PrintThreads.NullThreadArg");
}
and the messages.properties file would contain:
PrintThreads.NullThreadArg=PrintThreads.toThreadDescription(): thread argument == null\n This can happen if the thread was killed while PrintThreads was called
(BTW-I'm not sure if having a \n is right in this context. Perhaps
we should not have newlines, or split this into two strings and use
a platform dependent or Locale dependent line separator.)
Note that by having a Messages class per package, we can use a shorter
name for the string. An alternative would be to have a Messages class per
project or for a group of packages, but this would make refactoring by
moving packages more difficult as we would need to find the strings by
hand and rename them. I think that having a Messages class per
package that extends a common base class might be best here.
Anyway, this seems like a large project. Carefully reviewing what other
Java tools have done with internationalization would be valuable. How
does Eclipse and Netbeans do internationalization?
_Christopher
Anatoly Loy wrote:
> Thanks, Christopher, it's a nice information!
> Yes, I am interested . . .
> I have read the recommendations from Java.
>
> I understand that you are invited to benefit from Eclipse, but after
> that, as Eclipse will perform the conversion, you propose "manually"
> review changes from Eclipse and simplify the code (you said: "one
> line")?
> Also I think the automatically generated "identifiers" from Eclipse
> for string constants even more trouble than the multi-code instead of
> a string constant. Maybe I do not fully represent the amount of work,
> but still willing to propose that after the processing code in source
> code used in "speaking for themselves" ID of resources string. For
> example, instead
> String query = "Overwrite" _file.getName () "?";
> use something like
> String query = RSQ_OVERWRITE_FILE;
>
>
>
> 2009/9/18 Christopher Brooks <cxh at eecs.berkeley.edu>:
>> 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
>>
>
>
>
--
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
More information about the Kepler-users
mailing list