Hi, I've never seen this behavior before and it cannot be reproduced on "out of the box" DSpace. For instance, our Demo Site (https://demo.dspace.org/home) is running 9.1 and is not having this issue.
My best guess is that some sort of local customization has accidentally *broken* this language file hashing process. This hashing process occurs in the webpack build process, and was first introduced in version 7.6.1 via this PR: https://github.com/DSpace/dspace-angular/pull/2464 So, I'd recommend looking closely at whether you've accidentally modified the webpack build process, or if you are getting any logged errors when you rebuild via "npm run build:prod" (which is also executed via "npm run start"). You also should verify that you are using a supported version of Node.js (18.19+, 20.x or 22.x) and are following the installation documentation at https://wiki.lyrasis.org/display/DSDOC9x/Installing+DSpace Finally, if none of this helps, then I'd recommend trying to install *out of the box* DSpace locally to verify that it works *without any of your customizations*. It should. Assuming it does, then you could try to apply each of your customizations again to see which one results in the i18n failures -- as that can help you narrow down which customization is the problem. Good luck, Tim On Monday, September 22, 2025 at 6:13:28 AM UTC-5 [email protected] wrote: > I have a strange error on my dspace version 9.1 repository at > https://karuspace.karu.ac.ke. The language files are failing to load when > in production mode instead returning 404 error. I made the following > observations > 1. It only occurs when running in production mode. Even when I run the > application on my local development machine using `npm run start`, this > error still occurs > 2. It only occurs on GET requests, eg > https://karuspace.karu.ac.ke/search?spc.page=1. Submitting a form which > uses POST requests behaves normally. > 3. It only seems to occur when accessing /search paths eg > https://karuspace.karu.ac.ke/search?spc.page=1 > 4. The browser appears to be looking for /assets/i18n/en.json which in my > case does not exist in either dist/browser/assets/i18n or > dist/server/assets/i18n directories. On other sites that are working > correctly, these file names are hashed, > like en.048a59f6aded4af79bc3c464e8348dfa.json. The files with hashed names > also exist on my production system in i18n directories. > > So why is my app looking for en.json instead > of en.048a59f6aded4af79bc3c464e8348dfa.json? > > > *KARATINA UNIVERSITY* > *Inspiring Innovation and Leadership* > Main Campus | Kagochi, Karatina | P.O. Box 1957 – 10101 Karatina, Kenya > Tel: +254 20 217 6713 | Cell: +254 729 721 200 > Email: [email protected] | Website: www.karu.ac.ke > > *DISCLAIMER* > The information in this email is confidential and may be legally > privileged information and is intended solely for the addressee. Please > read the Karatina University (KarU) Email Terms and Conditions. > https://karu.ac.ke/karatina-university-email-disclaimer/ > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/3faf5887-e177-4013-b5ec-c80c0d3061f7n%40googlegroups.com.
