Gestion des métadonnées traduisibles lors des moissonnages

[alhyss]

Langues obligatoires

Lors du moissonnage DCAT, les dictionnaires contenant les métadonnées traduisibles sont construits par la fonction object_value_multilang du module dcat.profiles.dataset._functions, à partir de la liste de langues fournies par get_langs. Cette dernière renvoie ['en','fr'] - la liste est écrite en dur dans le module. Si d'autres langues apparaissent dans les métadonnées, elles sont ajoutées au dictionnaire, en plus des langues renvoyées par get_langs.

À analyser : est-il nécessaire, notamment pour l'affichage, que les dictionnaires de traductions comportent au moins les langues que l'utilisateur peut sélectionner dans l'interface ?

Si oui, alors :

• Les langues obligatoires devraient être un paramètre accessible par tous les moissonneurs, autant que possible le même paramètre qui sert à générer le menu de sélection de la langue dans l'interface.
• Il faudrait modifier les classes spatial.base.EcospheresSimpleTranslationDict et spatial.base.EcospheresMultiTranslationsDict pour ajouter des clés pour les langues de cette liste à l'initialisation des dictionnaires. À voir si, pour EcospheresSimpleTranslationDict, la valeur par défaut doit être None ou une chaîne de caractères vide. object_value_multilang met None, mais ici ce sont des chaînes de caractères vides.
• Un test confirmant que l'ajout d'autres langues ne pose pas de problème serait le bienvenu.

Si non, alors il est plus simple de ne pas ajouter ces clés potentiellement vides aux dictionnaires.

Cardinalité

La fonction object_value_multilang ne produit qu'un seul type de dictionnaire de traductions, qui n'admet qu'une seule valeur par langue :

{
    'fr': 'Traduction française',
    'en': 'English translation'
}

Or le schéma de métadonnées prévoit que certains champs admettent plusieurs valeurs d'une même langue, car DCAT-AP fait de même et il ne paraît pas souhaitable de perdre des valeurs en réduisant la cardinalité. C'est par exemple le cas de provenance et de free_tags.

Pour ces champs, c'est un dictionnaire de cette forme qui serait attendu :

{
    'fr': [
        'Traduction française 1',
        'Traduction française 2'
    ],
    'en': [
        'English translation'
    ]
}

De tels dictionnaires seraient vraisemblablement à créer par une autre fonction que object_value_multilang, qui est à ce stade utilisée pour provenance, et pourrait être inspirée de ce qui est fait pour free_tags.

Langue par défaut

object_value_multilang considère qu'une valeur littérale sans langue spécifiée est la valeur dans la "langue par défaut", déclarée en dur dans la fonction comme étant le français.

    default_lang = 'fr'
    lang_dict = {}
    for o in self.g.objects(subject, predicate):
        if multilang and o.language:
            lang_dict[o.language] = str(o)
            lang_dict[o.language] = str(o)
        elif multilang:
            lang_dict[default_lang] =str(o)
        else:
            return str(o)

Ainsi, avec <https://europeandataportal.eu/set/data/bm13sogjiwmi1eyxrlq> dct:title "Gross nutrient balance on agricultural land"@en, "Bilan nutritif brut de la terre agricole"@fr, "Bruttonährstoffbilanz der Agrarflächen", on obtient le dictionnaire de traductions suivant, car la valeur sans langue spécifiée vient écraser la valeur en français :

{
    'fr': 'Bruttonährstoffbilanz der Agrarflächen',
    'en': 'Gross nutrient balance on agricultural land'
}

Ce n'est vraiment pas un comportement logique. En admettant qu'il est acceptable de considérer que les valeurs sans langue sont en français, il paraîtrait plus judicieux d'avoir quelque chose de cet ordre :

    default_lang = 'fr'
    lang_dict = {lang: '' for lang in get_langs()}
    for o in self.g.objects(subject, predicate):
        if not multilang:
            return str(o)
        if o.language:
            lang_dict[o.language] = str(o)
        elif not lang_dict.get(default_lang):
            lang_dict[default_lang] = str(o)

Il pourrait également être souhaitable à terme que la langue par défaut soit un paramètre accessible à tous les moissonneurs, même si cette valeur est peu susceptible d'être modifiée dans le cas d'Ecosphères. À noter que côté moissonnage INSPIRE, c'est aussi en dur. La langue est déduite des métadonnées si possible, sinon il est considéré qu'elles sont en français.

        language = iso_values.get('metadata-language') or 'fr'

Même si elle ne sert pas pour le moissonnage INSPIRE, le module spatial.base définit aussi une langue par défaut de dernier recours, utilisée lorsque le moissonneur ne fournit pas l'information. Elle est là encore écrite en dur dans le module.

MAIN_LANGUAGE = 'fr'

Dictionnaires de traduction vides

S'il n'y a aucune traduction, la fonction object_value_multilang renvoie None plutôt qu'un dictionnaire dont toutes les clés ont pour valeur None ou des chaînes de caractères vides.

    __values=sum([bool(lang_dict[key]) for key in lang_dict]) == 0
    return None if __values else lang_dict

Ce n'est pas ce qui est fait côté INSPIRE, où EcospheresSimpleTranslationDict et EcospheresMultiTranslationsDict sont actuellement des dictionnaires vides en l'absence de traduction.

À clarifier : Quelle est la meilleure façon de représenter l'absence de traduction ?

Utiliser None nécessiterait vraisemblablement que le moissonneur INSPIRE ne renvoie pas directement un objet spatial.base.EcospheresDatasetDict, mais le résultat d'une méthode produisant un dictionnaire nettoyé.