I18nStrutsAdapter does not resolve i18n resources

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.0
  • Fix Version/s: TBD
  • Component/s: I18N, Paging/Sorting
  • Labels:
    None
  • Application server:
    Tomcat 5.5.7

Description

This is odd. I18nStrutsAdapter cannot resolve *part* of internationalized resources. The resources for tablecolumn header name, passed as a titeKey parameter in <display:column> *do get* resolved according to provided request locale while the messages that appear in a paging banner (paging.banner.*) seem to get resolved from the displaytag.properties rather than from messages defined in struts-config.xml. There's no fancy configuration: struts, tiles, displaytag and accompanying libraries are placed within webapp's WEB-INF/lib.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Oliver Siegmar added a comment -
This also affects version 1.1 and the I18nSpringAdapter.
Show
Oliver Siegmar added a comment - This also affects version 1.1 and the I18nSpringAdapter.
Hide
Permalink
Don Ngo added a comment -
I18nJstlAdapter has the same problem on version 1.1
Show
Don Ngo added a comment - I18nJstlAdapter has the same problem on version 1.1
Hide
Permalink
Toby Neumann added a comment -
This is not a problem of the various adapter implementations. In fact, these adapters are only involved resolving the resources for table title and column titles. All the built-in texts which are listed in the file displaytag.properties do not use that mechanism but access the properties directly (in file TableProperties.java). I think that is what is wrong.

Is there a reason why it could not be done in the same way?
Show
Toby Neumann added a comment - This is not a problem of the various adapter implementations. In fact, these adapters are only involved resolving the resources for table title and column titles. All the built-in texts which are listed in the file displaytag.properties do not use that mechanism but access the properties directly (in file TableProperties.java). I think that is what is wrong. Is there a reason why it could not be done in the same way?

People

  • Reporter:
    Dominik Drzewiecki
Vote (5)
Watch (4)

Dates

  • Created:
    Updated: