+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

+1 Best regards, Andreas 2011-12-05 16:58, Vincent Massol skrev:

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

Hi all, On 12/05/2011 04:58 PM, Vincent Massol 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

Well the only problem with that is that translation keys are used in the XE pages but written in ApplicationResources.properties: it means that if one upgrades the war but not the xar, when keys change, his stuff will fail. This is to say I prefer we don't have "force renames" as in, we break keys only when we really need it (new keys, removing old unused keys, etc). This rename rule above means that internal refactoring (renaming a module) could lead to broken translation keys for the user. We could: have a rule based on common sense wrt purpose of the module the key comes from, on forbidding prefixes such as core or xe which are, let's say, unneeded, and we don't change it when we change module name or submodule name or whatever. Or we could really hurry to implement translations injection from pages and put all translations used in XE in the xar and leave only translations used by the vms in the war, and drop the short toplevel project name, since I find it will be highly redundant (platform and enterprise almost everywhere). This is to say I am -0 to change all this now, until we don't have a nice way of separating the xar translations from the war translations. Although no existing translations will be changed, though, so we could say that this is the rule, I mean i have nothing against the fact that there is a rule, I only don't like the idea of renaming things.

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.

I don't know if it's on purpose or just not the scope of this proposal, but I would really think we should also have a plan about injecting translations stored in wiki pages (is it not in the proposal above because we plan to drop it or just not the scope?). Thanks, Anca

Here's my +1

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