18 Sep
2009
18 Sep
'09
10:36 a.m.
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
18 Sep
18 Sep
10:38 a.m.
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
10:50 a.m.
Hi,
On Fri, Sep 18, 2009 at 10:38 AM, Vincent Massol <vincent(a)massol.net> wrote:
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
On Sep 18, 2009, at 10:36 AM, Vincent Massol wrote:
I'm +1 for all 3. It would definitely make the application much better when
used in multilingual mode.
Guillaume
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
1:43 p.m.
On Sep 18, 2009, at 1:35 PM, Marius Dumitru Florea wrote:
Yes.
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.
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
Hi Vincent,
Vincent Massol wrote:
Yes but that's not for now IMO and requires to rewrite lots of code.
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.
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.
2:15 p.m.
On Sep 18, 2009, at 1:43 PM, Vincent Massol wrote:
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.
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
On Sep 18, 2009, at 1:35 PM, Marius Dumitru Florea wrote:
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.
Hi Vincent,
Vincent Massol wrote:
Yes but that's not for now IMO and requires to rewrite lots of code.
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.
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. 
1:52 p.m.
Le 18-sept.-09 à 13:35, Marius Dumitru Florea a écrit :
(that sounds a normal install process to me).
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
Hi Vincent,
Vincent Massol wrote:
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...
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).
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? > 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.
5530
days inactive
5530
days old
6 comments
4 participants
participants (4)
-
Guillaume Lerouge -
Marius Dumitru Florea -
Paul Libbrecht -
Vincent Massol