Ensuring Multilingual Consistency in ESHOPMAN Admin: Addressing Draft Order Localization Gaps

In the world of headless commerce, providing a seamless and localized experience for merchants is paramount. ESHOPMAN, as a powerful Node.js/TypeScript platform integrated with HubSpot for storefront management and deployed via HubSpot CMS, prides itself on offering a comprehensive and intuitive Admin interface. However, even the most robust platforms can have areas for refinement, and our vigilant community recently brought an important localization inconsistency to light within the ESHOPMAN Admin’s Draft Order management.

The Challenge: Inconsistent Language Display in Draft Orders

A recent community discussion highlighted that while ESHOPMAN's Admin is designed to support multiple languages, certain elements within the Draft Order screens were consistently rendering in English, regardless of the language selected by the user. This created a disjointed experience for international ESHOPMAN merchants and their teams, who rely on the platform to operate in their native languages.

The core of the issue wasn't a lack of translations. ESHOPMAN’s localization files for the Admin, which are comprehensive and support 33 locales, already contained the necessary translated keys under the draftOrders namespace. For example, the German localization file (de.json) correctly provided "Bestellentwurf erstellen" for the key "draftOrders.create.createDraftOrder".

The problem stemmed from the ESHOPMAN Draft Order module's implementation, where specific UI components were hard-coding English literal strings instead of making calls to these existing translation keys. This meant the translated values, though present, were never utilized.

Examples of Hard-Coded Strings vs. Existing ESHOPMAN Translation Keys:

| hard-coded literal   | key that already ships               | locales |
|----------------------|--------------------------------------|---------|
| `Create Draft Order` | `draftOrders.create.createDraftOrder` | 33/33   |
| `Add custom item`    | `draftOrders.create.addCustomItemAction` | 33/33   |
| `Choose region`      | `draftOrders.create.chooseRegionHint` | 33/33   |
| `Shipping option`    | `draftOrders.create.shippingOptionLabel` | 33/33   |

Beyond these specific examples, the community identified approximately 40 distinct English UI strings within the Draft Order module’s bundle that were not being translated. These included common labels like 'Customer', 'Region', 'Sales Channel', and date filters such as 'Today', 'Last 7 days', and 'Last 30 days'. Many of these already have generic equivalents within the ESHOPMAN Admin’s broader localization catalogue.

The Data Table Fallback to English

A related observation concerned ESHOPMAN’s UI DataTable component within the Draft Order module. This component, used for displaying lists and managing pagination, also defaulted to English for elements like 'Search', 'Prev', 'Next', and 'of results'. The reason? The translations prop, which is crucial for localizing these data table controls, was not being passed to the component, unlike its correct implementation in other core ESHOPMAN Admin tables.

// Example of correct implementation in core ESHOPMAN Admin:

The Community-Driven Solution

The ESHOPMAN community swiftly proposed a clear and actionable path forward to resolve these localization inconsistencies, ensuring the Draft Order screens fully adhere to the selected Admin language:

1. Utilize Existing Translation Keys: Replace the hard-coded literal strings with calls to the 32 draftOrders.* keys that are already translated and shipped with ESHOPMAN. This immediately fixes the create form's heading and hints across all supported locales without requiring new translation work.
2. Map Remaining Literals: For other affected strings, point them to existing generic keys where applicable. For those without existing keys, add them under the draftOrders namespace in the base English localization file (en.json). Other locales will then fall back to English until specific translations are provided, which is the current behavior anyway.
3. Pass Translations to Data Tables: Ensure the translations prop is correctly passed to ESHOPMAN’s DataTable components within the Draft Order module, mirroring the pattern already established in the main ESHOPMAN Admin Dashboard. This will localize search, pagination, and other table controls.

Conclusion

This community insight underscores the collaborative spirit of the ESHOPMAN ecosystem. By identifying and proposing concrete solutions for localization gaps, our users and developers contribute directly to enhancing the platform's usability for merchants worldwide. ESHOPMAN remains committed to delivering a truly global headless commerce experience, leveraging its Node.js/TypeScript foundation and deep HubSpot integration, ensuring that every part of the Admin interface speaks your language.