18 Sep
2009
18 Sep
'09
1:35 p.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs