+1 Thanks, Marius
On Mon, Dec 5, 2011 at 5:58 PM, Vincent Massol <[email protected]> wrote: > Hi devs, > > I see that in ApplicationResources.properties we now have some wrongly named > properties. > For example for the scheduler I find properties of the type xe.scheduler.* > but the scheduler is now in the platform. > > There are also resources named core.* > > Thus I'd like to propose a simple rule: > > <short top level projet name>.<short module name>.<propertyName> > > where: > <short top level projet name> = top level projet name without the "xwiki-" > prefix, for example: commons, rendering, platform, enterprise, manager, etc > <short module name> = the name of the maven module without the <short top > level project name> prefix, for example: oldcore, scheduler, activitystream, > etc > <propertyName> = the name of the property using camel case, ex: > updateJobClassCommitComment > > For example the property core.importer.package.version would be renamed in > platform.web.packageVersion > > The only issue is when we rename modules we need to rename the properties for > that module but I don't see any way out of this if we want to have expressive > property names. But at least it's an easy and mechanic change > > I also propose to introduce a different resource property file that will hold > deprecated properties and that we can put in the xwiki-platform-legacy > module. We could call it DeprecatedApplicationResources*.properties > > Of course in the future each module should be able to contribute both > resource properties (but they would use the same naming scheme!). > > Even though this is not the topic of this mail this is how I'd implement this > in the future: > * Implement a TranslationPropertiesConfigurationSource that is initialized by > reading all property files found in the classloader under > META-INF/translations.properties and > META-INF/translations-deprecated.properties. This component would listen to > observation events so that when a new jar is installed by the extension > manager it can check if it provides some translations and add them. > * Have a Translation Manager component which is the main API to be used by > other modules wishing to get translations. This manager would use the > TranslationPropertiesConfigurationSource component. > > Here's my +1 > > Thanks > -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
