Update translations from Weblate #1
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
8668125 to
c33b03c
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
2 times, most recently
from
81ea8e1 to
c201ce8
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
c201ce8 to
dea3b83
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
2 times, most recently
from
9ea4a6b to
2a2ff87
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
2a2ff87 to
55f30ff
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
55f30ff to
2cd3f29
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
2cd3f29 to
323e644
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
323e644 to
47dba8f
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
47dba8f to
9c07851
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
9c07851 to
9fd7387
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
9fd7387 to
77a4794
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
2 times, most recently
from
d3a2722 to
bf2e154
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
bf2e154 to
a71a9ce
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
2 times, most recently
from
fddb2e4 to
b1ef5b2
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
b1ef5b2 to
7887c0c
Compare
When we set up the message list in tests, we do it by preparing the
API response for a message fetch or new-message event, via JSON. But
{Stream,Dm}Message.toJson drops poll data on the floor, which
defeats setting up a poll-style message in the message list. Until
now, anyway, with this workaround.
A reference in a dartdoc to something called
`prepareMessageWithSubmessages` was dangling; it seemed to be
dangling when it first appeared, too, in 5af5c76; there's nothing
by that name.
We're about to add a test that renders a poll-style message, and we'd get this warning on that.
Greg points out that we'll need both values when restoring a failed message edit: originalRawContent for the eventual edit-message request (for prevContentSha256), and newContent to fill the edit-message compose box, so the user can restore the edit session to what it was before it failed.
In the upcoming edit-message feature, the edit-message compose box will have a "Preparing..." state after you tap "Edit message" in the action sheet, while we're fetching the raw message content. The edit-message compose box shouldn't be interactable in this state.
Otherwise, if several different test cases in this file fail due to checks failing inside checkInvariants, then only the first one gets reported in detail with the comparison and the stack trace.
…X span In CSS, the `em` unit is the font-size of the element, except when defining font-size itself (in which case it's the font-size inherited from the parent). See MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/length#em So when the same HTML span has a declared value for font-size, and also a declared value in units of `em` for some other property, the declared font-size needs to be applied in order to correctly interpret the meaning of `em` in the other property's value. It's possible this never comes up in practice -- that KaTeX never ends up giving us a span that gets both a font-size and a height. If it were hard to correctly handle this, we might try to verify that's the case and then rely on it (with an appropriate check to throw an error if that assumption failed). But the fix is easy, so just fix it.
This code had a switch/case on the Narrow type, so I discovered it while implementing keyword-search narrows. We support Zulip Server 7 and later (see README) and refuse to connect to older servers. Since we haven't been using this protocol for servers FL 155+, this is NFC. Related: zulip#992
Fixes zulip#1665. Currently instead of showing an audio player interface it just displays the audio `title` attribute text in a link pointing to the `src` URL.
Oops, forgot to do this at the time of making the release.
A couple of times I've forgotten the last step, post-release, of syncing the version and changelog to main. Hopefully documenting it in these instructions will help remind me.
Conceptually this should be a widget, but can't quite be, for the reasons explained in the comment. Still we can organize the code in nearly the same way as if it were a widget. Co-authored-by: Greg Price <[email protected]>
Done as preparation to implement a new Narrow subclass for keyword search. We can't really implement a client-side "contains-message" predicate for search; it's up to the server to decide whether a message matches the search query. A simple path to representing that, done here, is to just change Narrow.containsMessage's contract to say that it always returns null if the narrow is a search narrow. The app-code changes show just small behavior choices for a message-list page in a search narrow, which we'll implement soon: - Message events are ignored - Outbox messages never appear Various TODOs in tests; we'll handle all of those as part of adding the keyword-search Narrow subclass.
…ning Seeing that the tests were expecting a notifyListeners call already, we found that one is already done, in MessageStore.handleUpdateMessageEvent, so this is redundant. But because the new call is done synchronously with the existing call, it doesn't trigger any extra rebuilds, and it helps the reader by making it clear locally that listeners do indeed get notified.
We'll use this in keyword search, coming up, for renarrowing when the user submits a new keyword.
As suggested by Greg: zulip#1662 (comment)
…ions It looks like this comment was written for CombinedFeedNarrow and not updated when the other two cases were added. (Unlike with CombinedFeedNarrow, it's possible that some of `messageIds` weren't starred or mentioned in the first place, so it was inaccurate to say they "were" in the narrow.)
We already handle muted topics, but we still need to update the message list on muting/unmuting a channel, which is zulip#1255.
We plan to revert this when we do zulip#1663.
Fixes zulip#252. For timeliness, tests are left as a followup: zulip#1667
This condition is a bit complex already, and will become more so soon. So making it a method instead of an expression gives its logic a bit more room to breathe and spread out.
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
1f33c7b to
20b94c7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Automated changes by create-pull-request GitHub action