[xwiki-devs] [vote] Next localization steps
Hi devs, The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item): 0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components 1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me 2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me 3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers 4. Propose a standard for writing keys Next week - me + discussion on devs 5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners 6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources). Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet. I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge.
From me, +1 to all of these. WDYT? Any volunteers where needed? -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hello, Sergiu Dumitriu wrote:
Hi devs,
The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item):
0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components 1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me 2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me 3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers 4. Propose a standard for writing keys Next week - me + discussion on devs 5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners ok, I can help and do that for the scheduler and workstream
6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources). Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers
A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet. I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge. $l10n.get("key") ?
-0 I don't like it very much. What about $messages.get("key") ?
From me, +1 to all of these.
+1 for all the rest
WDYT? Any volunteers where needed?
On Wed, Oct 15, 2008 at 9:40 AM, Jerome Velociter <[email protected]> wrote:
Hello,
Sergiu Dumitriu wrote:
Hi devs,
The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item):
0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components 1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me 2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me 3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers 4. Propose a standard for writing keys Next week - me + discussion on devs 5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners ok, I can help and do that for the scheduler and workstream
6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources). Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers
A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet. I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge. $l10n.get("key") ?
-0 I don't like it very much. What about $messages.get("key") ?
Same here not really for me but seems too technical for a user.
From me, +1 to all of these.
+1 for all the rest
+1
WDYT? Any volunteers where needed?
Most of the work is already done for application manager and wiki manager, simply it's another toold so I will take care of "migration" for theses two plugins/applications when it will depends on 1.7 (when 1.7 will be stable branch).
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Jerome Velociter wrote:
Hello,
Sergiu Dumitriu wrote:
Hi devs,
The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item):
0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components 1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me 2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me
I don't think you can remove the old XWikiMessageTool in XWiki 1.9. Even if this seems far away, a lot of applications use it. Except if you provide backwards compatiblity for $msg and that things work seemlessly for applications of course.
Is there a doc of the new component ?
3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers 4. Propose a standard for writing keys Next week - me + discussion on devs 5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners
ok, I can help and do that for the scheduler and workstream
6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources). Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers
A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet. I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge.
$l10n.get("key") ?
-0 I don't like it very much. What about $messages.get("key") ?
From me, +1 to all of these.
+1 for all the rest
WDYT? Any volunteers where needed?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Ludovic Dubost wrote:
Jerome Velociter wrote:
Hello,
Sergiu Dumitriu wrote:
Hi devs,
The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item):
0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components 1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me 2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me
I don't think you can remove the old XWikiMessageTool in XWiki 1.9. Even if this seems far away, a lot of applications use it. Except if you provide backwards compatiblity for $msg and that things work seemlessly for applications of course.
The problem is not $msg from velocity, but 3rd party plugins that explicitely uses com.xpn.xwiki.web.XWikiMessageTool. I could put the localization component behind $msg today and it will be 100% backwards compatible.
Is there a doc of the new component ?
Yes, besides javadoc, there's http://code.xwiki.org/xwiki/bin/Plugins/LocalizationPlugin
3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers 4. Propose a standard for writing keys Next week - me + discussion on devs 5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners
ok, I can help and do that for the scheduler and workstream
6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources). Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers
A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet. I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge.
$l10n.get("key") ?
-0 I don't like it very much. What about $messages.get("key") ?
No, the proper term is Localization, and the official acronym is L10N. I could go with $localization if $l10n is too cryptic. Or, an alternative is to take the risk and replace $msg until we can access $services.localization.
From me, +1 to all of these.
+1 for all the rest
WDYT? Any volunteers where needed?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
ok found some time to review this email at last. Sorry for the delay. On Oct 15, 2008, at 3:47 AM, Sergiu Dumitriu wrote:
Hi devs,
The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item):
0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components
* I see you've used non threadsafe components for bundles. I don't think we should do that. * I'd prefer to use getMessage() instead of get() which is too cryptic for a LocalizationManager class IMO. * The Bundle implementations are actually BundleManager I think, each managing a different type of resources (ResourceManager which might be a better name) * I think there's an important bug. The LocalizationManager is supposed to be threadsafe but the use() method (I'm still unsure what it does and how it's used) doesn't look threadsafe * I'm surprised there are not tests. We must really write the tests either before the code or at the very least at the same time as otherwise they're loosing half of their power (which is to improve design) * WikiInformation doesn't seem to belong to this module. * I'm really missing tests to understand how the localization module is used. * Is it possible for an application to specify a single resource document and not use the other resource documents located in other applications in the wiki? I think either a namespace at the level of LocalizationManager (for example: getResourceCollection(String namespace)) or at the level of getMessage(String name, String namespace) (I prefer at the level of LocalizationManager) might be better. This also means introducing the concept of ResourceCollection as we have in the configuration module for configurations (ConfigurationCollection). * Is there a design document listing all the use cases we want to have somewhere?
1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me
After we agree on 0, sure.
2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me
+1 but it's possible we'll need the new velocity bridge to make the adaptation to the new component. I'd really like that we don't model the new component against the old message tool (like get() methods for ex).
3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers
+0, I think this is not a priority for 1.7 (it's not even defined in our roadmap). I'd much much prefer you finish the Blog application overhaul which is planned and people are waiting for it. And finish the velocity module refactoring for uberspectors + ability to support macro reloading (not sure what's the status on that one).
4. Propose a standard for writing keys Next week - me + discussion on devs
ok
5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners
Shouldn't we start extracting applications from XE into their own modules first?
6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources).
ok
Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers
Tests are a priority for validating the design.
A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet.
And I really don't like using get(). Again I'm 100% sure we shouldn't consider the old message tool to model our new components.
I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge.
Yes and at that time we should be able to map the old msg.get() to the new code.
From me, +1 to all of these. WDYT? Any volunteers where needed?
Thanks -Vincent
Vincent Massol wrote:
ok found some time to review this email at last. Sorry for the delay.
On Oct 15, 2008, at 3:47 AM, Sergiu Dumitriu wrote:
Hi devs,
The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item):
0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components
* I see you've used non threadsafe components for bundles. I don't think we should do that.
WDYM? Where exactly should those be used? I found some unsafe code in Pulled*Bundle, the list holding the pulled bundles wasn't synchronize (I thought I already synchronized it, maybe I accidentally removed the sync block in one of the refactorings).
* I'd prefer to use getMessage() instead of get() which is too cryptic for a LocalizationManager class IMO.
OK, but for backwards compatibility we should have get() also. Should it be deprecated and planned for a future removal?
* The Bundle implementations are actually BundleManager I think, each managing a different type of resources (ResourceManager which might be a better name)
I don't think Resource is better, since it seems generic. We're dealing with localization resources, which are called (AFAIK) bundles.
* I think there's an important bug. The LocalizationManager is supposed to be threadsafe but the use() method (I'm still unsure what it does and how it's used) doesn't look threadsafe
It is, since each bundle type uses a synchronized block. The synchronization is on the execution context, and unless someone copies some entries between two contexts, each execution context should hold its unique list of pulled bundles. The method from DefaultLocalizationManager doesn't need to be synchronized, since it merely forwards the call to a threadsafe method.
* I'm surprised there are not tests. We must really write the tests either before the code or at the very least at the same time as otherwise they're loosing half of their power (which is to improve design)
Agreed. I'll start doing proper TDD from now on.
* WikiInformation doesn't seem to belong to this module.
Partially agree. Some things should be here (the language ones), but I had to include some things that belong to other modules (the wiki constants, getCurrentWikiName). What do you propose?
* I'm really missing tests to understand how the localization module is used.
Hm... I thought the javadoc should be descriptive enough. I'll rework the javadoc to make it more clear.
* Is it possible for an application to specify a single resource document and not use the other resource documents located in other applications in the wiki? I think either a namespace at the level of LocalizationManager (for example: getResourceCollection(String namespace)) or at the level of getMessage(String name, String namespace) (I prefer at the level of LocalizationManager) might be better. This also means introducing the concept of ResourceCollection as we have in the configuration module for configurations (ConfigurationCollection).
I thought of that, too, but I thought it is too complicated for the moment, adding little benefit. This could be improved in the future, if we find it necessary. I don't think that this separation is needed, since applications should use prefixed key names, and it might be hard to mix applications otherwise. What I mean is that once we use Interface Extensions to interweave applications, several collections should be used in parallel.
* Is there a design document listing all the use cases we want to have somewhere?
No. My fault. We should write it collaboratively.
1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me
After we agree on 0, sure.
2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me
+1 but it's possible we'll need the new velocity bridge to make the adaptation to the new component. I'd really like that we don't model the new component against the old message tool (like get() methods for ex).
But this will make upgrades hard, unless we have an optional backwards compatible behavior.
3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers
+0, I think this is not a priority for 1.7 (it's not even defined in our roadmap). I'd much much prefer you finish the Blog application overhaul which is planned and people are waiting for it. And finish the velocity module refactoring for uberspectors + ability to support macro reloading (not sure what's the status on that one).
4. Propose a standard for writing keys Next week - me + discussion on devs
ok
5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners
Shouldn't we start extracting applications from XE into their own modules first?
We've been planning to do this for some time, with little progress.
6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources).
ok
Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers
Tests are a priority for validating the design.
A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet.
And I really don't like using get(). Again I'm 100% sure we shouldn't consider the old message tool to model our new components.
Again, this is in case we remove the MessageTool (which we should) and clients want to upgrade without manually replacing all the instances of $msg.get they have in their wiki.
I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge.
Yes and at that time we should be able to map the old msg.get() to the new code.
From me, +1 to all of these. WDYT? Any volunteers where needed?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (5)
-
Jerome Velociter -
Ludovic Dubost -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol