Thank you! This is good

I’ll try to find the old files, I was doing some cleanup and deleted before checking . I know this one `v20251209012613` was already failing. Will try to recover the older files to see when it stopped working.

Presuming it stopped working after an upgrade, do you know the version where it was working (knowing the filename of the last successful backup would help) and the version you’re at now?

duy: > Tried both. But I can’t found. You can try again now. My pull request to add the configuration for the translator bot was merged

Yes, it worked until ~mid-December.

In case you still have that problem or it happens again, it could help to check the network tab. I was able to find the error there when I had a similar error in the browser console: Make reason for 'error moving posts' visible in the interface >

Has this worked previously?

Recently, I struggled to move a post to a new topic. The modal only showed: > There was an error moving posts. Well, this time it was not that difficult; I hadn’t chosen a category. But, fun fact, it didn’t work when I added a category either. So I checked the browser console: That didn’t help me either, but finally, in the network tab, I found: This would have been really helpful to know without using a device where I have access to such tools. Is it possible to show the actual error message in the interface? Related off-topic question (click for more details)

We haven’t had the first-hand opportunity to debug, but others have come to this conclusion. It appears that the QQ mail server hangs up the connection prior to transmitting the acceptance of the message, so Discourse thinks it hasn’t been accepted when in reality it has.

Safari is the new IE github.com/discourse/discourse #### FIX: "Attach a file" unresponsive in chat on desktop Safari `main` ← `fix-safari-chat-upload` merged 03:59PM - 16 Jan 26 UTC ZogStriP +7 -3 The file picker wasn't opening when clicking "Attach a file" from the chat compo…ser dropdown menu on desktop Safari. Safari requires programmatic file input clicks to happen synchronously within the user gesture event chain. The previous code used `await closeFn()` before calling `button.action()`, which broke this chain by deferring execution to a new microtask. Safari no longer considered the subsequent `.click()` to be user-initiated. The fix removes the async/await to keep both calls synchronous within the original click handler. This issue cannot be caught by automated tests because our system specs use Chrome, which is more permissive with user activation (allowing a ~5 second window after user interaction). Safari's stricter requirements only manifest in that specific browser. References: - https://meta.discourse.org/t/393639 - https://webkit.org/blog/13862/the-user-activation-api/ - https://macwright.com/2022/07/11/activation.html

david: > Make sure you’re changing the correct string. This one is `js.footnote.add`. I think the footnote client.yml is not available on Crowdin, just like math was not. github.com/discourse/discourse #### translator.yml `f1275d2db` 86. 87. - source_path: plugins/footnote/config/locales/server.en.yml 88. destination_path: plugins/footnote/server.yml 89. label: footnote 90.

duy: > 1. Footnote > Make sure you’re changing the correct string. This one is `js.footnote.add`. There is a similar one under `discourse-ai`, but that’s used elsewhere. duy: > 2. Post Language button on editor > @keegan looks like we accidentally hardcoded this one? github.com/discourse/discourse #### frontend/discourse/app/components/post-language-selector.gjs `b8c8f2674` 44. @title="Post Language" duy: > 3. xxx posts were split to a new topic > 4. This topic was automatically closed > 5. Originally published at > These three are considered to be part of the post content. So the translation is only applied when the post (or ‘small action’) is created. duy: > 6. post.in_reply_to > Will be fixed by UX: Fix translation of post.in_reply_to by davidtaylorhq · Pull Request #37175 · discourse/discourse · GitHub. Thanks!

duy: > xxx posts were split to a new topic That is `move_posts.new_topic_moderator_post`. I can find that in Crowdin duy: > This topic was automatically closed This one is `topic_statuses.autoclosed_enabled_lastpost_days` I wonder if there is a problem with the plural versions

I did on the old server. Restoring I got the same error [2026-01-16 13:45:52] EXCEPTION: 3 posts are not remapped to new S3 upload URL. S3 migration failed for db ‘default’. [2026-01-16 13:45:52] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’

@david I think I’ve found some other strings that aren’t available for translation (or there are changed but they are not effective). 1. Footnote 2. Post Language button on editor 3. xxx posts were split to a new topic 4. This topic was automatically closed 5. Originally published at 6. post.in_reply_to

thaidb: > Is there a plan to eventually combine the standard search bar and Discourse AI into a single AI-driven chat interface? There’s not currently a plan, but we do have a number of search-related AI features… so it’s interesting to consider. Current tools include: * Personas like Forum Researcher, which can search using retrieval-augmented generation (RAG). This is from the AI Bot link to https://meta.discourse.org/discourse-ai/ai-bot/conversations and can also be used in Discourse chat. * AI embeddings semantic search, these are search results that appear on full-page /search * AI embeddings quick search, which is used to populate results in the search dropdown. This is especially useful for populating results in searches that would otherwise produce 0 results, like typos. * Discobot Discoveries, which is additional sidebar content to searches in both the dropdown and full page There are some tradeoffs with AI-first approaches, traditional search is still a good amount faster than RAG… but perhaps in cases like yours that’s ok and the search bar could be swapped out for an input that directly populates a query for the AI conversation page or a bot chat? Something like that would be possible to do from a theme component.

Did you do that on the original server? Or you need to do it after the database has restored before it does that check, using the --pause switch

I’m not sure I understand what you mean. Could you describe it in more detail or include a screenshot?

Thanks for this @justinm. I’ve merged the PR, and added a section to the docs: Discourse OpenID Connect (OIDC) > For identity providers which support secret-less authorization using the “Authorization Code Flow with Proof Key for Code Exchange”, PKCE should be enabled, and the `client_secret` configuration can be omitted.

I solved using local docker container hostname, thanks again for your help!

You really should set it up on a different server than discourse, at the bare minimum don’t use the docker bridge for uptime kuma or take discourse out of the bridge.

Thank you for this check I’m going to debug the problem on my side and I’ll let you know

FrancescoM: > Maybe something to set on Discourse? No, there is nothing to set up on discourse because problem is with your install of uptime kuma not discourse. I set up your site as a monitor on a fresh uptime kuma and it works.

I tried but it shows me the same error. I also set up a new monitor for a different website inside the same server, and it works perfectly. Maybe something to set on Discourse? Thanks again for your help

Change the monitor type to keyword first.