[xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties
5 Dec
2011
5 Dec
'11
4:58 p.m.
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
5 Dec
5 Dec
4:59 p.m.
Note that I had sent a proposal mail but it didn't receive a lot of feedback:
http://xwiki.markmail.org/thread/tnrfvkavbdeuw4zl
Since we need to agree on this, I'm resending it as a formal vote.
Thanks
-Vincent
On Dec 5, 2011, at 4: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
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
5:02 p.m.
New subject: [xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties
+1
Thanks,
Marius
On Mon, Dec 5, 2011 at 5:58 PM, Vincent Massol <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:23 p.m.
New subject: [xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties
On Mon, Dec 5, 2011 at 4:58 PM, Vincent Massol <vincent(a)massol.net> 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
Same +1 and same note about the already existing deprecated
translations section which is supported by l10n.xwiki.org from my
previous answer of the proposal.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
6 Dec
6 Dec
10:39 p.m.
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
31 Jan
31 Jan
4:15 p.m.
FYI the rule is now published on
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla…
It's also documented at the top of the ApplicationResources.properties file
Thanks
-Vincent
On Dec 5, 2011, at 4: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
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
1 Feb
1 Feb
12:27 p.m.
New subject: [xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:51 p.m.
New subject: [xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties
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 
4 Feb
4 Feb
6:49 a.m.
New subject: [xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties
On 02/01/2012 06:51 AM, Thomas Mortagne wrote:
On Wed, Feb 1, 2012 at 12:27 PM, Anca
Luca<lucaa(a)xwiki.com> wrote:
To be more specific, the rename rule isn't about forcing renames, but
about copying the old translations for the new names. So, let's say that
we rename the key old.module.key to new.module.key. Being an old key, it
already has translations in several languages. Without this new "rename"
feature, there are two options: manually copy the translations as well,
or add only the default language (English), hoping that some kind
translators are going to do the work again and re-translate the key to
their languages. This new feature just says that when performing the
nightly reimport of the default bundle (English), if a new annotation is
detected for a key, l10n.xwiki.org will automatically copy the existing
translations from the old key to the new key.
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.
>
>
>>
>> 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
>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
4608
days inactive
4669
days old
8 comments
6 participants
participants (6)
-
Anca Luca -
Andreas Jonsson -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol