xwiki-devs September 2013

xwiki-devs@xwiki.org

35 participants
75 discussions

[xwiki-devs] XWiki German translation status - help needed

by Sorin Burjan

Hello everybody, Recently I have taken a look at the status of the German language translations, and I have found several sections which should be improved. The main categories of interest, which are missing important translations are: Extension Manager, SOLR, Workspaces. Below there is a list with the missing translations in German. * XWiki CORE Resources aprox. 512 missing, the most important being the Extension Manager - http://l10n.xwiki.org/xwiki/bin/view/Platform/XWikiCoreResources?action=vie… * Main SOLR Translations approx 4 missing - http://l10n.xwiki.org/xwiki/bin/view/Platform/MainSolrTranslations?action=v… * Workspace Application (Workspace Application - Workspace Translations) approx 32 missing- http://l10n.xwiki.org/xwiki/bin/view/Platform/WorkspaceApplication-Template… * Workspace Application aprox 121 - http://l10n.xwiki.org/xwiki/bin/view/Platform/WorkspaceApplication?action=v… * Annotations aprox. 5 - http://l10n.xwiki.org/xwiki/bin/view/Platform/AnnotationCodeTranslations?ac… Since unfortunately I don't know German, I am bringing this to the community so maybe someone with German skills is willing to help. All you need to contribute is to know German and an account on l10n.xwiki.org. Regards, Sorin B.

11 years, 3 months

[xwiki-devs] [Proposal] Finding how many active instances of XWiki there are out there

by Vincent Massol

Hi devs, I think it would be great to have some indication of how many active instances of XWiki are out there in the wild. The idea is not so much to know the figure but to see how this figures evolves and thus to see if we're doing things right. It will also give us information about how quickly or slowly our user base upgrades from version to version. Here's my proposal: * When installing XWiki on a clean DB (ie first time install) generate a unique id and store it in the DB (similar to the version we're storing in the DB but using some UUID). Thus when an install is upgraded the same id is preserved. * When the Extension Manager is used and thus connects to extensions.xwiki.org (default extension repository), this unique ID is sent too. * In addition the version of XE is sent too * On extensions.xwiki.org side, we only log the unique ID/XE version **without** logging the IP or any other information thus ensuring that the ID remains completely anonymous * We display a counter on xwiki.org about the # of active instances of XE with a graph about XE versions used WDYT? Thanks -Vincent

11 years, 3 months

[xwiki-devs] [Proposal] Workspace Integration

by Guillaume "Louis-Marie" Delhumeau

Hi developers. I'm sorry to post such a long post, but the workspace integration in XE is a big deal, with a lot of things to discuss. That is why I describe the current state, what we want to have in the long term and what we can do for 5.2. 1 - Current state ------------------ 1.1 - What "Workspaces" is --------------------------- Currently, "Workspaces" is a set of features developped on top of XWiki Entreprise. It was developped for a research project and released as an extension. We now have a special release for it, but "Workspaces" is still not integrated deeply into the core. From the core perspective, it is still like an "add-on". That is why we have 2 modules: xwiki-platform-wiki-manager and xwiki-platform-workspace. 1.2 - What a subwiki is ------------------------ A subwiki is just an other wiki, that can use either global or local users (as you decide). You can invite people to your subwiki through the "Invitation" application, which is bundled by default. But the "Invitation" application is now hidden, so we need to add a new entry point for it. 1.3 - What a workspace is --------------------------- A workspace is a "space" where people can collaborate for a project. The actual implementation says that: - a workspace is a subwiki - a workspace does not have local users - there is an option that make possible for people to "join" the workspace (if he is not already in), with the optionnal validation of an admin. These options are called "membership type". - a workspace can be created by everyone, by default. + there is an UI in the workspace administration to invite user to the workspace. 1.4 - WorkspaceManager has to be installed ------------------------------------------- When you download a new XEM and create a fresh instance of "Workspaces", you will have a message on the main page that invite you to "Install WorkspaceManager". This installation of WorkspaceManager creates a new subwiki called "workspacetemplate". In this template, 2 XARS are imported: - workspace-template.xar, which is a nothing but a renamed xwiki-entreprise-ui-all.xar, most of the time. - workspace-template-features.xar, that add some UI for the workspace features (changing the top menu, etc). The installation also changes some settings in the template subwiki and then, 4 pages are removed: XWiki.AdminRegistrationSheet, XWiki.RegistrationConfig, XWiki.RegistrationHelp, XWiki.AdminUsersSheet. This is because a workspace is not supposed to have local users. This new workspace is a template, hidden to the users, and it will be used when you create a new workspace, unless the user manually decide to use an other template. If "WorkspaceManager" is not installed, you won't have the ability to create workspaces. This installation process is dirty in my point of view. Why should the user install something else after having installed XEM? 1.5 - What "WikiManager" is. ---------------------------- The module xwiki-platform-wiki-manager is the module that provides an API and a UI to manage multi-wikis. Is is a dependency for xwiki-platform-workspace. But this module is quite old. It was first developed as a "plugin" and not as a component, even if it can be used through a bridge. 2 - Long term objectives --------------------------- 2.1 - What we have discussed --------------------------- After some discussion in the mailing list, we have decided the following: - the ability of create subwikis will be integrated by default on XE. - we will stop making a distinction between workspaces and subwikis. There will be only the notion of "subwiki", with several options to cover all the use cases. - we will have a single UI to create a new subwiki, integrated in the top menu, like the space and the page creation. Now, this is what I propose to do after a discussion with Vincent: 2.2 - Create a new 'wiki' module --------------------------------- Currently we have xwiki-platform-wiki-manager and xwiki-platform-workspace. But it no longer make sense to have 2 distinct modules since we will have only one concept. But instead of integrating the workspace features into the wiki-manager module, we will create a new one. Why? Because xwiki-platform-wiki-manager is not a compoment and this new module will be a clean component with a clean API and a clean script service. Vincent already has created a new 'wiki' module for his URL module so it make sense to go in this direction. This new module will not be too long to implement since we can keep a lot of code from the 2 existing modules, but it will be written in a manner that the "farm" and the "workspace" use-cases are handled. 2.3 - The creation of a subwiki will not be possible until a subwiki template is created ----------------------------------------------------------------------------- The user may not want to use subwikis, so we should not force him to do it. Moreover, instead of having a "WorkspaceManager Install" process, we can add a new entry in the Administration that create the "workspacetemplate" and actually enable the "subwikis" features. It will not be seen a post-install installation. When creating the "workspacetemplate" (which will be called "subwikitemplate"), I will not remove XWiki.AdminRegistrationSheet, XWiki.RegistrationConfig, XWiki.RegistrationHelp and XWiki.AdminUsersSheet. I will make some code to "disable" them if the "local users" option is disabled. For example, the RegisterSheet will redirect to the main wiki Registration. 2.4 - Merge WorkspaceManager UI and WikiManager UI -------------------------------------------------- There will be only one UI in the future that shows all the subwikis and offering features of the 2 current UIs. 2.5 - Improve Invitation application ------------------------------------- Right now, we both have the "workspaces users" section in the administration and the Invitation application. It seems that Invitation application is a better application than the "workspace users" section because it can do more things. But the UI should be improved. Moreover, if a user wants to "join" a subwiki, the "join" link should be located near the "register" one. It would look more "integrated" than the current thing. At the end, it should replace the invitation feature of the current "workspaces users" section of the administration. 3. What I have already done --------------------------- I have made a new wizard, based on the Caty proposal and the current workspace creation UI. Screenshots: - Step1: http://tof.canardpc.com/view/582b629c-80c7-4e82-acda-ea99a20741a8.jpg - Step2: http://tof.canardpc.com/view/32737e88-9f78-4249-8063-caa42f92665c.jpg I have also started to change the XARs organization of enterprise, see it there: http://markmail.org/message/e4agvo2gevst6gox 4 - What I propose to do for 5.2 --------------------------------- Regarding the objectives, it seems obvious that we won't have the time to do all the work for 5.2. So we have to decide what we do. I propose to make it iteratively, but we have to take into account that the "Workspace Integration" has been voted for 5.2. So, we should: - bundle the "Workspaces" application by default, not bundle the "Wiki Manager UI". So the user can only create workspaces, which is the main use case. If the user want to create a subwiki like in the "farm" use-case, he will have to manually install WikiManager UI from the Extension Manager, which is not very hard! - start dropping the "workspace" terminology. The Workspaces application will be integrated, but all the texts will mention "subwikis" instead of "workspaces". So the user will not be used to the "workspace" term since we want to drop it in the near future. I don't know yet if it is better to create new translation keys or to reuse current ones (like workspacemanager.doc.createwiki.wikiname). - we keep the current main page, we do not put the Workspaces main page by default. - we integrate the new subwiki creation wizard that I have made, but in the end it does not do more than the current workspace creation UI. We do not implement the "users isolation" option. - Add a link to WorkspaceManager.Install in the administration instead of having it in the main page. - I create the menu Home/Wiki/Space/Page based on the option D of the Caty's proposal. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImprovem… The menu will be: * Add * Subwiki (if WorkspaceManager has been installed) * Space * Page * Home * Administer wiki (if you have the right) * Subwiki directories --- * Watch home (if you are in the main wiki) * Document index (if you are in the main wiki) * Subwiki (if you are not in the main wiki): * Watch subwiki * Administer subwiki * Document index * Delete subwiki * Space: * No change there * Page: * No change there Then, for the next releases (5.3?), we start to make the work that I have described in the long term objectives section. Conclusion ---------- WDYT? ;)

11 years, 3 months

[xwiki-devs] Support for custom facets in Solr search

by Martin Kresse

Hello there, I'd like to try to limit/customize the shown facets in the refinement panel for the Solr search. This would allow for a custom search page with different facet fields than the standard search (e.g. the facet "page" or "date" might not be useful in every case) or the addition of custom facet fields, for example "tags". Instead of modifying the global defaults in solrconfig.xml, I'd want to name the desired facet fields in the concrete solr query. Like documented for example in http://wiki.apache.org/solr/SimpleFacetParameters#Examples, if I want both fields "cat" and "inStock", I need to add both fieldnames to the query for the parameter "facet.field". On the Solr side, the set(String, String[]) method (http://lucene.apache.org/solr/4_2_1/solr-solrj/org/apache/solr/common/param…) could be used for this. However, the current SolrQueryExecutor implementation does not support this "multiple arguments" case, so for example a $query.bindValue('facet.field', ["cat", "inStock"])) doesn't work. To solve this problem, I suggest that SolrQueryExecutor.execute() checks each value of the named parameters for a list and optionally calls set(String, String[]) instead of set(String, String). I'd gladly supply a patch for this issue. Is there any interest in this? Sincerely, Martin Kresse -- Martin Kresse Anwendungsentwicklung EsPresto AG Breite Str. 30-31 10178 Berlin/Germany Tel: +49.(0)30.90 226.750 Fax: +49.(0)30.90 226.760 m.kresse(a)espresto.com HRB 77554 B - Berlin-Charlottenburg Vorstand: Maya Biersack, Peter Biersack Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber Zertifiziert nach ISO 9001:2008

11 years, 3 months

[xwiki-devs] [Reminder] BFD#32

by Vincent Massol

Hi everyone, We missed the BFD today. Sorry about that, I forgot to send the reminder… I thus propose to hold it tomorrow. ThomasM worked on it today so he's allowed to not participate tomorrow ;) Current status: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 We're 36 bugs behind ATM. Let's catch up some more. Here's the BFD#32 dashboard to follow the progress during the 2 days: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11691 Thanks -Vincent

11 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2013