Multilingual support in DCAT profiles#318
Merged
Merged
Conversation
`_add_triple_from_dict()` will check if the value is a dict and assume
it's a fluent field (i.e `{"lang1": "value_lang1", "lang2":
`value_lang2"}. `URIRefOrLiteral` also supports a lang parameter
Created multilingual versions of _object_value() and
_object_value_list() that store the different translations in the format
expected by the fluent fields, e.g.:
{
"en": "Dataset title",
"es": "Título del conjunto de datos"
}
and for tags:
{
"en": ["Oaks", "Pines"],
"es": ["Robles", "Pinos"],
}
Core fields (those ending in `_translated` are handled separately)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This builds on excellent code started by @stefina and @JVickery-TBS in #124 and #240 respectively, but adapting it to the current profiles and generalizing it for maximum compatibility.
Multilingual support is provided via integration with ckanext-fluent, the supported way of implementing translations for CKAN fields.
At the serialization level, a new triple will be added for each of the defined languages (if the translation is present):
When parsing, the parsers will import properties from DCAT serializations in the expected format if the field is defined as fluent in
the schema:
{ "name": "test-dataset", "provenance": { "en": "Statement about provenance", "ca": "Una declaració sobre la procedència", "es": "Una declaración sobre la procedencia" } }As implemented in #124, if one of the languages is missing in the DCAT serialization, an empty string will be returned for that language. Also if the DCAT serialization does not define the language used, the default CKAN language will be used (
ckan.locale_default).@JVickery-TBS this covers most of your changes in #240 except for the handling of translated fields in publishers / organizations. As it's difficult to come up with a logic that works in the many different scenarios, this is best suited in a small custom profile. But let me know if I missed anything else besides this issue.
cc @seitenbau-govdata