4 Feb
2012
4 Feb
'12
6:49 a.m.
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/