Japanese locale file not found, setting "ja" as default language causes 500

[Manny Rodriguez]

Hello,

I'm trying to set an AtoM v2.7 site to use Japanese.

As per the docs here:
https://www.accesstomemory.org/en/docs/2.7/user-manual/administer/default-language/

I'm editing the /apps/qubit/config/settings.yml file, and set "default_culture" to "jp".

That resulted in an error. I then looked up language codes here, and it turns out the correct code for Japanese is "ja".

I'm using this list to get the language codes:
https://gist.github.com/msikma/8912e62ed866778ff8cd

After making the change, I've cleared the cache with:
php symfony cc

However, the site will still not load, I get a 500 error. In the logs, I see the error:
[Thu Mar 28 21:22:54.390913 2024] [php7:notice] [pid 1106] [client 198.44.128.116:44654] Data file for "jp" was not found.

I then tried changing default_culture back to "en", but I get the same error. I'm not able to change the site back to English.

After changing default_culture back to English, I've cleared the cache, restarted Apache, and even rebooted the whole server a few times, but I'm getting the same "Data file for "jp" was not found" error.

It's as if something is stuck to "jp", even though the config file is being updated to several other values. What else can I try?

Thanks!

[Dan Gillean]

Hi Manny, 

First, here is a list of language codes that are actually supported in AtoM, that you can use going forward: 

• https://bit.ly/AtoM-langs

This is a strange error, and not one I recall hearing about before. You mention Apache, so I am curious to know if there are other ways that your installation differs from the recommended installation instructions (which typically use Ubuntu 20.04, PHP 7.4, MySQL 8, Nginx, and Elasticsearch 5.6 for an AtoM 2.7 installation)?

Clearing the application cache is a good idea. Don't forget that PHP-FPM also caches content - you can restart it with: 

• sudo systemctl restart php7.4-fpm
• See: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#restarting-php-fpm 

 Our installation instructions also include optional caching engines like Memcached, so restart that as well if installed: 

• sudo systemctl restart memcached
• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#restarting-memcached
  

You are normally meant to repopulate the search index after making culture changes, so I would try running the repopulate task as well: 

• php symfony search:populate
• See: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/populate-search-index

If for some reason that generates an error, then you can also try manually deleting the search index first, with: 

• curl -XDELETE 'localhost:9200/atom'

Note - if you get an error because cURL is not installed (i.e. a command not found or similar error), you may need to install it first. On Ubuntu, you can do this with:

• sudo apt update
• sudo apt install curl

Let us know how that goes! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/8f75894e-3095-4a35-870a-d3e358f110d9n%40googlegroups.com.

[Manny Rodriguez]

Hi Dan,

Thanks for the help.

I wonder if the `default_culture` setting is being saved to the database or some other persistent storage, and when I accidentally set the invalid value, it got stuck there even after setting a valid value?

Previously, I had cleared all the caches that apply (cache:clear, fpm), and ran a search:populate.

I ended up restoring the instance from a backup before I made the language change, and then changed default_culture to "ja", and everything works as expected. So the issue seems to be with recovering from an invalid locale value.

[Dan Gillean]

Interesting! 

Thanks for updating us, Manny - I'm glad you got things sorted out locally, and happy to hear you had some backups! I will bring this to the attention of the AtoM Maintainers, so they can investigate and try to reproduce at some point in the future. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/51835c4c-735f-4ff5-8aad-cb974abaa081n%40googlegroups.com.