On Wed, Feb 1, 2012 at 12:27 PM, Anca Luca <[email protected]> wrote: > 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.
You are forgetting that when we rename we keep the old name in a deprecation section. Look at the end of ApplicationResources.properties. > > 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 > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
