Update translations from Weblate #1279
Closed
Conversation
This file contains 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]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…mplete The fixes to RawAutocomplete's options width in the Flutter framework: flutter/flutter#143249 introduces a one-frame delay, so this test will need an extra pump to account for that.
This makes all the uses of _debugParserContext maximally simple, which will help us refactor it away.
Because this is used for parsing both inline and block nodes, moving it out will help us separate the rest of the parser code between the handling of inline content and block content.
This helps organize the parsing code a bit more cleanly -- not to mention more statically, by making the dynamic _debugParserContext assertions redundant.
This hopefully makes the logic of these loops a bit more readable.
We're about to group the others together under a new sibling of this class, so it'll be cleanest if this one doesn't appear in the midst of the others.
This expresses more directly what we really mean here: if the response had either the HTTP status code or the Zulip API error code that mean a rate-limit error, treat it as a rate-limit error.
The topic/subject field on DMs carries no information in the current API, and we already never actually look at it, as demonstrated by the lack of changes in the rest of the tree in this commit. Clean up the type definitions in the API a bit by making that explicit. This is NFC except in the case where a server were to not send this field at all for a DM (or to send a non-string value). In that case the old code would reject the server's response as malformed, and the new code after this commit would accept it because it doesn't look for the field.
The point in this autocomplete UI is to choose the entire new value for the topic input. So we can do that directly, without the more complicated logic that parallels what we need in the more complicated case of autocomplete in the content input. This is NFC as far as the text value of the input is concerned. I believe it's probably NFC entirely, because the remaining aspects of TextEditingValue -- the selection and the composing region -- are probably clobbered anyway by the next line's giving focus to the content input. (The new test already passes before this change.)
We'll use this to make a type-level distinction between a string that's being used to name a topic, and just any old string. That will help us in particular with #1250 the "general chat" feature, where the way we show a topic name to the user stops being necessarily just the same string that it appears as in the API. The next phase will be to migrate a bunch of places in our code to refer to TopicName when that's what they mean, instead of just String. During this phase, a TopicName can be freely used as a String, but not vice versa. So we'll do the migrations mostly in order of the data flow, from upstream to downstream. That will allow us to do them over a series of individually coherent commits, with a minimum of occasions where we temporarily introduce a conversion that won't be needed in the final result. That means: first, test data; then topics returned from the API to our code; then our internal models; then back to the API, this time for topics passed to the API from our code. After we have the type in place all over where it belongs, we'll start making use of the distinction, and then enforcing it.
These are being passed to test helpers which we'll leave as consuming String instead of TopicName, for convenience in other test cases. At these call sites the values were coming from fields that are or will become TopicName, though; so when that happens and we make TopicName no longer implicitly convertible to String, these will need to be explicitly String instead.
Fixed a bug in MessageListTheme.lerp() where dmRecipientHeaderBg was using streamMessageBgDefault instead of dmRecipientHeaderBg for interpolation.
I forgot to do this before today's v0.0.26, oops. The process is only semi-automated at this point (see #276). It was fresher in mind as of the last couple of releases, but I didn't think of it today. That's what a checklist is for; add it there.
Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
The string is used at the end of the "errorFilesTooLarge" message, which includes a list of files with its size that are too large. Signed-off-by: Zixuan James Li <[email protected]>
The message, when used in lib/widgets/compose_box.dart, substitutes `listMessage` with newline separated lines of filenames with size. Update the example to match this usage. Signed-off-by: Zixuan James Li <[email protected]>
to match the labels for the other fields (loginEmailLabel, loginPasswordLabel, etc.) This also updates existing translations in other languages to match. Signed-off-by: Zixuan James Li <[email protected]>
This avoids a potential race if the queried account is logged out between the invocation of this Builder callback and `MaterialApp.onGenerateInitialRoutes` (if such a race is possible).
And remove the use of Builder widget, which is unncessary after this refactor.
…ground Previously, when two accounts (Account-1 and Account-2) were logged in, the app always defaulted to showing the home page of Account-1 on launch. If the app was closed and the user opened a notification from Account-2, the navigation stack would be: HomePage(Account-1) -> MessageListPage(Account-2) This commit fixes that behaviour, now when a notification is opened while the app is closed, the home page will correspond to the account associated with the notification's conversation. This addresses #1210 for background notifications.
This fixes a potential bug, in case the server returned `realm_url` contains a trailing `/`.
I ran into this today when I tried running the Linux app. (It looks like the reason I hadn't seen it before is that until recently I had this package installed; it was installed "automatically", i.e. only because it was a dependency of something else, and then I upgraded my machine, it was no longer such a dependency, and got autoremoved. Now that I've installed it directly, it'll stay.)
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
1d917f6 to
1b50708
Compare
alexmv
force-pushed
the
action-rights-generated
branch
from
7dff110 to
bf74d0d
Compare
gnprice
force-pushed
the
action-rights-generated
branch
from
bf74d0d to
6bbe74f
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