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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
