...

Attendees

 Indicating note-taker

1. William Welling 
2. Andrew Woods 
3. Brian Lowe
4. Benjamin Gross 
5. Nicolas Dickner 
6. Georgy Litvinov
7. Ralph O'Flinn
8. Huda Khan 
9. Alexander (Sacha) Jerabek 
10. Benjamin Kampe 
11. Michel Héon 
12. Huda Khan Don Elsborg 

Agenda

1. Releasing a 1.12 alpha
   1. Tickets to be resolved

      1. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1762

      2. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1802

      3. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1814

      4. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1914

      5. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1941

      6. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1950

      7. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1956

      8. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1959

   2. Timing
      1. 1.12 alpha-1: Feb 19th
         1. Two week RC-1 testing period
         2. For each subsequent RC-2 (if required), adding another two weeks to the schedule
   3. Process - are we prepared to turn the crank? VIVO Release Process
   4. Communication
2. New developments

   1. Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1963

   2. Possible issue with duplicated edits?
   3. TDB "direct" versus "mapped" mode.

   4. Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1962

3. Post-i18n priorities
   1. VIVO-in-a-box
   2. Ingest / Kafka
   3. Advanced Role Management
   4. Moving Scholars closer to core - next steps

...

Draft notes on Google Drive

• Pre-main agenda
• Congrats to Brian on new position!
•  Zoom link has not changed YET

1. Releasing a 1.12 alpha
   1. VIVO-1762 - i18n: Document how to add new languages -for developer- In Progress
   1. Brian: Do we think this is a critical issue to address for the release?
   2. Michel: Not a blocker
   3. Benjamin: Nice to have before actual release but does not see like a blocker for alpha
   2. VIVO-1802 - i18n : Wrong label / untranslated items in "Same as" form Closed
   3. VIVO-1814 - i18n : French version of VIVO Publication graphic mouseover message is truncated Closed
   4. VIVO-1914 - i18n: Document how to upgrade existing site to use new i18n functionality Open
      1. If there is an existing 1.10/1.11 VIVO, what would need to be updated?
      2. More general question around upgrade process with Docker
      1. Recast this to make sense for 1.12
      2. Add text to approach customizations
      1. Mention changes to ontology.  Linguistic “en-us” tag at end of each label.
      1. Wasn’t required in the old VIVO but will be required in 1.12
      2. Brian: Data displayed by language filtering RDF service.  If it doesn’t find matching label, gives a random one. 
      1. Intention: Any place where end-user sees triples coming from triple store, it should have a fallback.
      2. Would the value disappear if no language tag?
      3. Michel: If stays en-US, should be fine.  If adding a language when editing data, the French tag will be in data.  Not sure if “en-US” will be added to the English string as a result of this edit.  
      4. Brian: Need to review this further
      5. Michel: Perhaps set up a helper asking what default language they want and then add that language to the strings?
      6. Brian: Utility (like Jena Tools) that could be run outside the app to set the tag?
      7. Michel: Yes
      8. Benjamin: Having a separate tool which does not need to be carried forward with VIVO: makes sense
      9. Brian: Alternative proposal.  Don’t want to carry around, but perhaps simpler if we just added a property in runtime properties to set locale.  This could be read in and then startup listeners could kick off conversion. 
      10. Benjamin: Less documentation this way.
      11. Brian: yes
      12. Georgy: When users do it intentionally, the separate tool might be better.  Otherwise, they may not think about what is happening. 
      13. Brian: Cannot necessarily account for complex changes for mixtures of languages (some as unintended side effects of editing)
      1. If all the language was to be in Spanish or English, if offered option to pick the locale that you expected your data to be.  Code will switch everything to that language, whether there was already a language tag or not.  
      2. Could be done by documentation using example SPARQL Update queries by named graphs, etc.
      3. Benjamin: worry about queries like that against large databases and stalling the system 
      14. Michel: Can’t build a solution for all cases, but need to specify that some process required on the data and cannot just be ported as is to 1.12 with i18n support. 
      15. Brian: Would prefer having this run as part of the tool
      1. Should we instead go with the documentation approach or command line approach?
      2. Volunteering to make a simple tool that would run inside VIVO, and then can review the pull request to see if acceptable or whether a separate tool is required. Brain to pick this up.
   1. Brian: Might be a little more critical. 
   2. May link to 1763 which is ready to go.  
   3. Benjamin: What needs to be done differently beyond the regular upgrade process
   4. Brian: https://wiki.lyrasis.org/display/VIVODOC111x/Upgrading+VIVO
   5. Michel
   5. VIVO-1941 - i18n - Refactor i18n properties and templates Open 
   1. E.g. there are custom templates in the fr_CA language repos. Properties have been added to existing .ftl files. Vision: Reform core FTL files so concatenation is no longer done… create longer i18n strings. 
   2. Michel in past has asked us to look at better way to look at syntax. 
   3. Benjamin - I don’t think it’s realistic to go back and try to address this at this point since it will require creating new i18n properties in multiple languages that will need reviewed by native speakers.
   6. VIVO-1950 - Google visualization libraries not loading - sparklines broken Closed
   1. Benjamin: Seems to be working fine.  Changed the URL for the request and callback.  Not seeing it load multiple times so it seems to be working. 
   7. VIVO-1956 - i18n - Re-Ensure consistency of RDF files Open
   1. Brian to look at this
   8. VIVO-1959 - When no selectable languages are enabled, interface is broken if browser's accept-language does not match an installed language Open
      1. Michel: Loads every time ?
      2. Brian: Selectable languages uncommented, and had French/German and not English, only those two are loaded
      1. If browser locale does not match anything in the selectable language list, it will default to the first selectable language 
      2. If browser locale matches something in the selectable language, it will pick the browser locale language
   1. Main blocker bug Brian assigned to self
   2. If running VIVO without enabling languages (default installation), and browser accept language is set to something (e.g. RO-RO for Romanian), get errors. 
   3. Changes to runtime properties so a sensible default would be set.
   4. Raises questions for future
   5. When don’t have selectable languages enabled in runtime properties, and no forced locale explicitly set, it doesn’t find a default language, and HttpServlet request does not get wrapped in a method which uses the getLocale.  Gets browser language.  Then, the properties file is attempted for retrieval, but is not found, and errors occur.
   6. RDF Files loading: where it decides to load en-US in absence of other languages.  That checks selectable locales and if empty adds en-US
   7. Quick fix for release: use that method instead. Refactor into general locale handling class.  That should allow us to get around issue. 
   8. Brian: Is this ok as a fall-back?
   1. If you add concept/class/individual, the i18n mechanism doesn’t work in this view. 
   2. Also doesn’t work in navigation or editing
   3. In French: Adding new class.  Linguistic tag not put in label description. 
   4. Brian: Tested with new code in main?
      1. Site info/page titles for page management, etc. : updated so that when a different language is set, it inserted the new value in the correct language and also preserved the other values in other languages
      2. In general, editing on administrative side with a different language should be fixed at this point
      3. Ontology editor: some areas not translated.  Domain/range, etc. Most of those properties get displayed in English b/c currently not providing translations for those. 
   1. Michel: Can test this with new code in main
   2. Brian: Worked with this area.  Initially reported by Benjamin for labels.  
   3. Michel: UQAM next week will be in sprint.  Talked about this with Sacha. Sacha will make systematic test in administrative portion. Next two/three weeks: probably additional tickets. 
   4. Benjamin: Will probably need point releases or a new releases for resolving blockers that are brought up now.  Fine to be part of testing for 1.12 but should not be blockers for 1.12.
   5. Nicolas (from chat): 
   1. https://jira.lyrasis.org/browse/VIVO-1947
   1. 1.12 alpha-1: Feb 19th
   1. Two week RC-1 testing period
   2. For each subsequent RC-2 (if required), adding another two weeks to the schedule
1. Plan: Alpha release by Friday. Two weeks of internal testing after which we’d announce it to community.  Then RC-1 after two weeks.
2. Will probably need some concerted effort for the remaining few open positions
3. Tickets to be resolved
4. Michel found bug in the administrative part.
5. Timing
6. Process - are we prepared to turn the crank?VIVO Release Process
7. Communication
2. Alpha release on track for end of week!
3. Georgy - working on advanced property removal logic. 
1. Original effort was too slow, but switched to DESCRIBE statements and seems to be better
2. Will clean up code and add redirect code for after deletion. 
3. Possible issue: what if user has ability to delete first object, but doesn’t have permission to delete objects that the deletion logic traverses?

Actions