February 2015 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Location of translation properties
by vincent＠massol.net 05 Mar '15

05 Mar '15

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

5 8

[xwiki-devs] [Contrib] Request repository for "RFC" Application
by Fabio Mancinelli 27 Feb '15

27 Feb '15

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.

2 2

[xwiki-devs] [XWiki Day] BFD#81
by Eduard Moraru 27 Feb '15

27 Feb '15

Hi devs, Today is BFD#81: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 68 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#81 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13098 Thanks and enjoy your bug fixing day! -Eduard

1 1

[xwiki-devs] Can I delete translations marked as "Dead"?
by Valdis Vītoliņš 26 Feb '15

26 Feb '15

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

2 3

[xwiki-devs] [ANN] XWiki 6.2.7 released
by Guillaume "Louis-Marie" Delhumeau 25 Feb '15

25 Feb '15

The XWiki development team is proud to announce the availability of XWiki 6.2.7. This is a stabilization release that fixes important bugs discovered in the 6.2.6 version. You can download it here: http://forge.ow2.org/project/showfiles.php?group_id=170 Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki627 Thanks -The XWiki dev team

1 0

[xwiki-devs] [ANN] XWiki 6.4.2 released
by Guillaume "Louis-Marie" Delhumeau 25 Feb '15

25 Feb '15

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

1 0

[xwiki-devs] [Proposal] Adding a setting in the skins to select the rendering syntax
by Guillaume "Louis-Marie" Delhumeau 25 Feb '15

25 Feb '15

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

4 7

[xwiki-devs] [Proposal] A new mechanism to overwrite a skin file
by Guillaume "Louis-Marie" Delhumeau 25 Feb '15

25 Feb '15

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

1 0

[xwiki-devs] Wrong displayer for 'date' and 'List of Users' format
by Pascal BASTIEN 25 Feb '15

25 Feb '15

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

2 2

[xwiki-devs] [ANN] XWiki 6.2.6 released
by vincent＠massol.net 25 Feb '15

25 Feb '15

The XWiki development team is proud to announce the availability of XWiki 6.2.6. This is a bugfix release. 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/ReleaseNotesXWiki626 Thanks -The XWiki dev team

1 1