Currently, the module framework prepends your moduleId to the start of all message property keys that don’t have them. (E.g. if I say in messages.properties: “yes=Yes” this gets converted to “mymoduleid.yes=Yes”.)
Unless you have a (hacky) message code saying “openmrs.property.MESSAGE_PROPERTY_ALLOW_KEYS_OUTSIDE_OF_MODULE_NAMESPACE=true” in which case the moduleId is not prepended.
I propose that we get rid of both of these behaviors.
The first behavior is nonstandard, and confusing, and the goal it is trying to achieve is misguided in the first place.
The second behavior is hacky but required to get around the first behavior (e.g. if you want a “distribution module” to define message codes for other modules, or to do l10n of metadata), and it doesn’t work with i18n tooling like transifex (because a translator will just translate “true”, thus breaking the behavior).
Unless anyone argues convincingly that these behaviors should stay, I am going to rewrite TRUNK-3920 to reflect removing these behaviors.
(This will cause minor backwards-compatibility problems for some modules that are relying on the first behavior, but these will be immediately-visible, and trivially easy to fix. In any case, we should do this as part of the Platform 2.0 release.)
So how will you handle conflicts? I.e where different modules and core have same message codes? Do you intend to validate them and ensure there are no duplicates to override each other?
I would hope that modules are able to override core messages, and this just
naturally works. So, no, we should not validate duplicates.
(I don’t think we need to solve the situation of trying to ensure
deterministic behavior if two modules try to define the same code. If we
were to solve that it should go via module startup order.)
Sorry for coming late to this, but I’m a little confused. If we are eliminating namespacing of message bundle keys, what will be preventing conflicts between keys? Will the framework know which module code is requesting the message? Or will it just be random, depending on which module was loaded last? Do we identify the module when requesting a message?
For example, imagine I had 30 modules that all used different messages for the key title, how would the right title be rendered for each module?
The idea is that you should still namespace message codes, but that the
module framework won’t automagically prepend the moduleid as a namespace if
you haven’t already. (Because this is non-standard, confusing, and it
prevents you from defining codes outside your namespace, which we sometimes
want.)
It’s already the case that the archetype and basic module start you off
with something like this:
${project.parent.artifactId}.title=Your Module
So most modules are already adding the module id themselves already.
So then the general advice to module developers is to ensure that message codes are namespaced but the module framework will no longer do this automatically? Is there any estimate for when this change expected to be released?
I have sent a PR at [1]. Please review it and let me know any issues.
After the removal of this behaviour, I thought that there is no need of test method WebModuleUtilTest.copyModuleMessagesIntoWebapp_shouldPrefixMessagesWithModuleId. Hence I removed it. Please correct me if I am wrong.
Also please provide the wikis that you know which has to be updated regarding this. I will also go through to find out. Still a newbuddy, so still getting to know things.
Still a newbuddy, so still getting to know things.