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

20 lines
394 B
JavaScript
Raw Normal View History

webpack: Migrate translations.js to use ES2015 syntax.
2017-06-15 19:48:48 +02:00
import i18next from 'i18next';
[third] Integrate i18next with Handlebars
2016-05-13 12:44:03 +02:00
translations: Clean up indentation for initialization code.
2018-05-30 18:14:20 +02:00
i18next.init({
lng: 'lang',
resources: {
lang: {
translation: page_params.translation_data,
translations: Load translations from page_params.translation_data. With this commit, we change how we deal with translation for strings. Previously we used to fetch the translations data after loading which created a lot of unpleasant race bugs. So we changed this to use the `translation_data` sent in `page_params` which is available at load time. The previous fetching can be useful if we want to change the string to the changed language without reloading the page but since we ask the user to reload the page after changing the default language so fetching after loading isn't useful for us and hence we can add resource only once. Ultimately, we can remove the i18next plugins too. We leave the logic for clearing local storage, patched to fully clear it. Fixes: #9087.
2018-05-29 12:34:59 +02:00
},
translations: Clean up indentation for initialization code.
2018-05-30 18:14:20 +02:00
},
nsSeparator: false,
keySeparator: false,
interpolation: {
prefix: "__",
suffix: "__",
},
returnEmptyString: false, // Empty string is not a valid translation.
});
Ensure translations are loaded. Since i18next loads translations asynchronously we need to make sure that they are loaded before we call the JS code which depends on them. Fixes #982
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;