How to disable caching for i18next translation.json files?

Question

I'm running a single page app on IIS and using i18next library for translations in my app. The problem is that sometimes when I add new keywords to my translation.json file and hit refresh, the browser still uses the old cached translation file and this results in user seeing the added keywords but not translations. E.g. if I add a keyword "somekey": "Some text here..." then somekey would be displayed instead of the specified text.

As my translation.json file is located in a folder called locales like this:

locales
    en
      translation.json

I tried adding following setting to web.config:

<location path="locales">
  <system.webServer>
    <staticContent>
      <clientCache cacheControlMode="DisableCache" />
    </staticContent>
  </system.webServer>
</location>

However, when I looked at the network traffic with Chrome developer tools, I noticed that translation.json file is still coming from cache and Cache-Control: no-cache header is missing. Why this does not work? What is right way to disable the caching of the file?

EDIT: Just checked the site again and it seems that translation.json file now has the Cache-Control: no-cache header and it is actually being retrieved from server every time I refresh the page. At this point I'm thinking that the issue might have had something to do with our release process and config changes not being applied. Not sure though.

score 12 · Answer 1 · answered Apr 19 '17 at 15:07

This is actually more tricky than it seems. I assume you're using the angular translate module.

I did cache busting where it loads the json files:

$translateProvider.useLoader('$translatePartialLoader', {
        urlTemplate: 'AppScripts/i18n/{part}-{lang}.json' + '?cb=' + (new Date()).getTime()
    });

That way it will never cache the language files, and will load the new ones on every request (without refreshing the page or clearing the cache).

The web config setting gets completely ignored, I believe because the way the plugin loads the files with ajax calls. Also, the json files can't be minified with .net bundling because the keys will change when compressed, so instead of "MAIN.FIRSTNAME": "First Name" you'll have something like "abc": "First Name" and it won't work since the views have the original names.

You can also use the version if you keep one, to bust the cache only when you release a new version, something like

    + '?v=' + myVersionVar

instead of using current timestamp which will always load the files on every request.

score 6 · Answer 2 · answered Apr 18 '17 at 17:28

I've came across this same situation using the combo SPA + i18next + IIS, and noticed that sometimes the json files have not been updated.

The main reason why this becames weird at some point is that there is a big chance that you have changed the IIS's web.config settings AFTER the files have been already cached by Google Chrome, since the first time the file has been downloaded without any Cache-Control header.

Cause

The json files was not presenting the Cache-Control: no-cache header, so the after a 304 - Not Modified response, it started to use google chrome's local disk cache.

Solution

It was solved by

1) Cleaning the Google Chrome's cache at Network tab (clear all the cache also do the job)

2) Placing a web.config file at /locales/ folder with the following staticContent rules, and location without specify a path attribute:

<?xml version="1.0" encoding="utf-8"?>
    <configuration>
        <location>
            <system.webServer>
                <staticContent>
                    <clientCache cacheControlMode="DisableCache" />
                </staticContent>
            </system.webServer>
        </location>
    </configuration>

As stated at the docs about the <location> tag:

path attribute

Using <location> with a missing path attribute applies the configuration settings to the current directory and all child directories.

In this case I've applied the rule specifically in the /locales/ folder, aiming to not interfere in caching for other static contents across the website, such as Images, JavaScript files, etc. The expected behavior may vary accordingly to your solution's needs.

ivandax · Answer 3 · 2021-05-14T08:27:32.423

I had a similar problem, I needed the translations file to be retrieved fresh after each build. A solution I found was to, first, add a plugin that allows the webpack build hash to be available on runtime (add this on the webpack.config.js file):

webpack.ExtendedAPIPlugin()

This will allow you to declare the hash anywhere on your app

const hash = __webpack_hash__;

Then, on your i18next.init(), on the backend section, I added the hash as a parameter to the request.

`/locales/.json/hash=${hash}`

This way, the hash will be different after each new build, and on the first request after the build the most recent translations file will be retrieved, preventing it from using the cache.

Filip Seman · Answer 4 · 2021-09-02T18:44:41.990

3

Simple configuration

I'm using i18next-http-backend for XHR request.

...
import { initReactI18next } from 'react-i18next';
import Backend from 'i18next-http-backend';

i18next
    .use(Backend)
    .use(initReactI18next)
    .init({
        backend: {
            loadPath: '/content/locales/{{lng}}.json',
            requestOptions: {
                cache: 'no-store',
            },
        },
        ...
});

MDN

no-store

The response may not be stored in any cache. Note that this will not prevent a valid pre-existing cached response being returned. Clients can set max-age=0 to also clear existing cache responses, as this forces the cache to revalidate with the server (no other directives have an effect when used with no-store).

edited Sep 02 '21 at 18:44

answered Sep 02 '21 at 18:16

Filip Seman

1,252
2
15
22

Disabling the cache all together seems a bit extreme, especially on huge files. In the end, I decided to have a mongodb collection (since I had a database anyway) so that I can have more control on the response headers (especially the `etag`) – usersina Apr 19 '23 at 08:40
If you want to keep things simple and avoid generating random hash filenames, no-store is a good option. But if you prioritize performance and have a large payload, caching could be more beneficial even though it could make your build process more complicated. – Filip Seman Apr 19 '23 at 09:57

score 0 · Answer 5 · edited Jun 25 '20 at 00:17

0

Thanks to @alx, used the following and replaced version_number as part of my grunt build.

$translateProvider.useStaticFilesLoader({
    prefix: 'locale/lang_',
    suffix: '.json?cd=version_number'    });

edited Jun 25 '20 at 00:17

David Buck

3,752
35
31
35

answered Jun 24 '20 at 22:24

Siva

1
2

score -1 · Answer 6 · edited Jun 25 '20 at 00:19

-1

what if we enabled the bundling when we deploy the application. like below.

#if DEBUG
    BundleTable.EnableOptimizations = false;
#else
    BundleTable.EnableOptimizations = true;
#endif

edited Jun 25 '20 at 00:19

David Buck

3,752
35
31
35

answered May 05 '17 at 07:45

Sangmeshwar Mashal

1
1

How to disable caching for i18next translation.json files?

6 Answers6

Cause

Solution