[xwiki-devs] [Proposal] Stop using $msg.get()
Hi, We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons: * Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search). * Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome). * It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing What should we do instead? Proposal: * Use the xwiki page translation feature... * Provide a XAR with all languages (and possibly a XAR per language). If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example. On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above. Thanks -Vincent
On Sep 18, 2009, at 10:36 AM, Vincent Massol wrote:
Hi,
We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons:
* Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search). * Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome). * It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing
What should we do instead?
Proposal:
* Use the xwiki page translation feature... * Provide a XAR with all languages (and possibly a XAR per language). If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example.
On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above.
It also makes translating stuff much easier since you don't need to find where a given key is used in the content... -Vincent
Thanks -Vincent
Hi, On Fri, Sep 18, 2009 at 10:38 AM, Vincent Massol <[email protected]> wrote:
On Sep 18, 2009, at 10:36 AM, Vincent Massol wrote:
Hi,
We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons:
* Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search). * Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome). * It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing
What should we do instead?
Proposal:
* Use the xwiki page translation feature... * Provide a XAR with all languages (and possibly a XAR per language). If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example.
I'm +1 for all 3. It would definitely make the application much better when used in multilingual mode. Guillaume
On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above.
It also makes translating stuff much easier since you don't need to find where a given key is used in the content...
-Vincent
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi Vincent, Vincent Massol wrote:
Hi,
We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons:
* Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search).
This applies to any page whose content is generated on the server side through velocity/groovy/etc. One option is to cache the rendered content and to search on it.
* Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome).
* It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing
But apps can have their own translation keys, right?
What should we do instead?
Proposal:
* Use the xwiki page translation feature...
* Provide a XAR with all languages (and possibly a XAR per language).
Does this mean we will have to maintain 22 (currently) XARs? For instance, when we change the layout of a page we will have to update each of its translations.
If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example.
On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above.
It will work for pages with pure wiki content, but I think it's going to be hard for pages generated through server-side scripting languages like velocity. Thanks, Marius
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Sep 18, 2009, at 1:35 PM, Marius Dumitru Florea wrote:
Hi Vincent,
Vincent Massol wrote:
Hi,
We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons:
* Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search).
This applies to any page whose content is generated on the server side through velocity/groovy/etc. One option is to cache the rendered content and to search on it.
Yes but that's not for now IMO and requires to rewrite lots of code.
* Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome).
* It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing
But apps can have their own translation keys, right?
Yes.
What should we do instead?
Proposal:
* Use the xwiki page translation feature...
* Provide a XAR with all languages (and possibly a XAR per language).
Does this mean we will have to maintain 22 (currently) XARs?
I suggest one XAR only for now. Anyway the number of XARs is not a pb since it's done by the build. The pb is more the number of pages.
For instance, when we change the layout of a page we will have to update each of its translations.
Page layout should be in templates/skins. Now yes when one page content is changed (like introduce a new header), someone (the community as it's done now) will have to change it for translated languages but it doesn't have to be done immediatly and will not prevent releases.
If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example.
On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above.
It will work for pages with pure wiki content, but I think it's going to be hard for pages generated through server-side scripting languages like velocity.
Code pages don't need to be translated. We need to test it to verify we can separate content from code but I'm pretty sure it's possible and we should have ways to do it if we want xwiki to be a proper dev platform anyway. Thanks -Vincent
On Sep 18, 2009, at 1:43 PM, Vincent Massol wrote:
On Sep 18, 2009, at 1:35 PM, Marius Dumitru Florea wrote:
Hi Vincent,
Vincent Massol wrote:
Hi,
We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons:
* Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search).
This applies to any page whose content is generated on the server side through velocity/groovy/etc. One option is to cache the rendered content and to search on it.
Yes but that's not for now IMO and requires to rewrite lots of code.
* Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome).
* It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing
But apps can have their own translation keys, right?
Yes.
We'd use this for reusable presentation components, which btw would find their ways in macros IMO. For example let's take the home page. It's including Main.Dashboard. Main.Dashboard is including Main.Spaces for example. So we could have instead in Main.Spaces something like: = Spaces = {{spaces/}} Where {{spaces}} will be a macro that lists spaces. That macro will use translations keys for the tooltip messages + the "create a new space" message for ex. Similarly if the code doesn't go in a macro, it could still use document resource bundles. This is what we'd do IMO for the Spaces page if it were not to go in a macro. But the Main.Spaces page would still be translated in several languages to translate the title.
What should we do instead?
Proposal:
* Use the xwiki page translation feature...
* Provide a XAR with all languages (and possibly a XAR per language).
Does this mean we will have to maintain 22 (currently) XARs?
I suggest one XAR only for now. Anyway the number of XARs is not a pb since it's done by the build. The pb is more the number of pages.
For instance, when we change the layout of a page we will have to update each of its translations.
Page layout should be in templates/skins.
Now yes when one page content is changed (like introduce a new header), someone (the community as it's done now) will have to change it for translated languages but it doesn't have to be done immediatly and will not prevent releases.
If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example.
On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above.
It will work for pages with pure wiki content, but I think it's going to be hard for pages generated through server-side scripting languages like velocity.
Code pages don't need to be translated.
We need to test it to verify we can separate content from code but I'm pretty sure it's possible and we should have ways to do it if we want xwiki to be a proper dev platform anyway.
I remove the "never" since it's not possible and I replace it with "As much as possible". Note that an idea is to implement an object for document resource bundles so that we can remove them from the xwikipreferences and make them work the same way as wiki macros work. Thanks -Vincent
Le 18-sept.-09 à 13:35, Marius Dumitru Florea a écrit :
Hi Vincent,
Vincent Massol wrote:
Hi,
We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons:
* Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search). This applies to any page whose content is generated on the server side through velocity/groovy/etc. One option is to cache the rendered content and to search on it.
Erm, in my (simple) extensions of the Curriki plugin I call renderPage... so I get all the msg.get result (and an amount of other potentially unwanted stuffs). This problem is by far not only a problem of msg.get!! (e.g. word contiguity, server generated lists...) I think the search plugin is also missing to know that a page is multilingual...
* Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome).
is an "instantiation process" what you are
* It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing
But apps can have their own translation keys, right?
(that sounds a normal install process to me).
What should we do instead? Proposal: * Use the xwiki page translation feature...
that changes nothing or?
If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example.
I don't think this is in any way reasonable. E.g. a highly designed home-page is instantiated differently in different language...
On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above.
It will work for pages with pure wiki content, but I think it's going to be hard for pages generated through server-side scripting languages like velocity.
There are three sorts of pages on our platform: - pages that use code and typically render differently depending on user, time, ... generally these are pages by developer, these are using msg.get and many other stuffs. They're generally not translated - pages that are static and are sometimes translated. Generally no programming or msg.get - pages that only contain one or two lines of code and attached objects. They're generally not translated and use (outside) programmes to render. msg.get quite much included of course! I am not sure you proposal fits any except the static pages. Or? paul
participants (4)
-
Guillaume Lerouge -
Marius Dumitru Florea -
Paul Libbrecht -
Vincent Massol