Fix frontend dashboard order translations

[the-sohan]

PR Type

What kind of change does this PR introduce?

• Bugfix
• Security fix
• Improvement
• New Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• Text changes
• Other... Please describe:

Description

The frontend Order History table can remain in English even when matching Directorist JavaScript translations are available. Its script does not register a translation domain, the Orders title is hardcoded, and several table strings are missing from the POT template. The shared DataViews empty message also uses the WordPress default domain instead of the plugin catalog.

Register the dashboard script translations, localize Orders, reuse the existing Order ID string, and add the missing catalog entries with built-JavaScript references so translation tools can generate the correct JSON catalog. After the order dashboard container is found, register an i18n.gettext_default fallback for an untranslated No results message. It reads the Directorist translation while preserving an existing WordPress translation and leaving other strings and domains unchanged. Rebuild the tracked dashboard bundle and asset manifest.

How to reproduce the issue or test the changes:

1. On a local WordPress site, activate Directorist and prepare a non-English Directorist PO/JSON catalog for the dashboard script, including Orders, Order ID, Status, Total Amount, Order Type, Payment Method, Order Date, Actions, and No results.
2. Open the frontend dashboard's Order History tab. Before the fix the script's translations are not loaded and Orders is hardcoded. With this change, verify the title and all seven column headings use the translations.
3. Search for a value that matches no orders. When WordPress has no default-domain translation for No results, verify the plugin translation is used. When WordPress does have one, verify it remains authoritative.
4. Switch back to English and verify the title, headings, and existing order rows still display normally. Confirm unrelated default-domain strings and other plugin domains are unaffected.

Local verification:

• Production Webpack build of the dashboard entry using the repository configuration succeeded.
• php -l includes/asset-loader/init.php and node --check assets/build/js/react/frontend/listing-owner-dashboard.js passed.
• git diff --check passed.
• Seven integration assertions using the actual WordPress hooks/i18n packages passed: no registration without the dashboard container, English fallback, omitted and explicit default domains, preservation of core translations, and isolation of unrelated strings/domains.
• Source-built bundle tested on directorist.local with an es_ES catalog: Pedidos, all seven translated columns, existing order rows, and Sin resultados verified. The earlier hotfix also passed the normal English-locale check; the user confirmed it resolved the reported issue.
• WP-CLI extraction verified the dashboard strings and their built-script references.

Notes:

• The build emitted non-fatal bundle-size warnings. Full PHPCS was not run because the worktree has no Composer-installed PHPCS binary.
• Locale-specific Spanish files from the downloadable customer hotfix are not included; this change supports catalogs for the site's selected locale, including es_MX.

Any linked issues

• Companion PR: https://github.com/sovware/directorist-pricing-plans-new/pull/129
• Help Scout: https://secure.helpscout.net/conversation/3404610740/5842?viewId=8936453
• Reported screenshot: https://prnt.sc/r7kTpKKQq5eZ

Checklist

• My code follows the WordPress coding standards