Localization of external exporters

[lubitchv]

I have a question regarding localization. Currently croissant has a function:

  /**
     * The display name shown in the UI
     *
     * @param locale
     */
    @Override
    public String getDisplayName(Locale locale) {
        // This example includes the language in the name to demonstrate that locale is
        // available. A production exporter would instead use the locale to generate an
        // appropriate translation.
        return "Croissant";
    }

If one wants to change the name is it possible to do in Dataverse with Bundle.properties and get existing Croissant jar without change, or one needs to change external exporter itself by changing code and adding localization files inside external exporter?

[pdurbin]

If it helps, there's also this comment upstream in modules/dataverse-spi/src/main/java/io/gdcc/spi/export/Exporter.java

/**
 * This method should return the display name of the metadata format this
 * Exporter provides. Display names are used in the UI, specifically in the menu
 * of avaiable Metadata Exports on the dataset page/metadata tab to identify the
 * format.
 */
String getDisplayName(Locale locale);

Let's see if @qqmyers feels differently but I suspect it's incumbent upon each exporter to implement internationalization.

@ErykKul have you thought about this at all? I'm asking because I know your exporter at https://github.com/gdcc/exporter-transformer already has config files which contain "displayName". Here are some relevant lines in your code:

• https://github.com/gdcc/exporter-transformer/blob/1.0.10/src/main/java/io/gdcc/spi/export/transformer/TransformerExporter.java#L193
• https://github.com/gdcc/exporter-transformer/blob/1.0.10/src/main/java/io/gdcc/spi/export/transformer/Config.java#L65

It does look like you've already implemented internationalization. 🤔

[qqmyers]

FWIW: Exporters currently work differently than previewers, mostly because exporters are Java and can have a getDisplayName(Locale) method. With previewers we have the toolName and you can have lines like externaltools.pdfPreviewer.displayname=Read Document in Bundle.properties and its i18n variants.

The former is nice because the exporters can then be completely bundled with their i18n strings, including displayName, but it also means you can't just include what they need in the main Dataverse Bundle.

Conversely, the external tool/previewer mechanism makes it easy to i18n in bulk/as part of Bundle.properties, but previewer creators can't do their own i18n of their name (internal strings can all be i18n in previewers as part of the previewer itself). And, since most previewers are just static web pages, there isn't a good way for Dataverse to dynamically get translated names so we don't have a choice. (Adding i18n of the toolName as part of the config file might be another approach to consider.)

Not sure either is ideal, but that's how it is.

[ErykKul]

@pdurbin
I did implement localization for the display name, I guess I forgot to document it. The default exporter is localized config.json:

{
    "formatName": "example_transformer_json",
    "harvestable": false,
    "availableToUsers": true,
    "mediaType": "application/json",
    "displayName": "Default transformer example",
    "displayName_en": "Transformer example",
    "displayName_fr": "Exemple de transformer",
    "displayName_fr-CA": "Exemple de transformateur"
}

[pdurbin]

@ErykKul great thanks.

I'm wondering if we should update the example exporter to support at least English and French. We say the example exporter may be used as a template.