chore(dashboard): Add error messages to update draft mutations#4381
Open
LucidityDesign wants to merge 1 commit intovendurehq:masterfrom
Open
chore(dashboard): Add error messages to update draft mutations#4381LucidityDesign wants to merge 1 commit intovendurehq:masterfrom
LucidityDesign wants to merge 1 commit intovendurehq:masterfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📝 WalkthroughWalkthroughAdds onError handlers to draft-order related useMutation calls in the authenticated orders draft page to surface toast error messages on failures. Updates many locale PO files: rebinds source-location references, adds new msgids (including multiple "Failed to ..." draft/order error messages and a "Discounts" key), and removes previously populated entries from packages/dashboard/missing-translations.txt, leaving only headers/placeholders. Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Member
|
Hi, Also, please run |
LucidityDesign
force-pushed
the
feat/display-errors
branch
from
6d9a8bb to
48c53ae
Compare
LucidityDesign
force-pushed
the
feat/display-errors
branch
from
48c53ae to
b56e188
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 18
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/dashboard/src/i18n/locales/cs.po (1)
1-14:⚠️ Potential issue | 🟡 Minor
POT-Creation-Dateis one year behind the PR date.The header reads
POT-Creation-Date: 2025-02-20while the PR was opened on 2026-02-19. Ifnpm run i18n:extractwas freshly run (as requested by the maintainer), this date should reflect the current run. Check that the extraction was executed from the correct directory (/packages/dashboard) and that the tooling is stamping the date correctly.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/dashboard/src/i18n/locales/cs.po` around lines 1 - 14, The POT-Creation-Date header in packages/dashboard/src/i18n/locales/cs.po is stale; re-run the extraction from the dashboard package (cd into /packages/dashboard and run npm run i18n:extract) so the lingui/cli stamps the current date into the msgid header (POT-Creation-Date). If the header still doesn't update, confirm the extraction script invoked (e.g., the npm script that calls `@lingui/cli`) and fix its working-directory or invocation so that create/update of locales/cs.po uses the correct timestamp, then commit the regenerated cs.po with the updated POT-Creation-Date.
🧹 Nitpick comments (2)
packages/dashboard/missing-translations.txt (1)
1-378: Removemissing-translations.txtonce translations are appliedThis file is a useful artifact for requesting translations but should not remain committed indefinitely. Once the translated strings are backfilled into the respective
.pofiles, this file should be deleted to avoid it becoming stale documentation.All locale files for the 22 languages in this file exist in the locales directory, including
sv.po.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/dashboard/missing-translations.txt` around lines 1 - 378, The file missing-translations.txt is an artifact that must be removed once its strings have been backfilled into the locale .po files; update the translation files for all listed locales (including sv.po) in the locales directory with the provided msgids, and then delete missing-translations.txt from the commit to prevent stale documentation lingering in the repo.packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx (1)
118-122:addItemToDraftOrder.onErrorsilently swallows non-ENTITY_NOT_FOUNDerrors — inconsistent with this PR's new pattern.All mutations added in this PR now show a toast for any error, but the pre-existing
addItemToDraftOrder.onErroronly handlesENTITY_NOT_FOUND. Network errors, permission errors, or any other failure during item addition will produce no user feedback.♻️ Suggested fix for consistency
onError: error => { if ((error as any).extensions?.code === 'ENTITY_NOT_FOUND') { toast.error(t`The variant could not be added. Ensure the parent product is enabled.`); + } else { + toast.error(t`Failed to add item to order: ${error.message}`); } },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft`.$id.tsx around lines 118 - 122, The onError handler for addItemToDraftOrder only handles ENTITY_NOT_FOUND and silently ignores all other errors; update addItemToDraftOrder.onError to always show a toast for any error: keep the specific branch that checks (error as any).extensions?.code === 'ENTITY_NOT_FOUND' and its product-disabled message, but add a fallback toast.error(...) that displays a generic failure message (optionally including error.message) for network/permission/other errors so every failure surfaces to the user.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/dashboard/src/i18n/locales/ar.po`:
- Around line 1830-1833: Several new localization entries (including msgid
"Discounts" and the 13 draft-order error msgids that use the "{0}" placeholder)
have empty msgstr values causing Arabic users to see English fallbacks; open the
Arabic .po file and for each listed msgid (e.g., "Discounts" and the draft-order
error messages) provide the correct Arabic translations in the corresponding
msgstr fields, ensuring you preserve the "{0}" placeholder exactly and keep
pluralization/formatting consistent with existing translated entries.
In `@packages/dashboard/src/i18n/locales/bg.po`:
- Around line 1838-1840: Several new msgid entries (including "Discounts" and 13
related error messages) currently have empty msgstr values; please populate each
corresponding msgstr with the correct Bulgarian translation for those msgid
strings (e.g., fill msgstr for "Discounts" and for each extracted error
message), preserving any placeholders/variables and plural forms exactly as in
the msgid entries, and then re-run your Lingui build/check to ensure the
translations compile cleanly.
In `@packages/dashboard/src/i18n/locales/cs.po`:
- Around line 1830-1833: Several msgstr entries in
packages/dashboard/src/i18n/locales/cs.po are empty (e.g., the entry with msgid
"Discounts" from
src/app/routes/_authenticated/_orders/components/order-table.tsx) so fill each
empty msgstr with the correct Czech translation for the corresponding msgid;
update all 14 empty entries (also those around the ranges mentioned: 2118-2122,
2253-2257, 2301-2305, 2314-2318, 2335-2359, 2374-2383, 2445-2454) by locating
the same msgid strings in cs.po and replacing msgstr "" with the translated
Czech text, preserving any markup/placeholders and plural forms, then save the
file and re-run the i18n extraction/lint step in your build to ensure no
formatting errors.
In `@packages/dashboard/src/i18n/locales/de.po`:
- Around line 1830-1833: The German translation for the user-visible label msgid
"Discounts" is missing; update the msgstr for that entry in the de.po file (the
msgid used in src/app/routes/_authenticated/_orders/components/order-table.tsx)
to the plural German "Rabatte" so the UI shows the correct localized label.
In `@packages/dashboard/src/i18n/locales/en.po`:
- Around line 2118-2121: Add a generic error string "Failed to add item to
order: {0}" to the en.po entries and update the addItemToDraftOrder mutation's
onError handler to use that generic message for non-ENTITY_NOT_FOUND failures;
specifically add the msgid/msgstr pair to
packages/dashboard/src/i18n/locales/en.po and change the onError branch in the
addItemToDraftOrder onError callback (the mutation handler that currently shows
"The variant could not be added..." for product-disabled errors) to call the
generic "Failed to add item to order: {0}" message when the error is not
ENTITY_NOT_FOUND so network/GraphQL errors display consistently with
adjustDraftOrderLine, setCustomerForDraftOrder, and
setShippingAddressForDraftOrder.
In `@packages/dashboard/src/i18n/locales/es.po`:
- Around line 2118-2121: Several newly extracted error message entries (e.g.,
msgid "Failed to complete draft order: {0}") have empty msgstr values causing
Spanish users to see English fallbacks; update each of the 13 new keys by
providing accurate Spanish translations in the corresponding msgstr fields
(preserve placeholders like {0}), including the example "Failed to complete
draft order: {0}" and the other entries referenced in the review (ensure
grammatical correctness and placeholder placement), then run your i18n
extraction/validation step to confirm no empty msgstr remain.
In `@packages/dashboard/src/i18n/locales/fa.po`:
- Around line 1830-1832: The Persian locale file fa.po contains 14 new
untranslated keys (e.g., msgid "Discounts" and multiple error messages like
"Failed to …: {0}") with empty msgstr entries; update each msgstr for these
msgids in packages/dashboard/src/i18n/locales/fa.po by providing the correct
Persian translations (preserving the {0} placeholder exactly), ensuring the
translated strings are inserted in the same entries that reference
src/app/routes/_authenticated/_orders/components/order-table.tsx and the related
error messages, and if you cannot translate now, add a follow-up issue to track
assigning these keys to the Persian locale maintainer.
In `@packages/dashboard/src/i18n/locales/fr.po`:
- Around line 1830-1832: Several new French translations in fr.po are empty
(e.g., msgid "Discounts" and 13 other newly extracted msgids), causing fallback
to English; open the fr.po entries for each new msgid (including "Discounts")
and replace the empty msgstr "" with accurate French translations for all 14 new
strings, ensuring proper accents and punctuation, then run the i18n
validation/extraction (npm run i18n:extract / lint step) to confirm all msgstr
are populated; verify the same updates are applied for the other ranges noted
(around the listed msgid groups).
In `@packages/dashboard/src/i18n/locales/he.po`:
- Around line 1830-1832: The new Hebrew locale entries are untranslated (msgstr
empty) so users see English; update the .po file entries (e.g., msgid
"Discounts" and all "Failed to …: {0}" msgid entries referenced in this diff) by
providing appropriate Hebrew msgstr values, reusing the existing "Discount"
translation as a template for "Discounts" and adding Hebrew translations for
each error-toast msgid; if you can't translate all immediately, add a tracking
TODO comment or issue reference in the repository and mark untranslated entries
with a clear placeholder (e.g., "TRANSLATION_PENDING") so they are identifiable
for later translation work.
In `@packages/dashboard/src/i18n/locales/hr.po`:
- Around line 1830-1832: The listed msgid entries (e.g., "Discounts" and each
"Failed to …: {0}" such as "Failed to complete draft order: {0}", "Failed to
delete draft order: {0}", etc.) in the Croatian PO file have empty msgstr
values; update hr.po by providing correct Croatian translations for each of
those msgid strings, preserving the {0} placeholder exactly, and ensure all
other identical untranslated entries are also filled (or annotate them for
follow-up if a translator is needed) so the UI uses Croatian instead of falling
back to English.
In `@packages/dashboard/src/i18n/locales/it.po`:
- Around line 1830-1833: Several new msgid entries (all 14 untranslated keys,
e.g., "Discounts" from the shown diff) have empty msgstr values; update each
corresponding msgstr to the appropriate Italian translation following the
project's existing "Impossibile …" convention so runtime fallbacks do not show
English. Locate the untranslated msgid entries in the locale file (the ones
shown and the other groups mentioned) and replace each empty msgstr with the
suggested Italian text, ensuring exact msgid keys remain unchanged and keeping
punctuation/capitalization consistent with surrounding translations.
In `@packages/dashboard/src/i18n/locales/ja.po`:
- Around line 1830-1832: The new Japanese locale entries (e.g., the msgid
"Discounts" in packages/dashboard/src/i18n/locales/ja.po and the group of
"Failed to ..." msgid entries listed in the comment) currently have empty msgstr
values; populate each corresponding msgstr with the correct Japanese translation
(or add approved translations into missing-translations.txt) and commit the
updated ja.po (or updated missing-translations.txt) so Lingui no longer falls
back to English for those keys before merging the PR.
In `@packages/dashboard/src/i18n/locales/nb.po`:
- Around line 1830-1832: The nb.po file contains 14 new msgid entries (e.g.,
"Discounts" referenced from order-table.tsx) with empty msgstr values, so
Norwegian Bokmål users will see English fallbacks; either provide Norwegian
Bokmål translations for each new msgid in
packages/dashboard/src/i18n/locales/nb.po (fill the corresponding msgstr "" for
all listed msgids such as the error strings added around order-table.tsx and the
other referenced ranges) or explicitly note in the PR description that NB
translations are deferred to community contributors so reviewers know this was
intentional. Ensure each msgid has an appropriate msgstr translation matching
existing phrasing patterns (see similar success-message translations like
"Billing address set for order" -> "Fakturaadresse satt for bestilling") before
merging.
In `@packages/dashboard/src/i18n/locales/ne.po`:
- Around line 1830-1832: Several new translation entries (e.g., msgid
"Discounts" and the 14 draft-order error toast keys) in the Nepali PO file have
empty msgstr values; populate each msgstr with the correct Nepali translation
for the corresponding msgid (all entries referenced in the review: the
"Discounts" label and the listed draft-order error toasts) so Nepali users see
localized text, or if translations are not yet available add/update the PO
header fields (Last-Translator and Language-Team) and mark these strings as TODO
for the Nepali translator to complete; locate the entries by searching for msgid
"Discounts" and the draft-order error toast msgids in the ne.po file and update
their msgstr values accordingly.
In `@packages/dashboard/src/i18n/locales/pl.po`:
- Around line 1830-1833: Open packages/dashboard/src/i18n/locales/pl.po and
replace the empty msgstr "" entries for the listed msgid keys (e.g. "Discounts",
"Failed to complete draft order: {0}", "Failed to delete draft order: {0}",
"Failed to remove coupon code from order: {0}", "Failed to remove order line:
{0}", "Failed to set billing address for order: {0}", "Failed to set coupon code
for order: {0}", "Failed to set customer for order: {0}", "Failed to set
shipping address for order: {0}", "Failed to set shipping method for order:
{0}", "Failed to unset billing address for order: {0}", "Failed to unset
shipping address for order: {0}", "Failed to update order custom fields: {0}",
"Failed to update order line: {0}") with appropriate Polish translations,
ensuring placeholders like {0} are preserved exactly; save the file so Lingui
will use the translated msgstr values instead of falling back to msgid at
runtime.
In `@packages/dashboard/src/i18n/locales/pt_BR.po`:
- Around line 1830-1832: The pt_BR locale file has 14 untranslated msgid entries
(including "Discounts" and a set of "Failed to ..." error messages) which fall
back to English at runtime; update the corresponding msgstr values for the
msgids listed (e.g., "Discounts" -> "Descontos", "Failed to complete draft
order: {0}" -> "Falha ao concluir pedido rascunho: {0}", "Failed to delete draft
order: {0}" -> "Falha ao excluir pedido rascunho: {0}", and similarly apply the
pattern "Falha ao <infinitive> <object>" to each remaining error msgids such as
"Failed to remove coupon code from order: {0}", "Failed to remove order line:
{0}", "Failed to set billing address for order: {0}", "Failed to set coupon code
for order: {0}", "Failed to set customer for order: {0}", "Failed to set
shipping address for order: {0}", "Failed to set shipping method for order:
{0}", "Failed to unset billing address for order: {0}", "Failed to unset
shipping address for order: {0}", "Failed to update order custom fields: {0}",
and "Failed to update order line: {0}"); apply the same updates to the other
occurrences noted (lines ranges referenced in the review) and request a native
Portuguese reviewer to verify the translations before merging.
In `@packages/dashboard/src/i18n/locales/pt_PT.po`:
- Around line 1830-1833: The pt_PT locale file has 14 new msgid entries (e.g.,
"Discounts", "Failed to complete draft order: {0}", "Failed to delete draft
order: {0}" and the other draft-order mutation error keys) with empty msgstr
values causing fallback to English; open
packages/dashboard/src/i18n/locales/pt_PT.po, locate the msgid entries
referenced (for example in
src/app/routes/_authenticated/_orders/components/order-table.tsx and the
draft-order mutation keys) and add appropriate Portuguese (Portugal)
translations for each msgid so msgstr is populated, or if translations aren’t
available yet, add a TODO comment and create an issue to track translating these
14 strings so pt_PT no longer falls back to English.
In `@packages/dashboard/src/i18n/locales/ru.po`:
- Around line 1830-1833: The Russian locale file
packages/dashboard/src/i18n/locales/ru.po contains 14 untranslated msgid entries
(e.g., "Discounts", "Failed to complete draft order: {0}", "Failed to delete
draft order: {0}", etc.) which fall back to English at runtime; open ru.po and
supply appropriate Russian translations for each listed msgid (preserving
placeholders like {0}) so the strings are translated for users, then run the
i18n build/extract workflow to verify the entries are picked up.
---
Outside diff comments:
In `@packages/dashboard/src/i18n/locales/cs.po`:
- Around line 1-14: The POT-Creation-Date header in
packages/dashboard/src/i18n/locales/cs.po is stale; re-run the extraction from
the dashboard package (cd into /packages/dashboard and run npm run i18n:extract)
so the lingui/cli stamps the current date into the msgid header
(POT-Creation-Date). If the header still doesn't update, confirm the extraction
script invoked (e.g., the npm script that calls `@lingui/cli`) and fix its
working-directory or invocation so that create/update of locales/cs.po uses the
correct timestamp, then commit the regenerated cs.po with the updated
POT-Creation-Date.
---
Nitpick comments:
In `@packages/dashboard/missing-translations.txt`:
- Around line 1-378: The file missing-translations.txt is an artifact that must
be removed once its strings have been backfilled into the locale .po files;
update the translation files for all listed locales (including sv.po) in the
locales directory with the provided msgids, and then delete
missing-translations.txt from the commit to prevent stale documentation
lingering in the repo.
In
`@packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft`.$id.tsx:
- Around line 118-122: The onError handler for addItemToDraftOrder only handles
ENTITY_NOT_FOUND and silently ignores all other errors; update
addItemToDraftOrder.onError to always show a toast for any error: keep the
specific branch that checks (error as any).extensions?.code ===
'ENTITY_NOT_FOUND' and its product-disabled message, but add a fallback
toast.error(...) that displays a generic failure message (optionally including
error.message) for network/permission/other errors so every failure surfaces to
the user.
Comment on lines
+2118
to
+2121
| #. placeholder {0}: error.message | ||
| #: src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx:302 | ||
| msgid "Failed to complete draft order: {0}" | ||
| msgstr "Failed to complete draft order: {0}" |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
fd "orders_.*draft.*\$id\.tsx" --type fRepository: vendurehq/vendure
Length of output: 43
🏁 Script executed:
find . -type f -name "*orders*draft*" -o -name "*draft*order*" | head -20Repository: vendurehq/vendure
Length of output: 1285
🏁 Script executed:
wc -l ./packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsxRepository: vendurehq/vendure
Length of output: 169
🏁 Script executed:
wc -l 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx'Repository: vendurehq/vendure
Length of output: 143
🏁 Script executed:
sed -n '100,130p' 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx' | cat -nRepository: vendurehq/vendure
Length of output: 1586
🏁 Script executed:
sed -n '100,130p' 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx'Repository: vendurehq/vendure
Length of output: 1369
🏁 Script executed:
grep -n "Item added to order\|Failed to add\|variant could not be added" 'packages/dashboard/src/i18n/locales/en.po'Repository: vendurehq/vendure
Length of output: 600
🏁 Script executed:
sed -n '26,60p' 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx' | cat -nRepository: vendurehq/vendure
Length of output: 1718
🏁 Script executed:
rg "Failed to add.*item|add.*item.*order" 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx' -iRepository: vendurehq/vendure
Length of output: 395
🏁 Script executed:
sed -n '26,200p' 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx' | grep -A 15 "onError"Repository: vendurehq/vendure
Length of output: 3424
🏁 Script executed:
sed -n '2250,2260p; 2298,2308p; 2311,2321p; 2332,2365p; 2371,2385p; 2442,2455p' 'packages/dashboard/src/i18n/locales/en.po' | cat -nRepository: vendurehq/vendure
Length of output: 4586
🏁 Script executed:
sed -n '130,170p' 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx' | grep -B 5 -A 5 "adjustDraftOrderLine"Repository: vendurehq/vendure
Length of output: 43
🏁 Script executed:
sed -n '105,125p' 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx'Repository: vendurehq/vendure
Length of output: 870
🏁 Script executed:
rg "Failed to update order line|Failed to set customer|Failed to set shipping address" 'packages/dashboard/src/i18n/locales/en.po' -A 1Repository: vendurehq/vendure
Length of output: 354
🏁 Script executed:
sed -n '104,125p' 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx' | cat -nRepository: vendurehq/vendure
Length of output: 1082
🏁 Script executed:
rg "onError.*error.*=>.*toast" 'packages/dashboard/src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx' -B 5 -A 2Repository: vendurehq/vendure
Length of output: 43
Add missing generic error string for the addItemToDraftOrder mutation's onError handler.
The mutation has a success string ("Item added to order") and a specific error string for product-disabled cases ("The variant could not be added. Ensure the parent product is enabled."), but lacks a generic handler for network or GraphQL failures. All other mutations in this file (e.g., adjustDraftOrderLine, setCustomerForDraftOrder, setShippingAddressForDraftOrder) follow the pattern of including a generic error string like "Failed to [action]: {0}" for unspecified errors. Consider adding "Failed to add item to order: {0}" to the PO file and updating the onError handler to display it for non-ENTITY_NOT_FOUND errors, consistent with the rest of the codebase.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/dashboard/src/i18n/locales/en.po` around lines 2118 - 2121, Add a
generic error string "Failed to add item to order: {0}" to the en.po entries and
update the addItemToDraftOrder mutation's onError handler to use that generic
message for non-ENTITY_NOT_FOUND failures; specifically add the msgid/msgstr
pair to packages/dashboard/src/i18n/locales/en.po and change the onError branch
in the addItemToDraftOrder onError callback (the mutation handler that currently
shows "The variant could not be added..." for product-disabled errors) to call
the generic "Failed to add item to order: {0}" message when the error is not
ENTITY_NOT_FOUND so network/GraphQL errors display consistently with
adjustDraftOrderLine, setCustomerForDraftOrder, and
setShippingAddressForDraftOrder.
LucidityDesign
force-pushed
the
feat/display-errors
branch
from
b56e188 to
9493ef3
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
packages/dashboard/src/i18n/locales/es.po (1)
1309-1311: Minor terminology inconsistency between the two "unset address" success messages.
Billing address unset for orderuses "eliminada" whileShipping address unset for orderuses "removida" — two different verbs for the same action. The corresponding error messages (Failed to unset billing/shipping address for order) both consistently use "eliminar", so aligning the success messages would improve uniformity.✏️ Suggested fix
-msgstr "Dirección de envío removida del pedido" +msgstr "Dirección de envío eliminada del pedido"Also applies to: 1407-1409
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/dashboard/src/i18n/locales/es.po` around lines 1309 - 1311, Update the Spanish translation for the "Billing address unset for order" msgid so it uses the same verb as the shipping success message for consistency: change the msgstr currently "Dirección de facturación eliminada del pedido" to use "removida" (matching the "Shipping address unset for order" translation and the error messages that use "eliminar"); locate the entry by the msgid "Billing address unset for order" in the es.po file (reference src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx) and make the msgstr wording consistent across both billing and shipping success messages (also apply the same change at the duplicate occurrence around lines referenced by the reviewer).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/dashboard/src/i18n/locales/ar.po`:
- Around line 2314-2317: The Arabic translations for the failure messages use
"سطر" while the success messages use "بند", causing inconsistency; update the
msgstr for the msgid "Failed to remove order line: {0}" and for "Failed to
update order line: {0}" to use "بند" (matching the existing "Order line removed"
and "Order line updated" translations), and apply the same replacement for the
other duplicated occurrences of these failure messages noted in the PR.
In `@packages/dashboard/src/i18n/locales/bg.po`:
- Around line 1307-1313: Update the Bulgarian msgstrs for the "unset" success
messages in packages/dashboard/src/i18n/locales/bg.po so they read as
completed-action confirmations rather than present-state descriptions: replace
the msgstr for msgid "Billing address unset for order" with "Адресът за
фактуриране е премахнат от поръчката" and likewise replace the msgstr for msgid
"Shipping address unset for order" with "Адресът за доставка е премахнат от
поръчката" to match the action-oriented phrasing used by the error messages.
In `@packages/dashboard/src/i18n/locales/nb.po`:
- Around line 2118-2121: The Norwegian translations in locales/nb.po use
inconsistent domain terms in error messages; update the msgstr for the affected
msgid entries (e.g., msgid "Failed to complete draft order: {0}") and the other
listed error msgid blocks (lines referenced in the comment: 2253-2256,
2301-2304, 2314-2317, 2335-2338, 2374-2377, 2379-2382, 2450-2453) to match the
established vocabulary used by success messages: replace "ordre" with
"bestilling", "faktureringsadresse" with "Fakturaadresse", and "ordrelinje" with
"Bestillingslinje" so all error translations use the same domain terms (search
for the specific msgid strings like "Failed to complete draft order: {0}" to
locate each entry).
In `@packages/dashboard/src/i18n/locales/pt_BR.po`:
- Around line 2118-2121: Update the Portuguese translations to match existing
terminology: replace occurrences of "o rascunho do pedido" with the established
"Pedido rascunho" and change "item do pedido" to "Linha de pedido"/"Linhas de
pedido" as used elsewhere; specifically update the msgstr for msgid "Failed to
complete draft order: {0}" and the msgstrs for the error strings like "Failed to
remove order line: {0}" (and the related entries referenced in the review) so
they use the consistent terms "Pedido rascunho" and "Linha de pedido"/"Linhas de
pedido" to align with the rest of the file.
In `@packages/dashboard/src/i18n/locales/pt_PT.po`:
- Around line 2350-2353: The Portuguese translations for the error messages use
"endereço de entrega" while the rest of the file uses "envio"; update the msgstr
for the msgid "Failed to set shipping address for order: {0}" (and the analogous
msgid "Failed to unset shipping address for order: {0}") to replace "entrega"
with "envio" so they match existing strings like "Endereço de envio" and "Morada
de envio".
---
Duplicate comments:
In `@packages/dashboard/src/i18n/locales/en.po`:
- Around line 2118-2121: Add a generic error msgid entry for the
addItemToDraftOrder mutation and wire it into the mutation's onError toast: add
the string "Failed to add item to order: {0}" to
packages/dashboard/src/i18n/locales/en.po (matching the format used by other
draft-order errors) and ensure the addItemToDraftOrder onError handler in
src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx uses that message
when the error is not an ENTITY_NOT_FOUND (i.e., fallback to the generic "Failed
to add item to order: {0}" with the error.message interpolated in the toast).
In `@packages/dashboard/src/i18n/locales/es.po`:
- Around line 2118-2121: The Spanish translations for the new msgids (e.g.,
"Failed to complete draft order: {0}" in
src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx and the new
"Discounts" label) were populated but please verify all duplicated ranges
(2253-2256, 2301-2304, 2314-2317, 2335-2382, 2445-2453, 1830-1832) have
equivalent non-empty msgstr values and that the placeholder "{0}" is preserved
exactly in each entry; if any are missing or the placeholder was altered, update
the corresponding msgstr to a natural Spanish translation matching the existing
terminology and restore the exact "{0}" placeholder.
In `@packages/dashboard/src/i18n/locales/fa.po`:
- Around line 1830-2453: The new translation entries are correct — ensure the
added msgids ("Discounts" and the fourteen "Failed to …: {0}" error messages)
keep their msgstr non-empty and preserve the {0} placeholder exactly as in the
diff (e.g., msgid "Discounts" -> msgstr "تخفیفها" and msgid "Failed to complete
draft order: {0}" -> msgstr "تکمیل پیشنویس سفارش ناموفق بود: {0}"), then mark
the i18n changes as approved; no code modifications are required beyond keeping
these exact msgid/msgstr pairs.
In `@packages/dashboard/src/i18n/locales/hr.po`:
- Around line 1830-1832: Confirm that each new msgid (e.g., "Discounts") in the
Croatian .po entries has a non-empty msgstr and that the placeholder "{0}" is
preserved verbatim; if any are missing or altered, populate the msgstrs to match
and restore exact placeholders, then run the i18n validation/test script to
ensure no fallback-to-English occurs and commit the updated .po entries.
In `@packages/dashboard/src/i18n/locales/pl.po`:
- Around line 2118-2122: Translations for the new draft-order error entries are
correct so no code changes are needed; leave the entries in
packages/dashboard/src/i18n/locales/pl.po (e.g., the msgid "Failed to complete
draft order: {0}" with its msgstr "Nie udało się ukończyć zamówienia roboczego:
{0}") as-is and proceed to approve/merge the changes.
In `@packages/dashboard/src/i18n/locales/pt_PT.po`:
- Around line 1830-1832: The po entry for msgid "Discounts" in
packages/dashboard/src/i18n/locales/pt_PT.po was previously empty; update and
keep msgstr set to "Descontos" (matching the usage in
src/app/routes/_authenticated/_orders/components/order-table.tsx) so the
European Portuguese translation is present and correct.
---
Nitpick comments:
In `@packages/dashboard/src/i18n/locales/es.po`:
- Around line 1309-1311: Update the Spanish translation for the "Billing address
unset for order" msgid so it uses the same verb as the shipping success message
for consistency: change the msgstr currently "Dirección de facturación eliminada
del pedido" to use "removida" (matching the "Shipping address unset for order"
translation and the error messages that use "eliminar"); locate the entry by the
msgid "Billing address unset for order" in the es.po file (reference
src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx) and make the msgstr
wording consistent across both billing and shipping success messages (also apply
the same change at the duplicate occurrence around lines referenced by the
reviewer).
Comment on lines
+2314
to
+2317
| #. placeholder {0}: error.message | ||
| #: src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx:159 | ||
| msgid "Failed to remove order line: {0}" | ||
| msgstr "فشل إزالة سطر الطلب: {0}" |
Contributor
There was a problem hiding this comment.
Inconsistent Arabic term for "order line" across success and error messages.
The existing success translations use "بند" (clause/item) for "order line":
"Order line removed"→"تمت إزالة بند الطلب"(line 3549)"Order line updated"→"تم تحديث بند الطلب"(line 3553)
But the two new failure translations introduced in this PR use "سطر" (row/text line) for the same concept:
"Failed to remove order line: {0}"→"فشل إزالة سطر الطلب: {0}""Failed to update order line: {0}"→"فشل تحديث سطر الطلب: {0}"
"بند" is the more semantically appropriate term for an order line item in Arabic e-commerce context, and consistency with the success messages is important to avoid confusing Arabic-speaking admins.
🛠️ Proposed fix to align terminology
-msgstr "فشل إزالة سطر الطلب: {0}"
+msgstr "فشل إزالة بند الطلب: {0}"-msgstr "فشل تحديث سطر الطلب: {0}"
+msgstr "فشل تحديث بند الطلب: {0}"Also applies to: 2450-2453
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/dashboard/src/i18n/locales/ar.po` around lines 2314 - 2317, The
Arabic translations for the failure messages use "سطر" while the success
messages use "بند", causing inconsistency; update the msgstr for the msgid
"Failed to remove order line: {0}" and for "Failed to update order line: {0}" to
use "بند" (matching the existing "Order line removed" and "Order line updated"
translations), and apply the same replacement for the other duplicated
occurrences of these failure messages noted in the PR.
Comment on lines
+1307
to
1313
| #: src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx:205 | ||
| msgid "Billing address set for order" | ||
| msgstr "Адресът за фактуриране е зададен за поръчка" | ||
|
|
||
| #: src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx:206 | ||
| #: src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx:227 | ||
| msgid "Billing address unset for order" | ||
| msgstr "Адресът за фактуриране не е зададен за поръчка" |
Contributor
There was a problem hiding this comment.
Minor semantic inconsistency in "unset" success messages (pre-existing).
The success messages for clearing addresses:
"Billing address unset for order"→"Адресът за фактуриране не е зadadен за поръчка"("…is not set for order" — state)"Shipping address unset for order"→"Адресът за доставка не е зadadен за поръчка"(same pattern, line 4429)
…read as a present-state description rather than a completed-action confirmation. By contrast, the corresponding error messages at lines 2382–2390 correctly use "премахване" (removal action). A more idiomatic success phrasing would be "Адресът за фактуриране е премахнат от поръчката" / "Адресът за доставка е премахнат от поръчката". This is pre-existing and not introduced by this PR, but worth noting for a future translation pass.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/dashboard/src/i18n/locales/bg.po` around lines 1307 - 1313, Update
the Bulgarian msgstrs for the "unset" success messages in
packages/dashboard/src/i18n/locales/bg.po so they read as completed-action
confirmations rather than present-state descriptions: replace the msgstr for
msgid "Billing address unset for order" with "Адресът за фактуриране е премахнат
от поръчката" and likewise replace the msgstr for msgid "Shipping address unset
for order" with "Адресът за доставка е премахнат от поръчката" to match the
action-oriented phrasing used by the error messages.
Comment on lines
+2118
to
+2121
| #. placeholder {0}: error.message | ||
| #: src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx:302 | ||
| msgid "Failed to complete draft order: {0}" | ||
| msgstr "Kunne ikke fullføre utkast til ordre: {0}" |
Contributor
There was a problem hiding this comment.
Terminology inconsistency: new error strings use different NB terms than the existing success strings for the same concepts.
Three divergences observed:
| Concept | Existing success-message translation | New error-message translation |
|---|---|---|
| "order" | bestilling (e.g., Line 1306, 1543, 1688, 4404) |
ordre (all new entries) |
| "billing address" | Fakturaadresse (Lines 1298, 1306, 1310) |
faktureringsadresse (Lines 2338, 2377) |
| "order line" | Bestillingslinje (Lines 3549, 3553) |
ordrelinje (Lines 2317, 2453) |
Norwegian users will see mixed vocabulary for the same domain concepts depending on whether an operation succeeds or fails. Aligning the error strings to the established terms would improve consistency.
🌐 Suggested alignments
-msgstr "Kunne ikke fullføre utkast til ordre: {0}"
+msgstr "Kunne ikke fullføre utkastbestilling: {0}"
-msgstr "Kunne ikke slette utkast til ordre: {0}"
+msgstr "Kunne ikke slette utkastbestilling: {0}"
-msgstr "Kunne ikke fjerne kupongkode fra ordre: {0}"
+msgstr "Kunne ikke fjerne kupongkode fra bestilling: {0}"
-msgstr "Kunne ikke fjerne ordrelinje: {0}"
+msgstr "Kunne ikke fjerne bestillingslinje: {0}"
-msgstr "Kunne ikke angi faktureringsadresse for ordre: {0}"
+msgstr "Kunne ikke angi fakturaadresse for bestilling: {0}"
-msgstr "Kunne ikke angi kupongkode for ordre: {0}"
+msgstr "Kunne ikke angi kupongkode for bestilling: {0}"
-msgstr "Kunne ikke angi kunde for ordre: {0}"
+msgstr "Kunne ikke angi kunde for bestilling: {0}"
-msgstr "Kunne ikke angi leveringsadresse for ordre: {0}"
+msgstr "Kunne ikke angi leveringsadresse for bestilling: {0}"
-msgstr "Kunne ikke angi leveringsmetode for ordre: {0}"
+msgstr "Kunne ikke angi leveringsmetode for bestilling: {0}"
-msgstr "Kunne ikke fjerne faktureringsadresse for ordre: {0}"
+msgstr "Kunne ikke fjerne fakturaadresse fra bestilling: {0}"
-msgstr "Kunne ikke fjerne leveringsadresse for ordre: {0}"
+msgstr "Kunne ikke fjerne leveringsadresse fra bestilling: {0}"
-msgstr "Kunne ikke oppdatere egendefinerte felt for ordre: {0}"
+msgstr "Kunne ikke oppdatere egendefinerte felt for bestilling: {0}"
-msgstr "Kunne ikke oppdatere ordrelinje: {0}"
+msgstr "Kunne ikke oppdatere bestillingslinje: {0}"Also applies to: 2253-2256, 2301-2304, 2314-2317, 2335-2338, 2374-2377, 2379-2382, 2450-2453
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/dashboard/src/i18n/locales/nb.po` around lines 2118 - 2121, The
Norwegian translations in locales/nb.po use inconsistent domain terms in error
messages; update the msgstr for the affected msgid entries (e.g., msgid "Failed
to complete draft order: {0}") and the other listed error msgid blocks (lines
referenced in the comment: 2253-2256, 2301-2304, 2314-2317, 2335-2338,
2374-2377, 2379-2382, 2450-2453) to match the established vocabulary used by
success messages: replace "ordre" with "bestilling", "faktureringsadresse" with
"Fakturaadresse", and "ordrelinje" with "Bestillingslinje" so all error
translations use the same domain terms (search for the specific msgid strings
like "Failed to complete draft order: {0}" to locate each entry).
Comment on lines
+2118
to
+2121
| #. placeholder {0}: error.message | ||
| #: src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx:302 | ||
| msgid "Failed to complete draft order: {0}" | ||
| msgstr "Falha ao concluir o rascunho do pedido: {0}" |
Contributor
There was a problem hiding this comment.
Minor translation terminology inconsistencies in the new error strings.
Two terms are translated differently in the new error messages compared to the existing UI strings in this file:
| Concept | Established translation (existing entries) | New error message translation |
|---|---|---|
| "draft order" | "Pedido rascunho" (e.g. lines 1846, 1851, 1855, 1766) |
"o rascunho do pedido" (lines 2118, 2253) |
| "order line" | "Linha de pedido" / "Linhas de pedido" (e.g. lines 3548, 3552, 3556) |
"item do pedido" (lines 2314, 2450) |
For example, "Order line removed" → "Linha de pedido removida", but "Failed to remove order line: {0}" → "Falha ao remover o item do pedido: {0}".
Please have a native Portuguese speaker align these with the conventions already established in the file — or intentionally update all occurrences if the newer wording is preferred.
Also applies to: 2253-2256, 2314-2317, 2450-2453
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/dashboard/src/i18n/locales/pt_BR.po` around lines 2118 - 2121,
Update the Portuguese translations to match existing terminology: replace
occurrences of "o rascunho do pedido" with the established "Pedido rascunho" and
change "item do pedido" to "Linha de pedido"/"Linhas de pedido" as used
elsewhere; specifically update the msgstr for msgid "Failed to complete draft
order: {0}" and the msgstrs for the error strings like "Failed to remove order
line: {0}" (and the related entries referenced in the review) so they use the
consistent terms "Pedido rascunho" and "Linha de pedido"/"Linhas de pedido" to
align with the rest of the file.
Comment on lines
+2350
to
+2353
| #. placeholder {0}: error.message | ||
| #: src/app/routes/_authenticated/_orders/orders_.draft.$id.tsx:198 | ||
| msgid "Failed to set shipping address for order: {0}" | ||
| msgstr "Falha ao definir o endereço de entrega da encomenda: {0}" |
Contributor
There was a problem hiding this comment.
Inconsistent terminology for "shipping address": entrega vs envio.
The two new error messages use endereço de **entrega**, while the existing success messages for the same operations ("Shipping address set/unset for order" at lines 4403–4409) use Endereço de **envio**. All other shipping-related strings in this file (Morada de envio, Método de envio, Endereço de envio) consistently use envio. A user who triggers an error sees a different term than in the success path for the identical operation.
🐛 Proposed fix — align error messages with the existing `envio` terminology
-msgstr "Falha ao definir o endereço de entrega da encomenda: {0}"
+msgstr "Falha ao definir o endereço de envio da encomenda: {0}"-msgstr "Falha ao remover o endereço de entrega da encomenda: {0}"
+msgstr "Falha ao remover o endereço de envio da encomenda: {0}"Also applies to: 2379-2382
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/dashboard/src/i18n/locales/pt_PT.po` around lines 2350 - 2353, The
Portuguese translations for the error messages use "endereço de entrega" while
the rest of the file uses "envio"; update the msgstr for the msgid "Failed to
set shipping address for order: {0}" (and the analogous msgid "Failed to unset
shipping address for order: {0}") to replace "entrega" with "envio" so they
match existing strings like "Endereço de envio" and "Morada de envio".
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Description
Displays errors if update mutations fail when editing draft orders.
The error message might be more important for developer as they tend to be technical. But it's still nice to inform the user about a failed request.
Breaking changes
Does this PR include any breaking changes we should be aware of?
Screenshots
You can add screenshots here if applicable.
Checklist
📌 Always:
👍 Most of the time: