On Thu, Sep 8, 2011 at 12: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

+1 I tough this was already voted for translations and configurations keys actually.

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

Until we do this there is already a deprecation mechanism for translations in ApplicationResources.properties file itself.

Of course in the future each module should be able to contribute both resource properties (but they would use the same naming scheme!).

We need to move on the translation component for sure...

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.

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne