Multilingual schema labels and presentation sections #86
Labels
No labels
area/api_cli
area/apps
area/content_model
area/framework
area/infrastructure
area/integrity
area/io
area/presentation
area/preservation
area/rdf
area/security
area/submission
area/ui
s
blocked
s
done
s
progress
s
testing
s
wontfix
p
critical
p
high
p
low
p
normal
t
bug
t
documentation
t
enhancement
t
feature
t
test
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
ktx/pocket_archive#86
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In order to effectively create multilingual archives and presentations, the modeling framework must support multilingual labels and descriptions for types and properties.
This may be best done by supporting an explicit configuration section that indicates all supported languages of an instance. Also, all schema definitions in both core and user-defined schemata should account for multiple values for the label and description of types and properties.
When multiple languages are set, the presentation generator should also generate multiple sets of HTML pages in different languages. These should be separated by a top-level folder, e.g.:
/en_US/index.html,ar_PS/index.html.Multilingual metadata labels and descriptions are different from multilingual values (already supported), but loosely related to one another. For example, if an archive is set up for English and Arabic, and a field has values in both languages, the presentation should display all labels, putting the one(s) matching the current language first. If a field is missing values in the requested language (which may be normal, e.g. for an inscription), the first available language is displayed.
Submission should not be affected significantly, as the property labels are not used in the LL, and multilingual values are already supported. One exception to this is support for multilingual file references used in presentation, such as
pres_content, which are ofresourcetype and as such don't currently support the lang tag. The presentation generator should use the same language election logic to parse the most appropriate file for the selected language.This ticket is split into different sub-tasks, that should be deployed as one new feature: