...
- Treat languages as part of the release
- Update documentation to reflect language support in the current release documentation
- Translators may discover missing tags, hard-coded language that require VIVO developers to address – Jiras opened, worked, and communicated back to the translators.
- English must be treated like any other language – with a language repository. Translators can see the changes from one version to another to see what has been changed. This is not in lieue of real-time communication as issues as being discovered.
- The commit review needs to consider multi-language support. Commits should not introduce language dependency.
- Could be a two step process, adding internationalization to code that may have been committed without it.
- In the folder for a language, have a README with contact info for responsible parties.
- Eventually have a symmetric build process with a declared language.
- Have the language as a dependency for the maven build process.
- Maven project structure for language folders
- Documentation indicates which translations are known to work
- Language release can be as a collection and released whenever any language has new material to publish.
- Need to be tagged in Maven Central as releases of the language files.
- Vitro messages, VIVO messages, Theme messages, Local messages. But that's not how it works now. Can this be automated?
Action Items
- Prioritized issues in Jira. Mike Conlon will add issues/comments from this call to the Jiras.
- Creating language files as a Maven project able to be