views:

226

answers:

2

I don't know anything about internationalization.

I have a project with several packages. I am using Eclipse's built-in "Externalize Strings" wizard to extract String constants in my classes to a properties file and replace those Strings with calls to a static accessor. So instead of

System.out.println("Hello, world!");

I end up with

System.out.println(Messages.getString("MyKey"));

and a Messages utility class in every package (which provides a static getString method for getting the desired String from a ResourceBundle [in this case a .properties file]). Is it best to have a Messages class in every package, or have a single Messages class for the entire project?

+2  A: 

I would keep one-per-package. This way maintenance/refactoring/unit-testing is much easier.

Also, there are no global dependencies on a single file.

Alexander Pogrebnyak
+2  A: 

I'm in favor of a global localization file. You will have duplicate keys ("OK", "Cancel") which would require duplication or nesting, and interfacing with outside localization people is easier if the resources are consolidated.

Michael Brewer-Davis
The fewer the files, the better. Consolidating shared strings, as Michael said, into a single file promotes translation consistency. And it's easier to fix bugs if you only have to look for them in a few files.
Mike Sickler
OK- you're asking about the Messages class...Then one per package.
Mike Sickler
@Mike--Why have more classes than resource files?
Michael Brewer-Davis
So you suggest a single resource file with all translatable strings from all packages and a single "Messages" class, say in package "org.mypackage.i18n"?
Jeffrey Finkelstein
That's what I do. I worked with one codebase that worked the opposite way (multiple resource files and multiple classes) and didn't like it. Interested to know if some see a clear advantage to multiple classes.
Michael Brewer-Davis