...
- Questions/Issues/Pull requests/Announcements
- VIVO-languages and Vitro-languages
- ARCHIVED
- The i18n redesign sprint number two is in progress
- VIVO leadership group meeting
- VIVO-languages and Vitro-languages
- The i18n redesign sprint
- the issue - https://github.com/vivo-project/VIVO/issues/3800
- the issue - https://github.com/vivo-project/VIVO/issues/3803
- the issue - https://github.com/vivo-project/VIVO/issues/3801
- Documentation needs update - Developing a New Interface Language for VIVO
- VIVO installation and deployment
- installation removing and adding some files in VIVO_HOME
- build GitHub action
- checking out Vitro from the main branch
- VIVO demo meeting
- Sprint results - 2023-01-26 - i18n redesigning demo meeting
- or VIVO 1.14.0
- Publishing VIVO 1.14.0 release
- we will start preparation after the sprint
- architecture improvements
- archiving VIVO-languages and Vitro-languages
- i18n improvements
- performance improvements
- faux data properties
- architecture improvements
- we will start preparation after the sprint
Notes
Dragan: VIVO-languages and Vitro-languages archived
This week is the last sprint this year with topic of i18n-redesign.
In the previous week there was a Leadership Group meeting.
We might release VIVO 2.0, it might happen once we have json API.
Another topic was about OpenAIRE guidelines
In Europe there is an OpenAIRE platform, to collect data from different systems, like institutional repositories, libraries and CRIS systems. As a response to that DSPACE implemented a protocol to provide that information.
They would like to collect information from all VIVO instances. OpenAIRE.
Guideline is for OAI-PMH protocol. We should start discussions on how to implement that.
Georgy: There are some libraries and frameworks to provide information in OAI-PMH protocol. We can choose from those libraries.
Dragan: one such option is OAICat library, in that case we would only need to define mappings.
Current PRs review:
We have two reviews on set of PRs: Vitro 351 and VIVO 3801, issue 3800
This PR provides a way to customize labels for ontology classes and properties.
In this approach if an institution used _x_ then these files would be kept not removed at the time of installation. All directories will be recreated, but this directory won’t be removed.
We should think about broader problems, not only about home directory…
Dragan: In this branch we transformed property files into ttl files.
Georgy also transforms those files on the fly.
They are loaded in the graph and merged on startup.
William: if you mean about major release, then there is no need to support.
Georgy: I think William’s solution is a good step forward to resolve deployment and application packaging.
William: My concern is about overall code quality.
Dragan: Can we reconsider to reuse your contribution from the past?
William: I think UQAM had concerns about that.
William: There is a PR history, I am sure commits are some there there. It wasn’t really complicated to implement.
With Github action we can rely on versions, not rely on branches. That wouldn’t require a git clone. But the process isn’t tuned yet. Getting commits in correct version that would be technically incorrect. There is a maven plugin that if you change a commit it modifies pom to avoid misalignments of commits and versions.
Dragan: If we use the development branch, we haven’t merged Vitro yet.
It might be passing, but in some moment it didn’t pass as VIVO branch had assumptions that we removed Vitro-languages.
William: We can create multiple workflows with Github actions.
Dragan: How can I inform Github action?
William: There are conditional actions.
Dragan: It seems to me that it is complicated. How align one branch with another branch, but each PR will have hardcoded branch names in actions.
William: There are always a few ways to accomplish the same thing.
If we lean on Github actions, maybe we should rely less on Github.
Dragan: Michel, why have we decided to postpone William’s contribution?
William: There was some push back from institutions. I like to see that languages aren’t necessary. It is not a worry anymore. It would be nice to utilize multiple languages.
Dragan: Yeah, we don’t have 4 linked PR now, maximum 2 at the moment.
Maybe I can show other PRs.
Before language tag in file name was necessary, now it is included in the upper directory name.
This PRs removing that redundant suffixes: VIVO 3804, Vitro 354, issue 3803
I also noticed that for some files this suffix is already removed.
I don’t see any need to have language encoded in file names.
I suggest merging that.
Smallest one set of PRs with corrections in case if some labels aren’t found:
Issue 3800 PR Vitro 351 and VIVO 3802
After that we need to create PRs to merge that into main branches.
Faux property improvements PR:
There are a few comments, but nothing dramatical. It would be nice if we have one more committer to review that.
Brian: I can look at this on Thursday.
...