The arrows were too close to the scrollbars that it would be
difficult to click them sometimes. This moves over the arrows and
unread counts to combat the issue.
Notifications essentially don't work on any mobile web clients,
so don't even show the banner.
This also fixes a traceback where it checks the permission state
with `notifications.permission_state()`, which calls
`Notification.permission`, which will error due to `Notification`
not existing on mobile devices.
Fixes: #7105.
http://zulip.readthedocs.io/en/latest/architecture-overview.html
mentions "Our mobile clients are separate code repositories: Android
and React Native iOS app. " However Zulip Mobile is the official
mobile Zulip client supporting both iOS and Android.
Edited by tabbott to also fix confusion about the desktop.
We have been assigning locale to language code. Mostly code and locale
are same but for languages like zh-Hans, locale is zh_Hans and code is
zh-hans.
After this commit, compilemessages command should be run.
Previously we were using regexes to extract the language from our
locale files. Now we use LANG_INFO data structure provided by Django
to do the same and fallback to PO files only when language code is not
present in the Django data structure.
We weren't compressing SVG, while at the same time were incorrectly
compressing octet-stream (Which meant downloading .tar.gz files in
Chrome would get double-compressed).
This reverts commit f04981513b.
We're not sure, but we suspect that this made Zulip not show es for
folks using es_es as their locale. Further testing is required.
In the UI we use locale as the code for the language. Django expects
language code. For Simplified Chinese, 'zh_Hans' is the locale which
maps to a directaory under static/locale, and 'zh-hans' is the language
code, which is used in settings.LANGUAGES setting found in Django.
Sparkle was the auto-update system used by the legacy desktop app. We
haven't been capable of using it for auto-update in years, so there's
no reason to keep around the configuration.
The new Electron app uses a different system anyway.
This presents multiple states for the subdomain input option
depending on the existence of a root domain.
Commit modified heavily by Brock Whittaker <brock@zulipchat.com>.
Fixes#6863.
This removes a test for "webkit" in the userAgent string in order
to see whether notifications should be displayed. This is so that
the notifications process will work correctly in Firefox and not
keep registering as "false" which makes the notifications prompt
continue to re-show itself.
This replaces the former non-functional StateHandler
stub with a dictionary-like state object. Accessing it will
will read and store strings in the BotUserStateData model.
Each bot has a limited state size. To enforce this limit while
keeping data updates efficient, StateHandler caches the expensive
query for getting a bot's total state size. Assignments to a key
then only need to fetch that entry's previous size, if any, and
compare it to the new entry's size.
Some bots have class names that differ from their module name,
e.g. `helloworld.py` vs. `HelloWorld`. Our tests should accept
all of these, as long as a handler class is present.
I think an hour after signup is not the right time to try to get someone to
re-engage with a product.
This also makes the day1 email clearly a transactional email both in
experiencing the product and in the eyes of various anti-spam laws, and
allows us to remove the unsubscribe link.
The rules here are fuzzy, and it's quite possible none of Zulip's emails
need an address at all. Every country has its own rules though, which makes
it hard to tell. In general, transactional emails do not need an address,
and marketing emails do.
Tim Abbott
Greg Price
Brock Whittaker
Nikhil Kumar Mishra
Umair Khan
Maarten Rijke
Shubham Dhama
Vishnu Ks
derAnfaenger
Rishi Gupta