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 sidethrough velocity/groovy/etc. One option is to cache the rendered contentand 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-standingBut 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 likevelocity.
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
