----- "Emmanuel Bernard" <emman...@hibernate.org> wrote: > I don't see i18n as something that should necessarily be packaged > inside a component. Resource keys are generally grouped in one or two > files for the overall application (so that fixing a typo is quick).
You must be developing small or monolith applications then ;) The common way I know of (from eclipse apps) is that the resource bundles *specific* to that module/plugin is stored in the module and if there are some common phrases/messages they are simply put into separate module/plugin or you simply depend on that module/plugin you want to share that common phrase with. > If > you have to dig into individual or even third party components, it > becomes a pain point. So I don't see that as encapsulation violation > (or at this stage, you have to consider that displaying the error > message to the user is violating encapsulation). Not following this, additional resource bundles is/should be possible to add translations to 3rd party components without changing it. -max > > You would put the @ResourceBundle on the constraint annotation? I > don't like the idea, it would encourage the creation of a myriad of > different resource bundle files. Also today the spec allows to inject > your own ResourceBundle implementation via the MessageInterpolator > (will even be better in Hibernate Validator after HV-238). Adding a > @ResourceBundle will clash with this freedom. > > Another point I want to mention, Hibernate Validator 3.x had support > for a more sophisticated RB approach but it turned out to be a big > ball of inconsistency and holes and I purposely simplified the model > in Bean Validation. > > On 15 févr. 2010, at 21:36, Hardy Ferentschik wrote: > > > Hi, > > > > Having multiple resource bundles and some custom way of specifying > these bundles is > > related to HV-238 and HV-251. > > > > Having a ResourceBundleLocatorStrategy should solve your problem > Gunnar, right? > > > > The default strategy could behave like it does now and we can > provide an additional strategy > > which allows for multiple resource bundles. You would specify the > strategy in the hibernate > > config file. The names for the different resource files could also > be specified in the > > config (or maybe there is a better way!?) > > > > --Hardy > > > > > > On Mon, 15 Feb 2010 16:51:13 -0300, Gunnar Morling > <gunnar.morl...@googlemail.com> wrote: > > > >> I agree, there probably won't be that many 3rd-party constraint > vendors :-) > >> > >> Nevertheless I think the problem is not too exotic. In my day job > for > >> example we're building a large-scale enterprise application, which > is made > >> up of multiple JARs ("components") developed by multiple, > independent > >> development teams. > >> > >> Now it would be great, if two teams could develop independently > their custom > >> constraints, specific to their component. As of now they would have > to > >> provide a unified ValidationMessages.properties, violating the > encapsulation > >> of the components. > >> > >> A rather simple solution might be a meta-annotation @MessageBundle, > which > >> optionally could be used at constraint annotation type declarations > to > >> specify the name of the message bundle to be used. That way name > collisions > >> between constraints from different JARs still could occur, but > finding > >> unique names should not be too hard. If that meta-annotation is not > given, a > >> fallback to ValidationMessages.properties might be used. > >> > >> WDYT? > >> > >> Cheers, Gunnar > >> > >> > >> 2010/2/15 Emmanuel Bernard <emman...@hibernate.org> > >> > >>> Yes, you need to copy it over or more likely adapt the messages to > your > >>> application (in which case you don't care). > >>> The problem with listing the resource bundle is that you need an > order to > >>> specify which has precedence over which. > >>> > >>> Another solution could be some sort of plugin system where 3rd > party > >>> constraint makers can reference automatically a resource bundle. > But > >>> realistically, how many 3rd party constraint makers will there > be? > >>> > >>> The question is: is the additional complexity for the solution > worth the > >>> current problem? > >>> > >>> On 14 févr. 2010, at 22:00, Gunnar Morling wrote: > >>> > >>> > Hello you two, > >>> > > >>> > recently I thought about the following situation: > >>> > > >>> > * I have a JAR containing a custom constraint on the class path > (could be > >>> a constraint provided by some 3rd-party constraint vendor) > >>> > * I have another custom constraint within the actual project > itself (and > >>> therefore a ValidationMessages.properties as well) > >>> > > >>> > Now the ValidationMessages.properties provided by the 3rd-party > vendor is > >>> hidden by my own ValidationMessages.properties, which - if I'm not > mistaken > >>> - requires me to copy the contents of the first to the latter. > >>> > > >>> > Is there any better solution to this problem? > >>> > > >>> > Maybe BV/HV should provide some means for constraint vendors to > specify > >>> the resource bundle containing messages? If you think, that's > useful I'd > >>> create a JIRA issue for that one. > >>> > > >>> > Thanks for any ideas, > >>> > > >>> > Gunnar > >>> > >>> > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- /max _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev