Re: Fwd: [OpenMap Users] OpenMap localization

Hello,

I'm another one of the developers here at BBN, and Don has asked me to help
integrate some of the internationalization efforts into Openmap. Currently
we have the code that you sent, some code from Bart and some ideas that Don
and I have been kicking around. I'm planning on trying to pull from all
three sources so as to get something included soon. As I get a little
further along I'll send out a synopsis of the blend that seems to be forming...

best,
-Ben

>From: "pitek" <pitek@gdynia.mm.pl>
>Date: November 6, 2003 7:46:35 PM EST
>To: <openmap-users@bbn.com>
>Subject: Re: [OpenMap Users] OpenMap localization
>Reply-To: "pitek" <Piotr.Kaminski@ctm.gdynia.pl>
>
>Hi,
>I've just make localization of simple text window. It works very well
>and I'd like to show the way I done that. Please see attached files
>and let me know if such way could be used for OpenMap localization.
>
>--
>Piotr
>----- Original Message -----
>From: Bart Jourquin
>To: pitek
>Cc: Don Dietrick
>Sent:Monday, November 03, 2003 11:05 AM
>Subject:Re: [OpenMap Users] OpenMap localization
>
>Sorry Piotr, but I have to confess that I didn't spare enough time to
>do that, and things are not going to be better in the coming months as
>I have to struggle with a lack of researches in my team for more than
>one year now....
>
>For the record, JBuilder has also a tool that helps to externalize the
>strings to translate with an option to store the in property files.
>
>Bart
>
>pitek wrote:
>
>Don, Bart,
>I'm facing again OpenMap localization problem.
>Bart, have you made any localization effort?
>What about that:
>- for each package create file i18n.properties
>- in each class (which needs localisation) declare field:
>java.util.ResourceBundle static bundle =
>java.util.ResourceBundle.getBundle("com/bbn/..package name ../i18n");
>- use this field:
>okButton.setText(bundle.getString("LOC_ok"));
>cancelButton.setText(bundle.getString("LOC_cancel"));
>jDialog.setTitle(bundle.getString("LOC_exit_dialog_title"));
>- in i18n.properties put key & value pair:
>LOC_ok = OK
>LOC_ok = Cancel
>LOC_exit_dialog_title = Exit OpenMap
>- in i18n_pl_PL.properties put (OK is OK in Polish ;-) :
>LOC_cancel = Rezygnuj
>LOC_exit_dialog_title = Koniec pracy z OpenMap
>
>NetBeans IDE has Internationalization Wizard which helps finding
>strings in
>source file and creating resource bundle file. "LOC_" makes localized
>strings
>easier to find and distinguish from other strings (for example
>exceptions'
>messages).
>
>I've checked NetBeans project's source for localization code. It is big
>project and
>is going to be fully localized. As I browsed through NetBeans source
>and I
>found a few
> different ways of making localization:
> - something similar to this example
> - use of specialised class NbBundle :
>NbBundle.getMessage(this.class,
>"TXT_message");
>- use of static Util class declared in each packaged. Util.getMessage(
>"TXT_message"); This class' methods call NbBundle.
>- use of class method g(String) which then calls NbBundle
>- the simplest way (this code is generated by NetBeans Wizard) :
>java.util.ResourceBundle.getBundle("org/netbeans/ Bundle").getString("TXT_mes
>sage");
>
>What is common in NetBeans source:
>- they use "Bundle.properties" for localization
>- almost every message has prefix TXT_ MSG_ CTL_ LBL_ ... (some of
>them I
>don understand)
>- the key is rarely a real message, it is rather some kind of helper:
>which
>class and which atribute it describes.
> LBL_OpenFileDialog_title = Open File
>
>Maybe some static utility class (com.bbn.openmap.util.I18N ?) would
>help but
>I shouldn't
>make conversion of keys (as Bart proposed). I'd preffer to define keys
>by
>myself.
>Also throwing runtime exception is nothing bad (NetBean's class does it
>also) - it helps you
>prepare good properties file. If some new string appears in GUI, then
>you
>create bundle.getString("LOC_newString")
>phrase and if you forget to add "LOC_newString" key to properties you
>will
>be warrned by exception.
>If you add new key in default properties (for default locale) and not
>add it
>in properties for other languages
>you will get default value from default propeties file. That's nothing
>wrong - you will see that there is new
>label in GUI and it needs to be localized.
>
>I think that proposed way of doing localization is as close to Sun's
>idea as
>possible.
>Sometimes I think that properies could be placed in separated dirctory
>tree.
>Or all files could be placed in one dirctory "i18n" and their names
>could
>correspond
>to packages names as follows:
>i18n/com.bbn.openmap.layer.properties
>i18n/com.bbn.openmap.properties
>i18n/com.bbn.openmap.gui.properties
> and so on. It could be easier to find all files which needs to be
>translated.
>
>Best Regards
>Piotr Kaminski
>
>----- Original Message -----
>From: "Don Dietrick" <dietrick@bbn.com>
>To: "Piotr Kaminski" <Piotr.Kaminski@ctm.gdynia.pl>
>Cc: "Bart Jourquin" <bart.jourquin@fucam.ac.be>; "Donald Dietrick"
><dietrick@bbn.com>
>Sent: Tuesday, June 17, 2003 11:53 PM
>Subject: Re: [OpenMap Users] OpenMap localization
>
>
>
>Hi Piotr,
>
>Bart sent me this link:
>
>http://java.sun.com/products/jilkit/
>
>It looks like this tool may take care of creating the proper resource
>files, as well as checking source files for potential string problems.
>I'd rather keep the resource files, in whatever key=value format they
>turn out to be, in the most common used format. I haven't used the
>tool to do this yet, so I'm not sure what the format is.
>
>On Tuesday, June 17, 2003, at 03:54 AM, Piotr Kaminski wrote:
>
>
>Hi Don,
>I wrote that I need to localize OpenMap becouse my client needs
>Polish GUI. That was true a week ago. Because I have to release
>first version till july I my client agreed to English GUI. I can move
>localization effort to subsequent releases.
>Now I have no time to make localization but I'd like to contribute
>in the future. It would be nice to have localization support in 4.6
>release,
>I think.
>
>I think so, too. That's the goal.
>
>
>Some technical questions:
>If one .properties file is for one package it would contain something
>like
>this:
>
>className.key=value
>
>I think this makes sense, but again, I'd like to see what the tool
>does.
>
>
>"className" is unique because classes are uniqe inside package. "key"
>might be "string_to_use" but what it that
>"string_would_be_very_very_long_and_unconfortable_to_use"?
>
>I don't mind long strings if it makes it easy to match and track down
>what string to modify to change a string in the component.
>
>
>If localized class is for example JMenu it have only "name",
>"mnemonic" and "tip" to set, so key might be "name", "mnemonic" and
>"tip" - short and comprehensible. What do you think?
>
>I think the key needs to be based on a string, not the function.
>
>
>I think also about parametrized strings, especially for messages. I
>think that standard mechanism uses %1 %2 fields to parametrize
>localized string with runtime values.
>
>I'm not sure how these strings are handled by the tool. I'm working
>with it this week.
>
>- Don
>
>
>Regards,
>Piotr
>
>----- Original Message -----
>From: "Don Dietrick" <dietrick@bbn.com>
>To: "Bart Jourquin" <bart.jourquin@fucam.ac.be>
>Cc: "Piotr Kaminski" <Piotr.Kaminski@ctm.gdynia.pl>;
><openmap-users@bbn.com>
>Sent: Monday, June 09, 2003 8:46 PM
>Subject: Re: [OpenMap Users] OpenMap localization
>
>
>
>Hi Bart,
>
>I seem to remember that we talked about a package-based solution -
>that
>is, a ResourceBundle per package - being the easiest solution to
>manage. Do you have an example of what a ResourceBundle would look
>like for a package, and how a class would access it for a particular
>language? Also, how to set up error handling if a string isn't found
>in a ResourceBundle?
>
>Seems like we would need to address labels, menus and ToolTips, to
>mention a few, spreading across various layer packages, the gui, event
>and proj packages.
>
>I don't think the modifications would take up much time, once the
>proper mechanism is defined. I'm in the process of finding out what
>it
>would take to get you and Piotr write access to our external CVS tree
>for the duration of this mini-project, so we could collaborate more
>easily.
>
>- Don
>
>On Monday, June 9, 2003, at 05:33 AM, Bart Jourquin wrote:
>
>
>Piotr Kaminski wrote:
>
>
>Hello,
>I'm going to make OpenMap GUI localization (for Polish language).
>I'm going to use ResourceBoundle mechanizm, and one property
>file for whole GUI interfaces.
>In official OpenMap sources there is no localization support,
>but I've head from Don, that some users are working on it.
>If someone has done OpenMap localization or is working on it
>please contact me or post information to openmap-users list.
>I'd like to know if there is some code I could use as a base version
>for Polish localization.
>Regards,
>Piotr Kaminski
>
>--
>[To unsubscribe to this list send an email to "majdart@bbn.com"
>with the following text in the BODY of the message "unsubscribe
>openmap-users"]
>
>
>
>Hi Piotr,
>
>I have to confess that I promised to Don to work on localization some
>months ago, but I couldn't fin the needed time resources due to
>internal staff changes in my research group :-(
>
>My primary idea was to use JBuilder, that has a tool that is able to
>"outsource" the strings to translate. I'v tested it with success on
>some internal projects and it should also work with OpenMap. Having
>write access to a BBN OpenMap CVS tree would also help...
>
>As I wrote to Don some days ago and I hope to have some time for this
>at the end of June or the first week of July... But if you do the
>work, it's obviously better for me :-)
>In such a case, I could perhaps translate the resource bundles in
>French.
>
>Best Regards
>
>Bart
>
>--
>Prof Dr Bart Jourquin
>F.U.Ca.M. - G.T.M.
>Chaussee de Binche, 151a
>B7000 Mons
>Belgium
>Tel. : +32 65 323293
>Fax. : +32 65 315691
>http://message.fucam.ac.be/~jourquin
>
>
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Don Dietrick, BBN Technologies, dietrick@bbn.com
>10 Moulton Street, Cambridge, MA 02138
>617-873-3031 [fax]-2794
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
>--
>[To unsubscribe to this list send an email to "majdart@bbn.com"
>with the following text in the BODY of the message "unsubscribe
>openmap-users"]
>
>
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Don Dietrick, BBN Technologies, dietrick@bbn.com
>10 Moulton Street, Cambridge, MA 02138
>617-873-3031 [fax]-2794
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
>
>--
>[To unsubscribe to this list send an email to "majdart@bbn.com"
>with the following text in the BODY of the message "unsubscribe
>openmap-users"]
>
>
>
>--
>Prof Dr Bart Jourquin
>F.U.Ca.M. - G.T.M.
>Chaussee de Binche, 151a
>B7000 Mons
>Belgium
>Tel. : +32 65 323293
>Fax. : +32 65 315691
>http://message.fucam.ac.be/~jourquin

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]