Re: [OpenMap Users] OpenMap localization

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"]