Hello,
I'm making a new Holiday Request Application, and I'm about to finish
the first version. So I would like to have a github repo on xwiki-contrib
for it. I would also need a maven groupId and a page for the project on
extension.xwiki.org so I could describe it a bit further. You can already
see the code of the application on my own github repo :
https://github.com/tdelafosse/holiday-request.
Thanks,
Thomas
Hi devs,
This issue has already been previously [1] discussed during the GSoC
project, but I am not particularly happy with the chosen approach.
When handling multiple languages, there are generally[2][3] 3 different
approaches:
1) Indexing the content in a single field (like title, doccontent, etc.)
- This has the advantage that queries are clear and fast
- The disadvantage is that you can not run very well tuned analyzers on the
fields, having to resort to (at best) basic tokenization and lowercasing.
2) Indexing the content in multiple fields, one field for each language
(like title_en, title_fr, doccontent_en, doccontent_fr, etc.)
- This has the advantage that you can easily specify (as dynamic fields)
that *_en fields are of type text_en (and analyzed by an english-centered
chain of analyzers); *_fr of type text_fr (focused on french, etc.), thus
making the results much better.
- The disadvantage is that querying such a schema is a pain. If you want
all the results in all languages, you end up with a big and expensive
query. If you want just some language, you have to read the right fields
(ex title_en) instead of just getting a clear field name (title).
-- Also, the schema.xml definition is a static one in this concern,
requiring you to know beforehand which languages you want to support (for
example when defining the default fields to search for). Adding a new
language requires you to start editing the xml files by hand.
3) Indexing the content in different Solr cores (indexes), one for each
language. Each core requires it's on directory and configuration files.
- The advantage is that queries are clean to write (like option 1) and that
you have a nice separation
- The disadvantage is that it's difficult to get it right (administrative
issues) and then you also have the (considerable) problem of having to fix
the relevancy score of a query result that has entries from different
cores; each core has it's own relevancy computed and does not consider the
others.
- To make it even worst, it seems that you can not [5] also push to a
remote Solr instance the configuration files when creating a new core
programatically. However, if we are running an embedded Solr instance, we
could provide a way to generate the config files and write them to the data
directory.
Currently I have implemented option 1) in our existing Solr integration,
which is also more or less compatible with our existing Lucene queries, but
I would like to find a better solution that actually analyses the content.
During GSoC, option 2) was preferred but the implementation did not
consider practical reasons like the ones described above (query complexity,
user configuration, etc.)
On a related note, I have also watched an interesting presentation [3]
about how Drupal handles its Solr integration and, particularly, a plugin
[4] that handles the multilingual aspect.
The idea seen there is that you have this UI that helps you generate
configuration files, depending you your needs. For instance, you (admin)
check that you need search for language English, French and German and the
ui/extension gives you a zip with the configuration you need to use in your
(remote or embedded) solr instance. The configuration for each language
comes preset with the analyzers you should use for it and the additional
resources (stopwords.txt, synonims.txt, etc.).
This approach helps with avoiding the need for admins to be forced to edit
xml files and could also still be useful for other cases, not only option
2).
All these problems basically come from the fact that there is no way to
specify in the schema.xml that, based on the value of a field (like the
field "lang" that stores the document language), you want to run this or
that group of analyzers.
Perhaps a solution would be a custom kind of "AggregatorAnalyzer" that
would call other analyzers at runtime, based on the value of the lang
field. However, this solution could only be applied at index time, when you
have the lang information (in the solrDocument to be indexed), but when you
perform the query, you can not analyze the query text since you do not know
the language of the field you're querying (it was determined at runtime -
at index time) and thus do not know what operations to apply to the query
(to reduce it to the same form as the indexed values).
I have also read another interesting analysis [6] on this problem that
elaborates on the complexities and limitations of each options. (Ignore the
Rosette stuff mentioned there)
I have been thinking about this for some time now, but the solution is
probably somewhere in between, finding an option that is acceptable while
not restrictive. I will probably also send a mail on the Solr list to get
some more input from there, but I get the feeling that whatever solution we
choose, it will most likely require the users to at least copy (or even
edit) some files into some directories (configurations and/or jars), since
it does not seem to be easy/possible to do everything on-the-fly,
programatically.
Any input on this would be highly appreciated, specially if others have
more experience with Solr setups.
Thanks,
Eduard
----------
[1] http://markmail.org/message/kaxaka7lsbgo57ms
[2]
http://lucidworks.lucidimagination.com/display/lweug/Multilingual+Indexing+…
[3]
http://drupalcity.de/session/language-specific-and-multilingual-full-text-s…
[4] http://drupal.org/project/apachesolr_multilingual
[5]
http://stackoverflow.com/questions/4064880/create-new-core-directories-in-s…
[6]
http://info.basistech.com/blog/bid/171842/Indexing-Strategies-for-Multiling…
Hi devs,
For the Mobile App Investigation, Ludovic has been playing with a XWiki
Mobile App prototype done with jQuery Mobile (http://jquerymobile.com/).
This is a proposal for a mobile application that matches the jQuery Mobile
framework capabilities and that provides minimal XWiki functionality (like
listing wikis, spaces, pages, accessing content, viewing recent activity,
etc.)
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileApp
Thanks,
Caty
Hello XWiki experts,
has anyone started an OAI-PMH endpoint implementation?
It seems to me that I could do this in Groovy and Velocity... but maybe I should rather use an existing library.
If anyone has done a part of this, I'd be interest.
thanks in advance
Paul
Hi devs,
4.4 and 4.5 are the last 2 stabilization releases for the 4.x cycle. As such they are meant to be short releases (1 month per release) and the idea is to have:
- 4.4: December
- 4.5: January
This will allow us to start working on 5.0 at the beginning of February.
Thus for 4.4 (and 4.5) I propose to work on the following stabilizations (we shouldn't work on new features):
* AWM stabilization. Assignee: Marius
** Remove the i18n hack and use the new localization module to create a translation bundle for the application
** Add new field types (for page, image and attachment at least, with pickers)
** Improve the title and content fields (e.g. prevent dragging more than one title or content field)
* Extension Manager. Specifically we still need to able to install/upgrade a wiki farm in a few minutes. Assignee: Thomas/Marius
** XWIKI-8252: Migration from an older version will cause many merge conflicts with the Distribution Manager
** XWIKI-8443: When uninstalling a XAR extension a question should be asked for various conflict use cases
** Find a way to allow having each wiki admin doing upgrade instead of upgrading the whole farm by a farm admin which don't always know how to fix conflict like in myxwiki.org for example
** XWIKI-8173 (EM should not allow installing package exposing an installed feature)
* Translation module stabilizations/improvements. Assignee: Thomas
** XWIKI-8263 (Allow providing translations in a jar extension).
* SOLR improvements: we need to continue working on it and we can decide in the course of 4.4/4.5 if it's good enough to be made the default search or if we need to wait for 5.x to make it the default. Assignee: Edy
* Usability: small usability improvements. Assignee: Caty/JV. Caty/JV, could you please list what you'd like to work on?
* Workspace bug fixes (there are some raised by Anca for example). Assignee: Edy
* And a lot of bug fixes. Manuel reported a lot of browsers issue for IE that we need to fix
Anything else committers/contributors would like to work on for 4.4?
Dates
=====
4.4M1: 17 Dec
4.4RC1: 31 Dec
4.4Final: 7 January
Note that I'd have normally put RC1 on 24th but since that's the Christmas holidays, I've given RC1 2 weeks instead.
Can everyone review what I've put tentatively and tell me if it's ok? Also could you create the associated JIRA issues and reply to this email with them so that I can prepare the roadmap page on xwiki.org?
Thanks a lot
-Vincent
Hi devs,
Here are some notes I took while releasing XWiki 4.3 on how to improve the release process:
* We need to automate the generation of the CLIRR report. This is what takes the longest when releasing (not overall time but manual time required). IMO this can be done relatively easily by creating a patch for the CLIRR maven plugin itself to:
** Add support for wildcards in the new <difference> syntax
** Ensure that their report generation takes into account the <justification> element
** Possibly add a text report generation that we'll be able to copy paste in our RN
* Remove PURL generation for Tweets
** Tweets are ephemeral so no need to have permanent URLs
** Tweet clients already do URL shortening
(It's complex to use the PURL UI too)
* Don't create RN summary for OW2, email and even blog post. This will win some more time. Instead just link to the RN page which contains a summary and all details. For example for the email it could be:
"
The XWiki development team is proud to announce the availability of XWiki Enterprise <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/ReleaseNotesXWiki<short version>
Thanks
-The XWiki dev team
"
* Put maven.xwiki.org:~/xwiki-release-scripts under Git and do a git reset before the ow2 step to be sure to have clean scripts
WDYT?
Thanks
-Vincent
Hi devs,
I've written some conventions for translation messages at
http://dev.xwiki.org/xwiki/bin/view/Community/L10N+Conventions
Please provide feedback, since we terribly lack some proper rules here,
and there aren't two applications that use the same conventions. Now
that we have support for modular translation documents, it's a good time
to clean up translations and move things out of ApplicationProperties
into each application.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
The XWiki development team is proud to announce the availability of XWiki Enterprise 4.3.
This release brings several improvements in Workspaces, Extension Manager, Distribution Wizard, the REST API, new field pickers (Date, User and Groups), improved translation registration and new experimental Solr search.
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/ReleaseNotesXWiki43
Thanks
-The XWiki dev team
Hello,
Annoying problem :
- One wiki on production with 1 space with an eventlistener working on it,
sending email as soon as a page is created in the space.
- In dev, the same wiki : we add a new space with an other eventlistener,
sending email as soon as a page is created in the space (in summary because
the mail, the conditions of sending it are differents, etc...)
Everything is OK !
So we've decided to get it on production. On pre-production the second
listener doesn't send emails. In logs we have this error :
com.xpn.xwiki.XWikiException: Error number 2 in 0: The wiki xxx does not
exist
xxx is the name of our wiki and declared as an alias of the wiki. We are in
version 2.6.2.
I don't see what we are missing and so we cannot get it on productio.
Thanks for your help.
Patrice
--
View this message in context: http://xwiki.475771.n2.nabble.com/com-xpn-xwiki-XWikiException-Error-number…
Sent from the XWiki- Dev mailing list archive at Nabble.com.