Hi devs,
We need to define a strategy for better handling translations. I've
had a call with Guillaume and Jean-Vincent and here's the process we'd
like to propose:
* One person is in charge of http://l10n.xwiki.org/. This means
monitoring the work there, coordinating validation of key values and
ensuring validated translations are incorporated in the source tree.
Guillaume is willing to take that role for now.
* The XE release manager has the responsibility of taking the
validated keys on l10n.xwiki.org and committing them during the
Milestone 2 dev (before the RC1).
* The l10n manager should ping the release manager whenever there are
translated and validated keys ready to be incorporated or if there
have been important changes to be included in the release after M2 has
been released.
* The l10n manager should test XE and the applications after the keys
have been applied to ensure quality. Basically the l10n manager is
responsible for the quality of translations in general.
Here's my +1
Thanks
-Vincent
Hello,
I am working on creating blog entries using xwiki. I was wondering if it would be possible to create a template for the blog entries so that they will be more structured?
Thank you for your time and help!
Hande Aksac
Hi,
Since I'm rewriting the new Rendering component
(see http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture)
, we need to finalize the new syntax we want to have.
Right now I'v planned to use the same wiki syntax as now
(http://platform.xwiki.org/xwiki/bin/view/Main/
XWikiSyntax#HTextStyles) with only one change: all macros now need to
be closed.
For example: {macro}...{/macro} and {macro:text|param=value|.../}
Is that ok with everyone or do we want to make changes?
Thanks
-Vincent
Hello XWiki developers,
can someone explain me what is the strategy to define the mime-type of
an attachment?
I see not configurable map nor any setter on the attachment types.
Is there any way I can enrich this or is it simply taking over the
mime-type provided the browser (which, too often, ends up being
application/octet-stream) ?
thanks in advance
paul
Hi devs,
I've implemented support for Google Gadgets for pages and for panels.
http://incubator.myxwiki.org/xwiki/bin/view/Gadgets/
It is possible to browse the Google Gadget Directory and select a
gadget, set it's parameters and either:
- insert a call to a gadget macro in a wiki page
- create a panel with this gadget
It's basically working, except for a few Gadget translations issues in
the gadget settings page (for some gadgets).
To integrate in XE this requires:
- a slight modification to the PanelClass and the displaypanel macro (to
support a gadgeturl and gadgetprefs field)
- a few pages including a Gadget Groovy page (which requires programming
rights)
I think we should transform the Gadget Groovy to a plugin to avoid the
need for programming rights.
We can also from there create a special page type to make a display of
gadgets or panels like iGoogle or NetVibes.
It would store gadgets or panel lists in a special class with some
position parameters. And with some JS we can reposition the panels or
gadgets and save the config in the wiki page.
This would be an easy way to make some portal like experience in the wiki.
Who wants to takeover this from the dev team ? Do you think we can have
this in 1.8 ?
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hello!
For the XOO project, I would need a conversion module which has two
components:
1. converter from the swriter html in pure html.
2. bidirectional converter wiki syntax - html.
Is this already done in the Office Importer project? If yes, I would be
grateful if you tell me where can I find this components.
Best regards,
Cristina Scheau
Hello devs,
I'd like to reorganize the document footer as depicted in
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/DocumentFooter , namely:
1: Tags will be displayed after the document content, as links to tag
pages, and not in an input element in the Information tab as they are
now. They are still editable in view mode by clicking an edit button
available after the tags list.
2. The "Created by ... on ..." information about the document will be
displayed before "Last modified by...", under the document content, and
not down in the page footer, where it seems ambiguous (seems to be
referring to the whole wiki), nor in the Information tab.
3. The "Information" tab becomes "Related documents", since it does not
contain the tags and the creator anymore. The related documents are:
* parent (editable in view mode by the same mechanism as the tags)
* children
* included documents
* links and backlinks
4. A new "Rights" tab is displayed for admins after "Related pages",
basically providing the rights management UI.
Here's my +1.
Any objections / other suggestions?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/