Struts 1.2.9 - Questions around custom internationalization
Asked Answered
G

1

6

We have a legacy application that uses Struts 1.2.9. The app is currently internationalized the standard way - .properties files for all UI labels, errors, messages, etc; <message-resouces> definition for each .properties file in struts-config.xml using default Factory & MessageResources definitions; <bean:message> usage in all JSPs. This has worked great till now, but for the fact that the application itself a framework for services used by a few hundred (yes 100's!) other applications internally.

We have a requirement to extend the i18n functionality as follows:

  1. Define a custom directory for .properties files - so this would be outside the scope of the classpath; basically not inside the .war package. The idea is to support just message string changes w/o really having to redeploy the entire application.
  2. This custom directory will also contain per supported applications messages - this could be just a subset of the existing ones or the entire set of resources tailored specifically to that application.
  3. Custom way of supporting per request basis Locale setting - barring all other considerations (default stack, classpath/package lookups, etc.) this is analogous to the way I18nInterceptor works in Struts2 with the requestOnlyParameterName attribute set to true.

Yes, I do understand that a few 100 bundles loaded at the same time will be memory intensive, but that is acceptable in our case.

Any help is appreciated - be it direction, sample code, etc.

Note: I completely agree that moving onto a newer UI platform is probably the best solution. But we can't.

TIA.

Gauger answered 18/10, 2015 at 16:12 Comment(1)
Looks like implementing your own MessageResources and MessageResourcesFactory is the way to go. Thoughts?Gauger
S
0

I had a similar requirement in a spring project, not only for i18n, also web services endpoints and other kind of properties.

We accomplish that requirement by adding that directory, in which we place the properties files, into the classpath in the server start configuration file.

Tested and working in weblogic 11g (Preproduction and production) and in a tomcat server (development environment).

Hope helps

Southwester answered 10/11, 2015 at 20:53 Comment(1)
Thanks for your suggestion Francisco. If I recall correctly, when you define <message-resouces>, you define the package name to pick the properties files from. If I had a root directory with many sub-directories, each potentially containing multiple bundles, I don't think this classpath setting alone will work. You'll need a mechanism by which for every request, the locale and in turn the right properties bundle should be picked from the corresponding directory for that application below the root dir.Gauger

© 2022 - 2024 — McMap. All rights reserved.