1 Feb
2012
1 Feb
'12
12:51 p.m.
On Wed, Feb 1, 2012 at 12:27 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
Hi all,
On 12/05/2011 04:58 PM, Vincent Massol wrote:
You are forgetting that when we rename we keep the old name in a
deprecation section. Look at the end of
ApplicationResources.properties.
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.
--
Thomas Mortagne
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs