2020-07-15 01:29:15 +02:00
|
|
|
import i18next from "i18next";
|
2016-05-13 12:44:03 +02:00
|
|
|
|
2018-05-30 18:14:20 +02:00
|
|
|
i18next.init({
|
2020-07-15 01:29:15 +02:00
|
|
|
lng: "lang",
|
2018-05-30 18:14:20 +02:00
|
|
|
resources: {
|
|
|
|
|
lang: {
|
|
|
|
|
translation: page_params.translation_data,
|
2018-05-29 12:34:59 +02:00
|
|
|
},
|
2018-05-30 18:14:20 +02:00
|
|
|
},
|
|
|
|
|
nsSeparator: false,
|
|
|
|
|
keySeparator: false,
|
|
|
|
|
interpolation: {
|
|
|
|
|
prefix: "__",
|
|
|
|
|
suffix: "__",
|
|
|
|
|
},
|
2020-07-16 23:29:01 +02:00
|
|
|
returnEmptyString: false, // Empty string is not a valid translation.
|
2018-05-30 18:14:20 +02:00
|
|
|
});
|
2016-06-10 09:03:36 +02:00
|
|
|
|
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:
e3f1d025aeee022e9edb83b94106fd716f77147a
We then removed the caching option altogether a year
later in May 2018:
cff40c557b2a35e03ac03af1125e19ba88555aef
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.
2020-02-29 12:23:06 +01:00
|
|
|
window.i18n = i18next;
|
