Update translations from Weblate #2
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]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
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
2 times, most recently
from
46a6f30 to
71d1fcf
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
71d1fcf to
40f3c4f
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
2 times, most recently
from
28e4431 to
14491db
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
2 times, most recently
from
279a12c to
b0805f1
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
b0805f1 to
7bb9c53
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
2 times, most recently
from
86b3f96 to
367a2bd
Compare
PIG208
force-pushed
the
main
branch
2 times, most recently
from
904062a to
9689dce
Compare
github-actions
bot
force-pushed
the
update-translations/weblate
branch
from
367a2bd to
290b7c0
Compare
This change should have no user-facing effect. The one spot where we have an `if (_disposed)` check in editMessage prevents a state update and a rebuild from happening. This only applies if the store is disposed before the edit request fails, but the MessageListView with the edited message should get rebuilt anyway (through onNewStore) when that happens.
While we do create outbox messages, there are in no way user-visible changes since the outbox messages don't end up in message list views. We create skeletons for helpers needed from message list view, but don't implement them yet, to make the diff smaller. For testing, similar to TypingNotifier.debugEnable, we add MessageStoreImpl.debugOutboxEnable for tests that do not intend to cover outbox messages.
This implements the waitPeriodExpired -> waiting state transition. GitHub discussion: zulip#1472 (comment)
For the topic-list page app bar, we leave out the icon "chevron_down.svg" since it's related to a new design (zulip#1039) we haven't implemented yet. This also why "TOPICS" is not aligned to the middle part of the app bar on the message-list page. We also leave out the new topic button and topic filtering, which are out-of-scope for zulip#1158. The topic-list implementation is quite similar to parts of inbox page and message-list page. Therefore, we structure the code to make it easy to maintain in the future. Especially, this helps us (a) when we're changing one, apply the same change to the other, where appropriate, and (b) later reconcile the differences they do have and then refactor to unify them. Figma design: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=6819-35869&m=dev The "TOPICS" icon on message-list page in a topic narrow is a UX change from the design. See CZO discussion: https://chat.zulip.org/#narrow/channel/48-mobile/topic/Flutter.20beta.3A.20missing.20topic.20list/near/2177505
The icon was taken from CZO discussion: https://chat.zulip.org/#narrow/channel/530-mobile-design/topic/Topic.20list.20in.20channel/near/2140324 Fixes: zulip#1158 Co-authored-by: Zixuan James Li <[email protected]>
This 11px whitespace can be traced back to 311d4d5 in 2022. While this is not present in the Figma design, it would be a good idea to refine it in the future. See discussion: zulip#1453 (comment)
[chris: expanded commit-message summary line] Co-authored-by: Chris Bobbe <[email protected]>
Normally, instead of doing it manually, we would add new languages from Weblate's UI. In this case, the ones added in this commit are not offered there. So we will commit this to GitHub first, and let Weblate pull the changes from there. The language identifier zh is left empty, and is set to be ignored on Weblate for translations. Translator will be expected translate strings for zh-Hans-CN and zh-Hant-TW instead. We can add more locales with the zh language code if users request them. See CZO discussion on how we picked these language identifiers: https://chat.zulip.org/#narrow/channel/58-translation/topic/zh_*.20in.20Weblate/near/2177452
The Figma: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=6089-28394&m=dev And while we're adding a test for it, also check that the chosen channel icon is the intended one.
…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
588a19a to
4da9f02
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