Managing library project, iternationalization and errors

[Karsten Wutzke]

Hello!

I'm not quite happy with a current design aspect in my software. I use
an own library into which I put a bunch of packages and classes for
reuse in other projects.

For each specific project, I created one huge centralized class
containing ALL keys of localizable (GUI) elements, which currently are
all strings. By creating one big file, I can refer to only one file
and forget about knowing many. Is that a good idea? I keep remembering
"OOP promotes distributed programming" and what I do/did (using one
centralized class) is pretty much the contrary.

Does anyone have a good advice how to manage the GUI keys? I already
use property files with resource bundles, so I mean where to put the
property file keys/identifiers which refer to a localized resource/
string when writing the actual code

GuiElem.OK_ACTION_NAME_KEY
GuiElem.CANCEL_ACTION_NAME_KEY

^^all centralized in project specific class

2. I didn't have to care much about error messages thus far, I don't
mean those which go to the log file, those are *not* localized anyway.
But what about those which will be displayed to the user?

I have some custom classes to ease server communication, an
abstraction which is part of the API. If that fails for some reason,
it is supposed to log and return some indicator what went wrong. I'm
not sure but error codes come to my mind. On demand the client using
the class/object/method can decide what to do with the returned code.

Again, this raises the question for how to design error codes, that
is, where to put them -> centralized vs. uncentralized...

I'd gladly appreciate if you could share your experiences with me
considering this is so trivial. Some pros cons discussion is welcome
as well as best practices...

Karsten

 

[GArlington]

Hello!

I'm not quite happy with a current design aspect in my software. I use
an own library into which I put a bunch of packages and classes for
reuse in other projects.

For each specific project, I created one huge centralized class
containing ALL keys of localizable (GUI) elements, which currently are
all strings. By creating one big file, I can refer to only one file
and forget about knowing many. Is that a good idea? I keep remembering
"OOP promotes distributed programming" and what I do/did (using one
centralized class) is pretty much the contrary.

Does anyone have a good advice how to manage the GUI keys? I already
use property files with resource bundles, so I mean where to put the
property file keys/identifiers which refer to a localized resource/
string when writing the actual code

GuiElem.OK_ACTION_NAME_KEY
GuiElem.CANCEL_ACTION_NAME_KEY

^^all centralized in project specific class

2. I didn't have to care much about error messages thus far, I don't
mean those which go to the log file, those are *not* localized anyway.
But what about those which will be displayed to the user?

I have some custom classes to ease server communication, an
abstraction which is part of the API. If that fails for some reason,
it is supposed to log and return some indicator what went wrong. I'm
not sure but error codes come to my mind. On demand the client using
the class/object/method can decide what to do with the returned code.

Again, this raises the question for how to design error codes, that
is, where to put them -> centralized vs. uncentralized...

I'd gladly appreciate if you could share your experiences with me
considering this is so trivial. Some pros cons discussion is welcome
as well as best practices...

Karsten

Usually you should have resource packages per language, when you
install the application or the applet is loaded it should read the
language settings on the client and load appropriate resource per
language.
Further more you might want to separate resources by something like:
Res.Messaging - all messaging localised strings, Res.Common - all
common localised strings, GUI.Common - all common forms elements and
labels (there are not too many), GUI.ApplicationSpecific - application
specific localised strings...