Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

i18n: Remove code to sweep local storage. 

Before 2018, we used a feature of i18next where
we would cache translations in local storage
for up to two weeks:

    var cacheOptions = {
        // ...
        prefix: 'i18next:' + page_params.server_generation + ':',
        expirationTime: 2*7*24*60*60*1000,  // 2 weeks
    };

    i18next.init({
        /// ...
        cache: cacheOptions
    }

Because `server_generation` would change each time you
upgraded a server, a frequently upgraded server like
chat.zulip.org would cause its active users to start
to accumulate lots of obsolete key/value pairs in local
storage over the two weeks.

See #4443 for more details.

We eventually reduced the cache life to 2 days.  And then
on top of that, newer versions of the server would start
to clean up after themselves using this commit from
April 2017:

    e3f1d025ae

We then removed the caching option altogether a year
later in May 2018:

    cff40c557b

We kept around the code to remove all the old keys, though.
This was particularly important for users who may have
been hitting servers that did an upgrade to the new
version from some older version that didn't have the
key-fixing code.

But mostly the problem takes care of itself after
either two days or two weeks, even on really out-of-date
servers.

The original problem was most likely to affect server
admins that did a lot of upgrades (and possibly only really
affected chat.zulip.org), so as long as those server
admins continued their patterns, it's highly likely that
they've done several upgrades since May 2018 that would
have cleaned these keys out for good.

And, again, even if there is some strange straggler here,
they probably only have one set of keys that will expire
either two days or two weeks after an upgrade, depending
on how long ago the prior upgrade was.  (All of their
keys based on older versions of `server_generation` would
have long since expired.)

Finally, any upgrade certainly won't make the problem
worse for any users under this hypothetical situation,
since the new server won't be writing new keys.

So I am removing the cleanup code.
This commit is contained in:
Steve Howell 2020-02-29 11:23:06 +00:00 committed by Tim Abbott
parent 6c74af4c06
commit 1abd00eac2
1 changed files with 1 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
static/js/translations.js
View File

@ -1,8 +1,4 @@
// commonjs code goes here
import i18next from 'i18next';
import localstorage from './localstorage';
window.i18n = i18next;
i18next.init({
lng: 'lang',
@ -20,22 +16,4 @@ i18next.init({
returnEmptyString: false, // Empty string is not a valid translation.
});
// garbage collect all old-style i18n translation maps in localStorage.
$(function () {
if (!localstorage.supported()) {
return;
}
// this collects all localStorage keys that match the format of:
// i18next:dddddddddd:w+ => 1484902202:en
// these are all language translation strings.
const translations = Object.keys(localStorage).filter(function (key) {
return /^i18next:\d{10}:\w+$/.test(key);
});
// remove cached translations of older versions.
translations.forEach(function (translation_key) {
localStorage.removeItem(translation_key);
});
return this;
});
window.i18n = i18next;