[
https://issues.apache.org/jira/browse/WICKET-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639217#action_12639217
]
Igor Vaynberg commented on WICKET-1868:
---------------------------------------
when i updated this morning and ran our app none of the resources were
resolving.
i then ran wicket tests and there were 26 failures (in resource related
classes) and 20 errors because markup did not match since resources were not
being looked up.
i traced the problem to resourcenameiterator, basically next() was no longer
returning the full path to the resource. so instead of /foo/bar/Baz_en_us it
was returning .en_us and thus the property factory could not load any property
files.
i looked at svn history for resourcenameiterator and unrolled your last
patch...all tests (with the exception of the one you modified) passed, so i
unrolled the change.
so nothing was done blindly.
i did not have time to go and look at what exactly was broken, especially since
martijn wants to build 1.3.5 today/tomorrow.
nothing was lost, the patches are still in svn tab of this issue so they can be
easily reapplied...
> i18n package resource resolving depends too much on available locale
> --------------------------------------------------------------------
>
> Key: WICKET-1868
> URL: https://issues.apache.org/jira/browse/WICKET-1868
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.4, 1.4-M3
> Reporter: Eelco Hillenius
> Assignee: Eelco Hillenius
> Fix For: 1.3.5, 1.4-M4
>
>
> Instead of just depending on the session's locale, our i18n resolving
> algorithm should look at the form of the file names as well. For instance, if
> we get a request for /web/resources/foo.Bar/test_en_US.css, it should
> recognize that test is the base form, and try en and en_US on top of that,
> regardless of the locale that is was set in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
