Description

The "Copy table to" form on the Table → Operations page submits its AJAX request silently — no visual feedback while the copy is in progress. Every comparable operation on the same page (Move table, Drop table, Truncate table, etc.) already shows a loading notification via Functions.ajaxShowMessage. The copy-table handler was the only one missing this call.

What this changes

1. resources/js/table/operations.ts — adds a single ajaxShowMessage(window.Messages.strCopyingTable, false) call inside the #copyTable.ajax submit handler, immediately before the $.post(...) invocation. The second argument false makes the notification persist (no auto-dismiss) until it is replaced by the success or error message that the existing response handlers display.

2. src/Controllers/JavaScriptMessagesController.php — adds the strCopyingTable message key ('strCopyingTable' => __('Copying table')) under a new /* For table/operations.js */ comment block, placed adjacent to the existing /* For database/operations.js */ block for discoverability.

The pattern mirrors the equivalent copy-database operation in resources/js/database/operations.ts, which uses ajaxShowMessage(window.Messages.strCopyingDatabase, false) immediately before its own $.post(...) call. No new UI pattern is introduced.

Behaviour after the fix

• Click "Go" on the Copy table form → a blue "Copying table" notification appears immediately.
• On success: the existing ajaxShowMessage(data.message) call replaces the loading notification with the server's success message.
• On error: the existing ajaxShowMessage(data.error, false) call replaces it with the error message.
• ajaxShowMessage removes any prior span.ajax_notification[id^=ajax_message_num] element before rendering the new one (see resources/js/modules/ajax-message.ts), so no notification stacking occurs.

How this was tested

Manual reproduction in a Docker dev environment against MariaDB:

1. Navigate to any table → Operations.
2. In the "Copy table to" card, enter a new table name and click Go.
3. Verify the blue "Copying table" notification appears immediately on click.
4. Verify the notification is replaced by the success message once the copy completes.
5. Verify the navigation tree refresh and the "Switch to copied table" behaviour are unchanged.

Static analysis: composer run phpstan and composer run psalm pass against the changed files. Existing PHPUnit and Selenium suites unaffected by the change.

No new automated test was added. The change is a one-line addition to an existing AJAX handler, mirroring an established precedent, and is exercised by the existing end-to-end coverage in tests/end-to-end/Table/OperationsTest.php. If a regression test is expected for this kind of change, please advise on the preferred location (PHPUnit unit, Jest, or Selenium) and I will add it.

Out of scope

• The moveTableForm submit handler on the same Operations page has the identical missing-spinner gap. This PR scopes to #copyTable only, per issue [Bug]: No load mask when copying table #19761. Happy to track the Move-table parity as a follow-up issue if that's preferred.
• resources/po/phpmyadmin.pot is not updated in this commit. The project regenerates the .pot via its CI/release tooling rather than per-PR, so "Copying table" will be picked up on the next regen cycle.

Fixes #19761.

Before submitting pull request, please review the following checklist:

• Make sure you have read our [CONTRIBUTING.md](https://github.com/phpmyadmin/phpmyadmin/blob/master/CONTRIBUTING.md) document.
• Make sure you are making a pull request against the correct branch. For example, for bug fixes in a released version use the corresponding QA branch and for new features use the master branch. If you have a doubt, you can ask as a comment in the bug report or on the mailing list.
• Every commit has proper Signed-off-by line as described in our [DCO](https://github.com/phpmyadmin/phpmyadmin/blob/master/DCO). This ensures that the work you're submitting is your own creation.
• Every commit has a descriptive commit message.
• Every commit is needed on its own, if you have just minor fixes to previous commits, you can squash them.
• Any new functionality is covered by tests. (See "How this was tested" — no new automated test added; happy to add one in the reviewer's preferred location.)