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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
