Please note: this page describes work planning for VIVO 1.5 – please see the extensive additional work in multi-language support for VIVO 1.6
up to all Development Components for VIVO 1.5
Component description
Study, design, and implement methods for moving VIVO from an English-centric application to a language-neutral application.
Scope of the component for v1.5
In scope:
The component breaks down neatly into three different levels of effort:
- Support non-English versions of VIVO
- All text that appears in templates, error messages, etc. must be configurable through templates or similar mechanism.
- Support multi-language versions of VIVO
- Each user sees templates and messages in their own preferred language.
- Initially as configured in the browser; changeable if logged in.
- Each user sees templates and messages in their own preferred language.
- Support multi-language content in VIVO
- Each individual might have multiple labels: one for each supported language. The user sees the label of his preferred language.
- This could apply to all literals in RDF data.
Out of scope:
- Multi-language support in the application logs.
Design work needed for the component
Each stage requires its own design elements:
Level 1 design:
- Some design – how should we store the strings of text in each language?
- How does this relate to extensions/modules?
- What is required to implement an additional language?
- Not really design, but a lot of inspection of the code base.
- Where are these hard-coded strings appearing?
- In the templates.
- In the controllers (in particular, error messages).
- In warnings and error messages at startup time.
- Where are these hard-coded strings appearing?
- Which of these strings could/should be stored in the application ontology as annotations, instead of being in the controllers or templates?
- Do we need to jump right to multi-language content just to handle them??
Level 2 design:
- How to determine the user’s preferred language.
- What if their preference is for a language that the installation doesn't support?
- How to make the selected language particular to each request or each session, instead of pertaining to the entire context.
Level 3 design:
This one is quite challenging.
- Although RDF specifies a way of adding a language tag to a literal, some Ontologies specify alternate ways.
- For example, create properties like “name-en” and “name-sp” as English and Spanish sub-properties of “name”.
- Does this require that we do property inferencing?
- How does this affect SPARQL queries that only return values, and not property names?
- There is not even a de facto standard. How far do we go to support those non-standard schemes? How flexible do we want to try to be?
- What do we do if we find English and French versions of a value, but the user’s preferred language is Italian?
- Show the English?
- Show nothing?
Can this component be addressed in stages?
| Task | Depends on | Time |
|---|---|---|---|
1a | Design the mechanism for "dictionary files", and implement it for Java and for Freemarker. |
| 6 days |
1b | Scour the code base for strings that should be language-dependent. Use the new mechanism instead. | 1a | 10 days |
2 | Create mechanism for choosing a language for each request, including default. | 1a, 1b | 4 days |
3a | Design for multi-language content
|
| 8 days |
3b | Implement multi-language content | 3a | Dependent on design |
Dependency on any other component
Essentially none, although the configuration design should take the extension framework into account.
A suggested incremental plan
For release 1.5:
- Nothing
For later releases:
- If Levels 1 and 2 are considered useful, move forward with them.
- Do some of the design work for Level 3, so we can form some opinion about the level of effort it would require.
