2019-06-25 11:39:03 +02:00
|
|
|
// Below, we register Zulip-specific extensions to the handlebars API.
|
|
|
|
//
|
|
|
|
// IMPORTANT: When adding a new handlebars helper, update the
|
|
|
|
// knownHelpers array in the webpack config so that webpack knows your
|
|
|
|
// helper is registered at runtime and don't try to require them when
|
|
|
|
// bundling.
|
|
|
|
|
2013-08-27 20:17:42 +02:00
|
|
|
// We don't want to wait for DOM ready to register the Handlebars helpers
|
|
|
|
// below. There's no need to, as they do not access the DOM.
|
|
|
|
// Furthermore, waiting for DOM ready would introduce race conditions with
|
|
|
|
// other DOM-ready callbacks that attempt to render templates.
|
|
|
|
|
|
|
|
Handlebars.registerHelper('plural', function (condition, one, other) {
|
2018-06-06 18:19:09 +02:00
|
|
|
return condition === 1 ? one : other;
|
2013-08-27 20:17:42 +02:00
|
|
|
});
|
|
|
|
|
2019-06-25 02:54:18 +02:00
|
|
|
Handlebars.registerHelper({
|
|
|
|
eq: function (a, b) { return a === b; },
|
|
|
|
and: function () {
|
|
|
|
// last argument is Handlebars options
|
|
|
|
if (arguments.length < 2) {
|
|
|
|
return true;
|
2013-08-13 18:08:12 +02:00
|
|
|
}
|
2019-11-02 00:06:25 +01:00
|
|
|
let i;
|
2019-06-25 02:54:18 +02:00
|
|
|
for (i = 0; i < arguments.length - 2; i += 1) {
|
|
|
|
if (!arguments[i] || Handlebars.Utils.isEmpty(arguments[i])) {
|
|
|
|
return arguments[i];
|
|
|
|
}
|
2014-02-13 21:16:43 +01:00
|
|
|
}
|
2019-06-25 02:54:18 +02:00
|
|
|
return arguments[i];
|
|
|
|
},
|
|
|
|
or: function () {
|
|
|
|
// last argument is Handlebars options
|
|
|
|
if (arguments.length < 2) {
|
|
|
|
return false;
|
|
|
|
}
|
2019-11-02 00:06:25 +01:00
|
|
|
let i;
|
2019-06-25 02:54:18 +02:00
|
|
|
for (i = 0; i < arguments.length - 2; i += 1) {
|
|
|
|
if (arguments[i] && !Handlebars.Utils.isEmpty(arguments[i])) {
|
|
|
|
return arguments[i];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return arguments[i];
|
|
|
|
},
|
|
|
|
not: function (a) { return !a || Handlebars.Utils.isEmpty(a); },
|
2018-09-02 09:38:09 +02:00
|
|
|
});
|
|
|
|
|
templates: Cache translations.
For Manage Streams, when we render the subscriptions
template, a significant amount of time is taken
by the "t" helper.
Obviously for the first call, we expect "t" to be
somewhat expensive, but subsuquent calls should be
fast, but i18next seems to have some overhead.
Also, we can save a tiny bit of overhead (marking it
as a safe string) that comes from our helper.
As an aside, are we sure it's ok to mark translations
as safe strings?
To test before and after, use blueslip.timings before
and after this commit. When I tested with about 300
streams, the difference is pretty striking:
without cache: 100ms
with cache: 20ms
This is particularly interesting, since the subscriptions
templates have long strings for things like the SVG-based
checkmarks, but they're not really the bottleneck.
Unfortunately, this doesn't seem to be a huge win
elsewhere. In some places we don't call "t", but of
course those might change in the future and benefit from
the cache. And in other places we have smart widgets
that avoid rendering all N objects at one (e.g. buddy
list and list_render).
So this might be too big a hammer to speed up one
screen (albeit a really slow one). It's possible
that we should simply move the i18n.t step **outside**
of certain templates to avoid doing them in a loop.
2020-01-15 15:05:17 +01:00
|
|
|
// Note that this i18n caching strategy does not allow us to support
|
|
|
|
// live-updating the UI language without reloading the Zulip browser
|
|
|
|
// window. That constraint would be very hard to change in any case,
|
|
|
|
// though, because of how Zulip renders some strings using the backend
|
|
|
|
// Jinja2 templating engine, so we don't consider this important.
|
|
|
|
const t_cache = new Map();
|
|
|
|
|
2016-05-13 12:44:03 +02:00
|
|
|
Handlebars.registerHelper('t', function (i18n_key) {
|
|
|
|
// Marks a string for translation.
|
|
|
|
// Example usage:
|
|
|
|
// {{t "some English text"}}
|
templates: Cache translations.
For Manage Streams, when we render the subscriptions
template, a significant amount of time is taken
by the "t" helper.
Obviously for the first call, we expect "t" to be
somewhat expensive, but subsuquent calls should be
fast, but i18next seems to have some overhead.
Also, we can save a tiny bit of overhead (marking it
as a safe string) that comes from our helper.
As an aside, are we sure it's ok to mark translations
as safe strings?
To test before and after, use blueslip.timings before
and after this commit. When I tested with about 300
streams, the difference is pretty striking:
without cache: 100ms
with cache: 20ms
This is particularly interesting, since the subscriptions
templates have long strings for things like the SVG-based
checkmarks, but they're not really the bottleneck.
Unfortunately, this doesn't seem to be a huge win
elsewhere. In some places we don't call "t", but of
course those might change in the future and benefit from
the cache. And in other places we have smart widgets
that avoid rendering all N objects at one (e.g. buddy
list and list_render).
So this might be too big a hammer to speed up one
screen (albeit a really slow one). It's possible
that we should simply move the i18n.t step **outside**
of certain templates to avoid doing them in a loop.
2020-01-15 15:05:17 +01:00
|
|
|
|
|
|
|
const cache_result = t_cache.get(i18n_key);
|
|
|
|
if (cache_result !== undefined) {
|
|
|
|
return cache_result;
|
|
|
|
}
|
2019-11-02 00:06:25 +01:00
|
|
|
const result = i18n.t(i18n_key);
|
templates: Cache translations.
For Manage Streams, when we render the subscriptions
template, a significant amount of time is taken
by the "t" helper.
Obviously for the first call, we expect "t" to be
somewhat expensive, but subsuquent calls should be
fast, but i18next seems to have some overhead.
Also, we can save a tiny bit of overhead (marking it
as a safe string) that comes from our helper.
As an aside, are we sure it's ok to mark translations
as safe strings?
To test before and after, use blueslip.timings before
and after this commit. When I tested with about 300
streams, the difference is pretty striking:
without cache: 100ms
with cache: 20ms
This is particularly interesting, since the subscriptions
templates have long strings for things like the SVG-based
checkmarks, but they're not really the bottleneck.
Unfortunately, this doesn't seem to be a huge win
elsewhere. In some places we don't call "t", but of
course those might change in the future and benefit from
the cache. And in other places we have smart widgets
that avoid rendering all N objects at one (e.g. buddy
list and list_render).
So this might be too big a hammer to speed up one
screen (albeit a really slow one). It's possible
that we should simply move the i18n.t step **outside**
of certain templates to avoid doing them in a loop.
2020-01-15 15:05:17 +01:00
|
|
|
const safe_result = new Handlebars.SafeString(result);
|
|
|
|
t_cache.set(i18n_key, safe_result);
|
|
|
|
return safe_result;
|
2016-05-13 12:44:03 +02:00
|
|
|
});
|
|
|
|
|
|
|
|
Handlebars.registerHelper('tr', function (context, options) {
|
|
|
|
// Marks a block for translation.
|
|
|
|
// Example usage 1:
|
|
|
|
// {{#tr context}}
|
|
|
|
// <p>some English text</p>
|
|
|
|
// {{/tr}}
|
|
|
|
//
|
|
|
|
// Example usage 2:
|
|
|
|
// {{#tr context}}
|
|
|
|
// <p>This __variable__ will get value from context</p>
|
|
|
|
// {{/tr}}
|
|
|
|
//
|
|
|
|
// Notes:
|
|
|
|
// 1. `context` is very important. It can be `this` or an
|
|
|
|
// object or key of the current context.
|
|
|
|
// 2. Use `__` instead of `{{` and `}}` to declare expressions
|
2019-11-13 14:48:21 +01:00
|
|
|
const result = i18n.t(options.fn(context).trim().split("\n").map(s => s.trim()).join(" "), context);
|
2016-05-13 12:44:03 +02:00
|
|
|
return new Handlebars.SafeString(result);
|
|
|
|
});
|
|
|
|
|
2019-10-25 09:45:13 +02:00
|
|
|
window.templates = exports;
|