Hi Devs,
Even though we don’t have listed on http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices I believe the following has already been agreed but I’d like to add it there so I’m sending it as a proposal.
So I propose that:
* Any java code requiring translation should put them in an ApplicationResources.properties file at the root of the JAR (not the global ApplicationResources.properties in oldcore!)
* Any wiki page requiring translations should put them in a Translations page in the space for the app.
Special case:
* For Macro UI modules (ie containing only wiki macros), we put them in the Macros space and in this case we should use a Macros.XXXTranslations page for each module. We’ll need to decide what we want to do in the future.
Also, even if some existing module is wrongly using the ApplicationResources.properties in oldcore (for example), we should still follow the rules above and start doing it in the new way.
WDYT?
Thanks
-Vincent
Hi all,
I would like to create a repository on xwiki-contrib for a little
application I wrote.
Basically it allows to manage a document base like the one about
IETF's RFCs (http://www.ietf.org/rfc.html)
Name: application-rfc
Tools: NONE
Thanks,
Fabio
P.S.: I think I can create the repo by myself, so this mail was just
to announce the repo creation.
Can I delete translations marked as "Dead"?
When I need to "refactor" some common term, I find it in "Dead"
translations also, which, if not updated, appears as unwanted search
results.
Valdis
The XWiki development team is proud to announce the availability of XWiki
6.4.2.
This is a stabilization release that fixes important bugs discovered in the
6.4.1 version.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki642
Thanks
-The XWiki dev team
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi.
Problem: in XWiki, we have currently 2 main skins, Colibri (to be
deprecated) and Flamingo, that did not share the same doctype. Colibri
templates are using the XHTML 1.0 syntax, meanwhile Flamingo uses the HTML
5 syntax.
Currently, we have hard-coded in a lot of places the fact that we use XHTML
1.0 syntax, but I would like to replace this by a new setting,
skin-dependant, to select the rendering syntax we want. It would enable us
to generate valid code (with the HTML cleaner, among other things) for each
skin we support.
This setting will be located in the XWiki.XWikiSkins objects, and in the
skin.properties file for file system skins. Of course we also need to add a
new API to get the current rendering syntax.
The alternative is to create a global setting or constant to set the
rendering syntax for the whole XWiki instance.
Some discussions about this there: http://jira.xwiki.org/browse/XWIKI-11602
Here is my +1,
Thanks,
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hello.
This proposal is about the following issue:
http://jira.xwiki.org/browse/XWIKI-11803.
Currently, our mechanism to overwrite a skin file in the wiki has some
problems:
1 - we need to add a property in the XWiki.XWikiSkins class for every file
that we want to overwrite. It is not clean to change a system class just to
use a feature. Moreover, all the existing skins are polluted with any new
property added to the class, even if the skin does not need it.
2 - we cannot overwrite a file placed in a subdirectory (like
"less/style.less.vm") since we cannot have the "/" character in a property
name. This blocks http://jira.xwiki.org/browse/XWIKI-11394.
To avoid the problem 1, people usually attach their overwriting files to
the skin documents. But it causes some other problems: it is not the wiki
spirit to edit a file locally and then to upload it. It would be far better
to edit the code directly in a textarea.
To fix these 2 problems, I propose a new mechanism, that Eddy have
described previously [1]:
* we create a new XClass called XWiki.XWikiSkinFileOverride.
* this class would contain 2 properties:
** a path (eg: htmlheaders.vm, less/buttons.less...)
** a content (a textarea).
Then, on the skin document, we add one XObject per file that we want to
overwrite. The system is simple and flexible.
(On the future, we can even imagine that XWiki automatically merges the
content of the XObject with the existing file in the skin, but this idea is
not a part of this proposal.)
Depending on the time I will have, I may not be able to fully implement
this for 7.0. So I plan to make it work for the LESS files first, that we
cannot overwrite currently.
Here is my +1,
Thanks
[1]
http://jira.xwiki.org/browse/XWIKI-10568?focusedCommentId=81939&page=com.at…
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hello,
I created an application with Xwiki 6.4.0, I created my Class (with string, date and /'List of Users' properties), a Sheet and Template.
My fields are displayed correctly except if I export my page.
In PDF/ODT export file, I obtain "Unknown display mode." instead of the value for all 'date' and 'List of Users' field.
Did you notice that?
I found this issue http://jira.xwiki.org/browse/XWIKI-8694 (I didn't tested with 'List of groups' but I can if you want to)
Thxs
Pascal B