In our app we have a messages.properties file which contains all of the strings that will be shown to the UI. We have a small app with a few screens and it's already getting unwieldy with duplicate string values throughout.
Right now we have it organized with page specific strings separated out with whitespace and comments, with a section for each jsp with the property name having a prefix of the page name. We also have sections for entities, for instance, anywhere we show the user's email address, we would reference the property user.email for the label for that input or output field. We have another section for error and status messages, and finally one last section with global messages like "Submit" and "Cancel"
There's got to be a better way, and I'm wondering if you know what it is.
I don't think there is a universal "better way". I tried Googling for "best practice" advice on this, and found nothing that talked about how best to structure the property namespace for i18n.
(This I found somewhat surprising. There's usually someone out there who is prepared to put forward their ill-considered opinions on something like this as "best practice". Or perhaps, I'm too cynical.)
FWIW, my general advice would be:
- be systematic and consistent about the property names and the property file structure,.
- don't be afraid to use resource bundle inheritance if there is a lot of duplication,
- if the property files or resource bundles get too large, partition them.
But I expect you already know and do all of that.
Finally, don't get too hung up about getting this "just right". There is no perfect solution, and what you are currently doing is probably good enough ... according to the criteria of whoever is paying you to do this work.
来源：https://stackoverflow.com/questions/4414313/how-to-organize-java-properties-entries-for-internationalization