Internationalization update (Sacha primarily, plus Michel)
Proceeding with testing
Looking for things that need to be translated
Creating new elements in forms; looking for problematic behavior
Capability map
Selenium tests being developed from scratch (four tests exist)
Not based on previous Selenium tests developed by Jim Blake
In next two weeks will be working on solutions for more complex syntactic differences between languages where simple string substitution via properties files is problematic.
UQAM team also has other responsibilities, so effort will be somewhat limited.
Don interested in having capability map be able to traverse links between persons and publications to include concepts linked via publications and not just directly to people.
Benjamin: fairly comprehensive suite of Selenium tests already exists, but I had trouble getting them to run. Should be documented in the release procedure on the wiki.
Ralph: should be available in vivo-community. May not have been updated since 1.9.3.
Benjamin: believe Jim did a lot of work to bring them up to date after 1.9.3.
Don: agree with vision, but would be good to articulate the reasoning. Could be variations on the theme, e.g. still specify Tomcat directory if desired but copy the whole war file there instead of exploding it first.
Benjamin: one important use case is being able to download the war file and drop it into Tomcat without building at all.
Struggle to see how this is going to help me (as a developer)
Have custom Java files I will have to deploy anyway.
Ralph: good for adhering to best practices and for testing/evaluation
Benjamin: Right now, can’t customize branding without modifying the theme directory, which is inside the war. So without other changes, it really will only be useful for evaluation and not production.
Don: could open up interesting opportunities [related to clustering?]
Ralph: Docker may be the easiest way to deal with Solr installation and setup
Do we support latest and greatest Solr or maintain support for multiple versions of Solr as well as ElasticSearch?
Benjamin: not sure there’s enough of a community to demand or support ElasticSearch at this point
I18n configuration via runtime.properties without having to edit pom.xmls
Merged to i18n sprint branch; Benjamin and Brian want a simplification of the mechanism (no requirement for master list of all supported languages) to occur before the feature gets merged to master. Andrew created an issue for this.
Ralph: has voiced preference in other projects for things to be configurable via GUIs rather than properties files
Don: some of us prefer the opposite (file-based configuration)
Discussion of fact that all i18n files are installed at build time and RDF is selectively loaded according to languages enabled in runtime.properties.
Advantage of more GUI-based configuration would be instant changes without need for restart.
Benjamin: Maintaining compatibility with third-tier builds may be only a matter of documentation, or small adjustments to pom.xml files.
JSM messaging approaches
Don: multiple approaches exist now that rely on eternal processes to build index. My concern with VIVO-scholars is that there is yet another Java process running queries and building index, etc. Much more complex for system administrators than the other configuration issues we talked about earlier.
Having a common solution for mapping triple changes to document changes and being able to use it in multiple applications would simplify this landscape.
Ralph: also German use case for audit logging. Seems like first thing this should cover.
Don interested in creating an MVP that could update FacetView.
Brian: these discussions seem to be conflating two very diferent use cases
1. Low-level listening to RDF changes : can be done by implmeneting either VIVO’s change listener interface or Jena’s ModelChangedListener (which can be adapted to listen to an RDFService)
2. Listening to index changes at a higher level that takes advantage of VIVO’s logic for mapping triple changes to field updates in different index documents. Here it might make sense to start by making a third implementation of the search index interface (after Solr and ElasticSearch) that instead of using the API for a particular index product instead emits generic document update messages that can be consumed by different systems.
Indicating note-taker