Stream: internationalization

Topic: use cases


view this post on Zulip Falco (Copenhagen University Library) (Jul 08 2026 at 08:53):

Hey everyone,

thanks to @Alyssa Conlon and her Borealis colleagues for the presentation at the Community Call yesterday (and at the Community meeting in Barcelona) and their ideas on resurrecting the Internationalization WG.

I just wanted to expand a little bit on our use case in Denmark:
We do not make a translation into Danish, since there is a common understanding that research infrastructure services should be primarily provided in English here. However, we have made our own customized English version of the language properties files. Initially, we were just looking for a way to remove / replace all the links to the Dataverse guides in the UI, since we are using our own guides on a separate homepage.

After getting started, we made a lot of other changes as well in order to make the language more consistent and user-friendly, adapt it to some specific choices we had made for our own repository, and customize the email notifications. If anyone is curious, you can have a look at the attached properties files (and just use the great tool from Borealis for comparison: https://alliance-rdm-gdr.github.io/Borealis_Localizer/). They should correspond to Dataverse 6.10.

Anyway, with this perspective in mind, I'd be interested in joining this WG and discuss best practices for developing and maintaining customized language files.

@Dieuwertje Bloemen : Could you elaborate more on your approach - I'm not sure I understood what you wrote yesterday.

BuiltInRoles_en.properties
Bundle_en.properties

view this post on Zulip Philip Durbin ๐Ÿš€ (Jul 08 2026 at 13:13):

Falco (Copenhagen University Library) said:

customized English version of the language properties files

Just a heads up that this is being discussed at #docs > changing text in the UI as well.

view this post on Zulip Kris Dekeyser (KU Leuven) (Jul 09 2026 at 15:47):

Hi, stepping in for @Dieuwertje Bloemen, as I'm the one guilty for what we are doing to customise the properties file. I will attach our script and some data file(s) as an example.

The script is written entirely in Bash, but it uses another script written in Ruby to extract properties from the metadata blocks. Please be aware that it is part of a larger ecosystem of supporting scripts and configurations that this script relies on. I cannot share the entirety of it, but you should be able to understand what we are doing without the supporting framework. It will just not run as-is. Some Bash functions and variables are missing in the upload.

The script has several sections:

Copy required properties files

where we copy the distributed properties files into a folder with language specific properties files (*_en.properties). We are using the linux commands cp and rm for this.

Apply metatadata customization

Here we extract some fields from the metadata blocks into extra <metadata block name>_en.properties files. Since it is a more complex operation, we used a ruby script for that. It is a bit much to handle for Bash. I'll add the source code, but it should be easy to rewrite it in Python or so.

We extract the metadata block name and displayName values, title description and watermark for all the datasetfields and the controlledvocabulary items. The metadata block and datasetfields are straight-forward. Extracting the controlled vocabulary items is a bit more complex.

If you have no intent to customise the metadata block text, I think you can just skip this section. I think, because we still export the values, although we do not customise them in the properties. @Philip Durbin ๐Ÿš€ may know if the metadata block text needs to be present in for properties customisation, but I think that is not the case.

Customise text

where we patch the copied properties files based on json files we keep in a custom configuration folder. All done with jq (for reading the json files), grep (to check if the property exists in the properties file) and sed (to replace the value in the properties file.

The JSON files group customisations in a - for us - logical bundle and are structured like this:

{
  "title": "Some title displayed by the update tool for feedback",
  "data": [
    {
      "name": "<name of the properties file>#<name of the property to overwrite>",
      "value": "New value for the property"
    },
    {
      ...
    }
  ]
}

So the update script will perform a change to one of the properties file(s) using each name and value pair in sequence.

update-properties.sh
extract_properties.rb
01-login.json
05-fileUpload.json


Last updated: Aug 18 2026 at 08:27 UTC