Missing translation files issue.

[MicheleMallia]

URL address of the page where you encountered the problem

Local Docker deployment:

http://localhost:9090/

The same problem can occur on any Skosmos page when the selected or default UI language is configured in skosmos:languages but the corresponding translation file is missing from resource/translations.

Description of the problem

Skosmos 3.2 returns HTTP 500 when a language is declared in the global skosmos:languages configuration but the corresponding UI translation file does not exist.

Example configuration:

skosmos:languages (
  [ rdfs:label "en" ; rdf:value "en_GB.utf8" ]
  [ rdfs:label "it" ; rdf:value "it_IT.utf8" ]
  [ rdfs:label "ca" ; rdf:value "ca_ES.utf8" ]
  [ rdfs:label "ro" ; rdf:value "ro_RO.utf8" ]
) ;

With this configuration, Skosmos tries to load files such as:

resource/translations/messages.ca.json
resource/translations/messages.ro.json

If one of those files is missing, the application crashes with a fatal error instead of falling back to an available language.

Steps to reproduce:

1. Configure a Skosmos instance with a language in skosmos:languages that does not have a matching resource/translations/messages.<language>.json file, for example ro.
2. Build and start the Docker container.
3. Open the Skosmos home page or request it with curl.
4. The application returns HTTP 500.

Expected outcome after the issue is fixed:

Skosmos should not crash when a configured UI language is missing a translation file. It should either:

• skip missing translation files and fall back to the default or fallback locale, such as English;
• or fail during configuration validation with a clear error message explaining that messages.<language>.json is required for every entry in skosmos:languages.

The fallback behavior would be preferable because vocabularies may contain content labels in languages that do not yet have a complete Skosmos UI translation.

This is also confusing because there are two different language settings:

• skosmos:language on a vocabulary defines content languages available in the SKOS data;
• global skosmos:languages defines UI/interface languages.

If a deployment has vocabularies with labels in Catalan or Romanian, it is easy to assume those languages can also be listed globally. However, doing so currently requires a matching UI translation file, otherwise the application crashes.

Additional information (e.g. screenshots) about the problem

Observed Apache/PHP log:

PHP Fatal error: Uncaught Symfony\Component\Translation\Exception\NotFoundResourceException:
File "/var/www/html/src/model/../../resource/translations/messages.ro.json" not found.
in /var/www/html/vendor/symfony/translation/Loader/FileLoader.php:31

The stack trace points to src/model/Model.php, where Skosmos registers a translation resource for every configured global language:

$this->translator->addResource(
    'json',
    __DIR__.'/../../resource/translations/messages.' . $langcode . '.json',
    $langcode
);

A possible fix would be to check that the translation file exists before registering it:

$translationFile = __DIR__.'/../../resource/translations/messages.' . $langcode . '.json';

if (file_exists($translationFile)) {
    $this->translator->addResource('json', $translationFile, $langcode);
}

Fallback locales could also be configured explicitly:

$this->translator->setFallbackLocales(['en']);

There may also be a related locale naming issue. Some configurations use language tags such as pt-br or fr-ca, while existing translation files are named with underscores, for example:

messages.pt_BR.json
messages.zh_CN.json

Environment:

• Skosmos: 3.2
• Symfony Translation: 6.4
• PHP: 8.3
• Docker runtime based on Ubuntu 24.04
• Composer dependencies installed from lock file

The browser you used when the problem appeared

The issue was reproduced with curl against the local Docker deployment.

It is server-side and should not be browser-specific. Browsers would show an HTTP 500 response.

[osma]

Thanks for submitting the issue!

Skosmos should not crash when a configured UI language is missing a translation file. It should either:

• skip missing translation files and fall back to the default or fallback locale, such as English;
• or fail during configuration validation with a clear error message explaining that messages..json is required for every entry in skosmos:languages.

I think that falling back to a default language would be more confusing than helpful. The UI language setting requires that a message file exists; this is different from having a partial translation, which is quite normal, and then some of the messages will be shown in English.

I think failing with a clear error message is the better option here.

[MicheleMallia]

Thanks, that clarifies the intended behavior.

Just to make sure I understand the practical consequence for deployments:

If I want to list a language in skosmos:languages as an available UI language, do I need to create and maintain the corresponding resource/translations/messages.<lang>.json file myself?

For example, if my vocabularies contain Catalan or Romanian labels and I also want ca or ro to appear as UI language options, should I add files such as:

resource/translations/messages.ca.json
resource/translations/messages.ro.json

even if they are initially incomplete?

And if I only want Catalan or Romanian as vocabulary content languages, but not as UI languages, should I keep them only in each vocabulary’s skosmos:language setting and remove them from the global skosmos:languages list?

Thanks in advance!

[osma]

If I want to list a language in skosmos:languages as an available UI language, do I need to create and maintain the corresponding resource/translations/messages..json file myself?

Basically yes, but there are tools and guides for managing translations. See this wiki page. You are welcome to become a translator for Catalan and/or Romanian UI translations. You can edit them in Lokalise and download them directly from there in JSON format for your own use. Then we will include them in subsequent Skosmos releases.

And if I only want Catalan or Romanian as vocabulary content languages, but not as UI languages, should I keep them only in each vocabulary’s skosmos:language setting and remove them from the global skosmos:languages list?

Yes. It's OK to have vocabulary/content languages that are not UI languages, and vice versa.

[MicheleMallia]

Thanks! I close the issue.

[osma]

The crash/500 error instead of a helpful error message is still a valid concern, so I will reopen this.

[MicheleMallia]

Ah ok, sorry!