-
Notifications
You must be signed in to change notification settings - Fork 1.3k
feat(dashboard): Add internationalization for Romanian language #3997
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
feat(dashboard): Add internationalization for Romanian language #3997
Conversation
…ces pluralization support
…ollections dialog
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughAdds Romanian ( Changes
Sequence Diagram(s)(No sequence diagram — changes are localization and textual/pluralization updates without modifications to control flow or inter-component protocols.) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ 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 |
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (13)
packages/dashboard/src/i18n/locales/it.po (1)
3048-3049: Consider refining the translation of "override" for technical accuracy.The phrase "Can be overridden by product variants" is translated as "Può essere sostituito da varianti prodotto" (can be replaced by). In a technical context, "override" implies superseding a default while keeping it as a fallback, rather than complete replacement.
Consider using:
- "Può essere sovrascritto dalle varianti prodotto" (can be overridden by), or
- "Può essere personalizzato dalle varianti prodotto" (can be customized by)
-msgstr "Imposta il livello di scorta al quale una variante è considerata esaurita. L'utilizzo di un valore negativo abilita il supporto per ordini arretrati. Può essere sostituito da varianti prodotto." +msgstr "Imposta il livello di scorta al quale una variante è considerata esaurita. L'utilizzo di un valore negativo abilita il supporto per ordini arretrati. Può essere sovrascritto dalle varianti prodotto."packages/dashboard/src/i18n/locales/pt_PT.po (1)
736-769: Pluralization entries use correct Lingui format with grammatically sound Portuguese.The new pluralization messages demonstrate proper implementation:
- Singular/plural agreement: "país/países", "coleção/coleções", "método" apply correct grammatical number
- Past participle agreement (line 748-749): "Encontrado" (singular) vs "Encontrados" (plural) correctly agrees with the noun, which is more linguistically precise than the English source
- Consistent terminology: Reuses established translations ("coleção", "zona", "país")
Minor note: Entries mix
=1 {...} other {...}format (lines 738, 753, 758, 764) withone {...} other {...}format (lines 743, 748, 768). Both are valid in Lingui, but consistency within the file would improve maintainability.Consider standardizing pluralization delimiters across all plural entries to either
=1oronefor consistency, though this is not blocking since both formats are functionally equivalent.packages/dashboard/src/i18n/locales/pl.po (2)
736-770: Pluralization and move/zone/shipping texts look solid, with one optional case tweakThe ICU plural syntax and placeholders in these messages are correct, and the overall Polish phrasing for moving collections, loading collections, and zone bulk actions is clear and consistent.
One small grammatical improvement you could consider (optional):
- msgstr "{0, plural, one {Czy na pewno chcesz usunąć # kraj z tej strefy?} other {Czy na pewno chcesz usunąć # kraje z tej strefy?}}" + msgstr "{0, plural, one {Czy na pewno chcesz usunąć # kraj z tej strefy?} other {Czy na pewno chcesz usunąć # krajów z tej strefy?}}" - msgstr "{0, plural, one {Usunięto # kraj ze strefy} other {Usunięto # kraje ze strefy}}" + msgstr "{0, plural, one {Usunięto # kraj ze strefy} other {Usunięto # krajów ze strefy}}"Using “krajów” in the
otherbranch sounds more natural for higher counts (5, 10, 100, …), and doesn’t harm the 2–4 case too much given the two-form limitation in the msgid.Also applies to: 2179-2182, 2719-2722, 2842-2853, 3505-3507, 3712-3715
1747-1750: Make date-format labels more idiomatic in Polish“Display language”, “Locale”, “Sample Formatting”, and “Select display language” are all translated well. The only slightly awkward bits are the labels for date formats:
msgid "Medium date" msgstr "Data średnia" msgid "Short date" msgstr "Data krótka"A more natural UI wording would be:
msgid "Medium date" -msgstr "Data średnia" +msgstr "Średni format daty" msgid "Short date" -msgstr "Data krótka" +msgstr "Krótki format daty"This matches how date-format options are typically named in Polish system UIs.
Also applies to: 2747-2749, 2800-2803, 3783-3785, 3969-3971, 4111-4114
packages/dashboard/src/i18n/locales/es.po (4)
1214-1217: Manage-languages / global-language settings: semantics are solid, capitalization slightly inconsistent
- All manage-languages/global-language strings (e.g.
"Available Languages","Global Languages","Default Language","Configure available languages for your store and channels","These languages will be available for all channels to use", permissions and loading/error messages) accurately convey the English intent.- Permission texts clearly differentiate channel vs. global language settings and are easy to understand.
Minor polish suggestion: capitalization in Spanish headings is a bit inconsistent (e.g.
"Idiomas Disponibles","Idiomas Globales","Idioma Predeterminado"vs other headings using sentence case like"Idiomas disponibles"). If you care about visual consistency, you might normalize these to either sentence case or title-style across the language-management UI.Also applies to: 1402-1405, 1649-1652, 2171-2174, 2443-2446, 2727-2730, 3131-3133, 3956-3959, 3976-3978, 4599-4602, 4944-4946, 4948-4950
1088-1091: Healthcheck strings are accurate; consider unifying wording
"All resources are up and running","Some resources are down","Current status","Health checks","Monitored Resources","Last updated {0}", and"Refresh"are all correctly translated and match the monitoring context.- There is minor variation between
"Healthchecks"→"Comprobaciones de salud"and"Health checks"→"Verificaciones de salud". Both are valid, but you might standardize on one term (e.g. always"Comprobaciones de salud") for a more cohesive UI.Functionally everything is fine; this is purely wording consistency.
Also applies to: 1546-1549, 2524-2531, 2681-2684, 2829-2832, 3649-3651, 4158-4161
1011-1014: Stock / variants strings: one minor wording/casing tweak suggested
"No stock locations available on current channel","Stock on Hand","Variant", and the global out‑of‑stock threshold description are all correctly translated and align with existing uses of stock in the file."Add Stock to Location"→"Agregar Stock a Ubicación"is understandable but slightly awkward in Spanish and inconsistent with your other usages where stock and common nouns are lowercase (e.g."Añadir nivel de stock para otra ubicación").Consider something like:
-msgid "Add Stock to Location" -msgstr "Agregar Stock a Ubicación" +msgid "Add Stock to Location" +msgstr "Agregar stock a la ubicación"This better matches natural Spanish and your existing terminology.
Also applies to: 3200-3202, 4047-4050, 4218-4221, 4826-4829
1751-1754: Language-dialog / locale / login UX strings are correct; optional tweak for “Medium date”
"Display language","Select display language","Locale","Sample Formatting","Short date","Medium date","Price","Search languages...", and login"Please wait"are all well translated and fit their UI purposes.- Very minor:
"Medium date"→"Fecha media"is understandable, though something like"Fecha intermedia"or"Fecha mediana"might sound slightly more natural to some Spanish speakers. This is subjective and not required to ship.Functionally everything here is fine.
Also applies to: 2750-2753, 2804-2807, 3512-3515, 3786-3789, 3972-3975, 3539-3542, 3877-3879
packages/dashboard/src/i18n/locales/en.po (1)
736-769: Minor inconsistency in pluralization syntax.Line 738 uses
=1(exact numeric match) while all other plural entries (lines 743, 747, 752, etc.) useone(grammatical plural category). For English, both work identically, but usingoneconsistently is the ICU message format best practice as it properly maps to grammatical plural rules in languages with more complex pluralization (like Romanian, which this PR adds).-msgid "{0, plural, =1 {Select a target collection to move this collection to.} other {Select a target collection to move # collections to.}}" -msgstr "{0, plural, =1 {Select a target collection to move this collection to.} other {Select a target collection to move # collections to.}}" +msgid "{0, plural, one {Select a target collection to move this collection to.} other {Select a target collection to move # collections to.}}" +msgstr "{0, plural, one {Select a target collection to move this collection to.} other {Select a target collection to move # collections to.}}"packages/dashboard/src/i18n/locales/ne.po (2)
736-769: Minor inconsistency in ICU plural syntax - both approaches are valid.The plural forms use two different approaches:
- Lines 738-739:
{0, plural, =1 {...} other {...}}(exact match)- Lines 743, 753, etc.:
{0, plural, one {...} other {...}}(CLDR plural category)Both are valid ICU MessageFormat syntax. Using
=1matches exactly the number 1, whileoneuses CLDR plural rules which is more appropriate for localization as some languages have different rules for what constitutes "one" (e.g., numbers ending in 1 but not 11 in some Slavic languages).For consistency across the codebase, consider standardizing on one approach. The
one/otherpattern is generally preferred for i18n.
14-14: Consider adding Plural-Forms header for Nepali locale.The
Plural-Formsheader is empty. While the codebase uses ICU MessageFormat syntax for pluralization (which handles this internally), having the proper Plural-Forms header is good practice for PO file completeness:-"Plural-Forms: \n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n"This follows the standard Nepali plural rules where there are 2 forms: singular (n=1) and plural (n≠1).
packages/dashboard/src/i18n/locales/cs.po (2)
736-770: ICU plural messages work; optionally refine for Czech ‘few’ formsThe new pluralized messages for:
- selecting/moving collections,
- removing countries from a zone,
- reporting found shipping methods,
are syntactically valid ICU plurals and preserve
#/placeholders correctly.If you want grammatically perfect Czech for counts 2–4, you could optionally introduce a
fewbranch, e.g.:msgstr "{0, plural, one {Opravdu chcete odebrat # zemi z této zóny?} few {Opravdu chcete odebrat # země z této zóny?} other {Opravdu chcete odebrat # zemí z této zóny?}}"Current translations are acceptable, so this is purely a quality polish, not a blocker.
Also applies to: 746-750, 751-765
4043-4051: Unify ‘backorder’ terminology and tweak helper text (optional)The global out-of-stock helper now uses “zpětných objednávek” while the per‑variant helper below still says “předobjednávek”, even though both English texts refer to “backorder support”. For consistency and clarity you might:
- Standardize on one term, e.g. “zpětné objednávky”.
- Slightly clarify the last sentence to refer explicitly to the setting.
For example:
-msgstr "Nastavuje skladovou úroveň, při které je varianta považována za vyprodanou. Použití záporné hodnoty umožňuje podporu zpětných objednávek. Může být přepsáno variantami produktu." +msgstr "Nastavuje skladovou úroveň, při které je varianta považována za vyprodanou. Použití záporné hodnoty umožňuje podporu zpětných objednávek. Toto nastavení lze přepsat na úrovni variant produktu." -... "Použití záporné hodnoty umožňuje podporu předobjednávek." +... "Použití záporné hodnoty umožňuje podporu zpětných objednávek."This is a style/consistency improvement only.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (21)
packages/dashboard/lingui.config.js(1 hunks)packages/dashboard/src/app/routes/_authenticated/_collections/components/move-collections-dialog.tsx(3 hunks)packages/dashboard/src/app/routes/_authenticated/_global-settings/global-settings.tsx(1 hunks)packages/dashboard/src/app/routes/_authenticated/_shipping-methods/components/test-shipping-methods-result.tsx(3 hunks)packages/dashboard/src/app/routes/_authenticated/_zones/components/zone-bulk-actions.tsx(3 hunks)packages/dashboard/src/i18n/locales/ar.po(86 hunks)packages/dashboard/src/i18n/locales/cs.po(86 hunks)packages/dashboard/src/i18n/locales/de.po(86 hunks)packages/dashboard/src/i18n/locales/en.po(86 hunks)packages/dashboard/src/i18n/locales/es.po(86 hunks)packages/dashboard/src/i18n/locales/fa.po(86 hunks)packages/dashboard/src/i18n/locales/fr.po(86 hunks)packages/dashboard/src/i18n/locales/he.po(86 hunks)packages/dashboard/src/i18n/locales/hr.po(86 hunks)packages/dashboard/src/i18n/locales/it.po(86 hunks)packages/dashboard/src/i18n/locales/ja.po(86 hunks)packages/dashboard/src/i18n/locales/nb.po(86 hunks)packages/dashboard/src/i18n/locales/ne.po(86 hunks)packages/dashboard/src/i18n/locales/pl.po(86 hunks)packages/dashboard/src/i18n/locales/pt_BR.po(86 hunks)packages/dashboard/src/i18n/locales/pt_PT.po(86 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
packages/dashboard/src/app/routes/_authenticated/_zones/components/zone-bulk-actions.tsx (1)
packages/admin-ui/src/lib/core/src/common/utilities/selection-manager.ts (1)
selection(19-21)
packages/dashboard/src/app/routes/_authenticated/_collections/components/move-collections-dialog.tsx (1)
packages/dashboard/src/lib/components/ui/alert.tsx (1)
AlertDescription(60-60)
🔇 Additional comments (56)
packages/dashboard/src/i18n/locales/hr.po (1)
28-51: Pluralization entries are structurally well-formed; verify runtime behavior and translation accuracy.The new translation entries introducing pluralization support follow correct ICU MessageFormat syntax and maintain proper msgid/msgstr parity. All plural forms are properly paired (e.g.,
one/other,=1/other).However, a few observations for verification:
Plural form consistency: Lines 738-739 use
=1for exact matching, while lines 743+ useone(CLDR plural form). Both are valid, butoneis preferred for language-aware pluralization. This inconsistency likely originates from the source code files being translated (move-collections-dialog.tsx line 354 vs. zone-bulk-actions.tsx line 57).Runtime validation needed: Ensure that the pluralization logic works correctly with the Lingui i18n framework at runtime—especially for the dynamic count placeholders (e.g.,
{0, plural, ...}).Translation accuracy: Croatian translations use correct plural forms (e.g., "# državu" for singular, "# država" for plural), but recommend verification by a Croatian speaker to ensure natural phrasing and correctness.
All line references appear to be consistently updated throughout the file.
Also applies to: 224-227, 736-769
packages/dashboard/src/i18n/locales/it.po (4)
28-52: LGTM! Query extension error messages are well translated.The Italian translations for the new query extension error messages are accurate, clear, and maintain proper technical terminology. Format strings are correctly preserved.
224-228: LGTM! User input placeholder is clearly translated.The placeholder text is well translated with clear instructions for Italian users.
736-770: LGTM! Plural forms are correctly implemented.All pluralized translations follow Italian plural rules correctly using the Lingui format with
oneandothercases. Grammar and number agreement are accurate throughout:
- Collections: "collezione" (singular) → "collezioni" (plural)
- Countries: "paese" (singular) → "paesi" (plural)
- Shipping methods: "metodo... idoneo" (singular) → "metodi... idonei" (plural)
Format placeholders are properly maintained.
1-4973: Line reference updates are expected and correct.The numerous line reference updates (marked with ~) throughout the file are metadata changes reflecting source code reorganization. These are standard .po file maintenance and don't affect translation functionality.
packages/dashboard/lingui.config.js (1)
28-28: LGTM!The Romanian locale ('ro') is correctly added to the locales array, enabling Romanian catalog generation for the dashboard.
packages/dashboard/src/i18n/locales/he.po (1)
736-769: LGTM!The Hebrew pluralization entries are correctly formatted using ICU MessageFormat syntax. The translations properly handle singular/plural forms for collections, zones, and shipping methods.
packages/dashboard/src/app/routes/_authenticated/_global-settings/global-settings.tsx (1)
133-137: LGTM!Good grammar correction - removing the erroneous "this" from "at which this a variant" to "at which a variant" improves the clarity of the description text.
packages/dashboard/src/app/routes/_authenticated/_zones/components/zone-bulk-actions.tsx (3)
9-10: LGTM!Correct imports for both the JSX
Pluralcomponent (for rendering) and thepluralfunction (for programmatic string generation in toast messages).
32-37: LGTM!Good use of the
plural()function from@lingui/core/macrofor the toast message, which correctly handles the singular/plural forms for country removal notifications.
57-61: LGTM!The
<Plural>component is correctly used for the confirmation dialog text with proper singular ("# country") and plural ("# countries") forms.packages/dashboard/src/app/routes/_authenticated/_shipping-methods/components/test-shipping-methods-result.tsx (1)
62-66: LGTM!Good use of
<Plural>to properly handle the singular/plural forms for the eligible shipping methods count. The#placeholder correctly displays the count value.packages/dashboard/src/app/routes/_authenticated/_collections/components/move-collections-dialog.tsx (4)
18-18: LGTM!Correct import of
Pluralalongside existingTransanduseLinguiimports.
69-71: LGTM!Good addition of
selectedCollectionNamederived from the cache, enabling context-aware pluralized messages that include the destination collection name.
78-96: LGTM!The pluralization logic correctly handles all three scenarios:
- Top-level destination with plain string plurals
- Named collection with
<Trans>wrapping for variable interpolation- Generic fallback for unnamed selections
Using
<Trans>inside theone/otherprops (lines 87-88) is the correct approach when interpolating variables like{selectedCollectionName}.
354-358: Based on the web search results, I can verify the technical correctness of the review comment:The Lingui
Pluralcomponent distinguishes betweenone(ICU plural form for singular) and_1(exact-match for count=1). These are not interchangeable — they serve different purposes:
oneis the proper plural category form for singular case_1is an exact-match form that takes precedence over plural categoriesThe review comment's technical point is sound — using
onewould be more semantically appropriate for the singular text variant. However, I was unable to access the repository to verify:
- The actual code at lines 354-358 and 79-95
- Whether lines 79-95 actually use
oneas claimed- The consistency pattern across other
Pluralusages in the file
Use
oneinstead of_1for the singular form in the Plural component. Theoneprop represents the correct ICU plural category for singular case, while_1is an exact-match form for count=1. These serve different purposes;oneis more semantically appropriate here.<Plural value={collectionsToMove.length} - _1={'Select a target collection to move this collection to.'} + one={'Select a target collection to move this collection to.'} other={'Select a target collection to move # collections to.'} />packages/dashboard/src/i18n/locales/pt_BR.po (2)
28-51: New query extension error translations added correctly.The six new translation entries for query extension errors are clear and appropriately translated into Portuguese. The error messages maintain clarity and context consistency with the existing codebase.
736-769: Pluralization entries follow correct Lingui syntax and Portuguese grammar.All eight new plural translation entries correctly use the
{count, plural, one {...} other {...}}syntax and follow Brazilian Portuguese plural rules. The # placeholder for number formatting is properly positioned within each form, and the singular/plural distinctions are grammatically appropriate for Portuguese contexts (e.g., "país" vs. "países", "coleção" vs. "coleções", "método" vs. "métodos").packages/dashboard/src/i18n/locales/pt_PT.po (2)
28-51: New GraphQL error translations are well-executed.The additions for query extension error messages (lines 28-51) are accurate, clear, and idiomatic Portuguese. The translations properly convey the technical error context.
224-227: String list input placeholder is properly translated."Type and press Enter or comma to add..." → "Digite e prima Enter ou vírgula para adicionar..." is idiomatic and accurate Portuguese. The use of "prima" (press) and "para adicionar" (to add) follows natural Portuguese phrasing conventions.
packages/dashboard/src/i18n/locales/fa.po (2)
736-769: Plural forms look correct for Persian.The ICU MessageFormat plural syntax is correctly applied. Persian doesn't require grammatical plural distinctions in most contexts, so identical translations for
oneandotherforms (e.g., lines 743-744, 748-749) are acceptable.Note: Line 769 uses differentiated verb endings (
حذف شدvsحذف شدند), which is a nice touch for past tense. The other plural entries could optionally follow this pattern for consistency, but this is not required.
224-227: LGTM!The new placeholder string translation is clear and appropriate for Persian users.
packages/dashboard/src/i18n/locales/de.po (1)
1-50: Translation file appears well-structured with proper pluralization support.All marked changes show correctly formatted Gettext PO entries with corresponding German translations. The new pluralization messages (lines 736–769) use valid ICU MessageFormat syntax with appropriate singular/plural forms for German. Query extension error messages and UI label updates are consistently translated with no missing msgstr entries.
packages/dashboard/src/i18n/locales/ja.po (4)
28-51: New query extension error messages translated correctly. The five GraphQL error messages (lines 28-51) are properly added with appropriate Japanese translations. Format and structure are consistent with existing entries.
224-227: New UI placeholder string added appropriately. The string-list input placeholder at line 225-226 ("Type and press Enter or comma to add...") is correctly translated to Japanese with proper context for the user action.
736-769: Pluralization entries use correct ICU MessageFormat syntax. All six new pluralized messages (lines 736-769) follow the standard ICU pattern with proper singular/plural forms:
- Collection move messages (lines 738-764): correctly handle singular "collection" vs plural "collections"
- Zone country removal (lines 743-744, 768-769): consistent plural handling
- Shipping method eligibility (lines 748-749): uses
onevsotherforms appropriatelyJapanese translations use
#as a placeholder for count values, which is the standard convention for this format. All msgid/msgstr pairs are complete.
1-14: Verify PO file metadata is current. The file header (lines 1-14) showsPOT-Creation-Date: 2025-02-20 14:18+0100. Confirm this timestamp aligns with the PR merge date and thatPlural-Forms(line 14) is correctly set for Japanese. If this field is empty, it should be populated with the proper plural form expression for Japanese (typicallynplurals=1; plural=0;).packages/dashboard/src/i18n/locales/es.po (6)
28-52: Query-extension error strings: semantics and punctuation are correctThe new query-extension error messages map cleanly to Spanish, including the trailing colons and spaces in
"Query extension mismatch: "/"Error de extensión de consulta: ". No placeholders are dropped and the tone matches existing error messages.
224-228: Filter/search helper texts read naturally and are consistent
"Type and press Enter or comma to add..."→"Escriba y presione Enter o coma para agregar..."is clear and idiomatic."Clear all","Filter by collection name","Filter...", and"No results"all use consistent terminology with the rest of the file.No issues with meaning or style here.
Also applies to: 1337-1341, 2344-2347, 2352-2355, 3177-3181
736-770: Pluralization for collections/zones/shipping and related messages is correct
- All ICU plural blocks for collections and zones (e.g.
"{0, plural, ...}","# country/countries") preserve the plural logic and use grammatically correct singular/plural Spanish forms.- Zone bulk-action strings (
"Remove from zone","Removed # country from zone","Failed to remove countries from zone") are accurate and consistent with existing terminology (quitar/eliminar).- Move-collections dialog strings (
"Move Collections","Move to the top level","Loading collections...","Please select a target collection","Select a destination collection", success/failure to move) all read well and match the intent of the English originals."Found # eligible shipping method(s)"correctly flips verb agreement (Se encontróvs.Se encontraron) between singular and plural."Code"in the zone countries table remains correctly translated as"Código".ICU syntax (
#, braces, and selectors) is intact in all these entries.Also applies to: 792-796, 1364-1368, 1379-1382, 2179-2186, 2344-2347, 2723-2726, 2846-2854, 3508-3511, 3716-3719
814-819: Placeholder-only strings are preserved correctlyStrings that are essentially wrappers around placeholders (e.g.
"{buttonText}","{label}","Language: {0}","Transition to {0}","Select next state","Select the next state for the order","Transition to selected state") all:
- Keep the placeholders unchanged.
- Use natural Spanish around them where applicable.
No functional or translation issues here.
Also applies to: 820-824, 2647-2650, 3988-3991, 4000-4003, 4707-4710, 4717-4719
1108-1112: Customer address / shared address form strings look consistent and naturalAddress-related fields and actions:
"Apartment, suite, etc.","Company","City","Country","Full Name","Street Address","Postal Code","Phone Number"."Default Billing Address","Default Shipping Address","Use as the default billing/shipping address","Select a country","Save Address".All have idiomatic Spanish, consistent phrasing, and share the same wording across customer, shipping-test, and shared address forms. No placeholder or meaning issues.
Also applies to: 1327-1332, 1387-1392, 1448-1454, 1627-1636, 1653-1657, 2428-2433, 3494-3499, 3516-3521, 3915-3919, 4222-4227, 4792-4796, 4797-4801, 3800-3804
1238-1243: Order-detail / history / transition strings are correctly wired to SpanishFor the order flows (detail, modification, transitions), all new or re-referenced strings look good:
- Status and sections:
"Customer","Billing address","Shipping address","Fulfillment details","Payment details","Tax summary","Order history","No customer","No fulfillments".- Actions and outcomes:
"Successfully updated order","Failed to modify order","Failed to transition order to state","Failed to update order","Error transitioning to state".- Transition prompts:
"Transition to {0}","Select next state","Select the next state for the order","Transition to selected state".Translations are clear, maintain the same nuance as English, and keep placeholders untouched.
Also applies to: 1562-1567, 1946-1949, 2175-2178, 2213-2216, 2270-2273, 2407-2410, 3007-3010, 3127-3130, 3320-3323, 3435-3438, 4071-4075, 4517-4519, 3988-3991, 4000-4003, 4707-4710, 4717-4719, 4405-4408
packages/dashboard/src/i18n/locales/ar.po (6)
28-51: Format and structure look good for new query extension error messages.The new error message entries (lines 28–51) follow the correct PO format with proper msgid/msgstr pairs. The Arabic translations appear complete and the structure is consistent with existing entries.
224-227: Approve addition of string-list-input UI string.The new placeholder text translation for "Type and press Enter or comma to add..." is properly formatted and integrated with correct line references to
src/lib/components/data-input/string-list-input.tsx:237.
736-770: Pluralization entries follow correct Lingui format.The pluralization entries for collection moves, zone country removals, and shipping methods (lines 736–770) correctly use the Lingui plural syntax:
{0, plural, one {...} other {...}}or=1 {...} other {...}. Format is consistent across all pluralization blocks:
- Line 738–739: Collection move singular/plural variants
- Line 743–744: Zone country removal with
one/othervariants- Line 748–749: Shipping method count with
one/othervariants- Lines 753–754, 758–759, 763–764: Additional collection move scenarios
860-863: Verify line reference updates align with component reorganizations.Sampled line references show proper reorganization:
- Line 860:
channel-switcher.tsx:171(context: "active language")- Line 1011–1013:
create-product-variants.tsx:182(Stock to Location)- Line 1088:
healthchecks.tsx:66(resources status)- Line 1238–1242:
order-detail-shared.tsx:270(Billing address)These reflect the PR's stated component path updates and appear correctly positioned. No evidence of stale or misaligned references in the sample.
Also applies to: 1011-1013, 1088-1090, 1108-1110, 1238-1242
1214-1216: New language/channel management UI strings properly integrated.Lines reflecting the expanded i18n coverage for channel and language management show consistent additions:
- Line 1214–1216: "Available Languages"
- Line 1315–1317: "Channel Languages"
- Line 1327–1331: "City"
- Line 1379–1381: "Collections moved successfully"
- Line 1402–1405: "Configure available languages for your store and channels"
- Line 1449–1452: "Country"
- Line 1537–1540: "Current"
- Line 1649–1651: "Default Language"
- Line 1751–1753: "Display language"
All follow standard msgid/msgstr format without anomalies.
Also applies to: 1315-1317, 1327-1331, 1379-1381, 1402-1405, 1449-1452, 1537-1540, 1649-1651, 1751-1753
2443-2445: Global and channel language configuration strings properly added.New entries at lines 2443–2445 ("Global Languages") and 2774–2777 ("Manage Languages") correctly support the expanded language management functionality described in the PR objectives. Both follow standard format with proper source file references.
Also applies to: 2774-2777
packages/dashboard/src/i18n/locales/nb.po (1)
1-4960: LGTM! Well-maintained translation file with proper i18n enhancements.This Norwegian Bokmål translation file has been properly updated with:
- New query extension error messages (lines 28-52): Properly translated error strings for GraphQL query extension handling
- Pluralization support (lines 736-770): Correctly implemented ICU MessageFormat pluralization for dynamic content like collection moves, zone bulk actions, and shipping method results
- Updated source references: Line numbers and file paths updated throughout to reflect code refactoring
- New UI strings: Added translations for features like "Manage Languages", "Loading global settings...", etc.
The translations follow Norwegian language conventions correctly:
- Proper use of Norwegian characters (å, æ, ø)
- Correct plural forms (note: "land" remains "land" in plural, which is correct)
- Placeholders (
{0},#, variable names) preserved accurately- ICU MessageFormat syntax properly applied
packages/dashboard/src/i18n/locales/fr.po (6)
28-52: LGTM!The new French translations for query extension error messages are grammatically correct and maintain consistency with the existing error message patterns.
224-228: LGTM!Clear and natural French translation for the input placeholder.
736-770: LGTM!The ICU plural form translations are correctly implemented for French:
- Proper singular/plural differentiation where applicable
- Correct handling of invariable words like "pays" (country)
- Proper adjective and past participle agreement (e.g., "retiré" vs "retirés", "éligible" vs "éligibles")
2179-2181: LGTM!Correct French translation for the zone error message.
3044-3046: LGTM!The updated description translation accurately conveys the stock threshold functionality, including the backorder support explanation.
3508-3510: LGTM!Standard and correct French translation for the waiting message.
packages/dashboard/src/i18n/locales/en.po (5)
28-51: LGTM!The new query extension error messages are well-structured and follow the existing .po file conventions. The trailing colons on "Query extension mismatch: " and "Query extension error: " appropriately indicate that dynamic content will be appended.
3043-3046: LGTM!The description text is clear and grammatically correct.
3509-3511: LGTM!Simple and appropriate loading state message for the login form.
2178-2181: LGTM!The new zone-related error message follows the existing error message patterns.
2712-2715: LGTM!The new "Remove from zone" action label is clear and consistent with other bulk action labels in the file.
packages/dashboard/src/i18n/locales/ne.po (3)
28-51: LGTM - New query extension error translations are complete and well-formatted.The new error message translations for query extension functionality are properly structured with complete Nepali translations.
224-227: LGTM - Placeholder translation is complete.The new placeholder text for the string list input component has a proper Nepali translation.
3508-3510: LGTM - New "Please wait" translation added.The new loading state translation is properly formatted and complete.
packages/dashboard/src/i18n/locales/cs.po (2)
224-228: String-list input hint translation looks good
"Type and press Enter or comma to add..." → "Pište a stiskněte Enter nebo čárku pro přidání..."is natural Czech, preserves the semantics, and introduces no placeholder issues. Nothing to change here.
1747-1750: Language/locale-management strings are consistent and safeThe new/retargeted strings around display language & locale (
"Display language","Select display language","Locale", date samples), channel switcher ("Language: {0}","Current","Active"), and manage-languages dialog ("Global Languages","Channel Languages","Select Available Languages", permission errors) all:
- Use consistent terminology with existing “Globální nastavení / Dostupné jazyky”.
- Keep placeholders and ICU syntax intact.
- Read naturally in Czech.
No changes needed.
Also applies to: 2638-2645, 2746-2749, 2800-2803, 3680-3687, 3723-3725, 3953-3955, 2440-2442, 2723-2726, 2770-2773, 3127-3130, 3595-3598, 4940-4947
… query extension messages
…or query extension messages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/dashboard/src/i18n/locales/cs.po (1)
736-770: Consider adding Czech "few" plural form for better grammar.The plural translations are grammatically correct, but Czech has three plural categories:
- one (1): "1 kolekce"
- few (2-4): "2-4 kolekce"
- other (0, 5+): "5+ kolekcí"
Currently, these translations use only two forms ("one" and "other" or "=1" and "other"), which works but may not provide the most natural Czech grammar for numbers 2-4. For example:
Line 738-739:
{0, plural, =1 {Vyberte cílovou kolekci pro přesun této kolekce.} other {Vyberte cílovou kolekci pro přesun # kolekcí.}}Could be enhanced to:
{0, plural, =1 {Vyberte cílovou kolekci pro přesun této kolekce.} few {Vyberte cílovou kolekci pro přesun # kolekcí.} other {Vyberte cílovou kolekci pro přesun # kolekcí.}}While the current translations are functional and understandable, adding the "few" category would align better with Czech linguistic conventions. This applies to similar plural forms throughout lines 736-770.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/dashboard/src/i18n/locales/cs.po(86 hunks)
🔇 Additional comments (3)
packages/dashboard/src/i18n/locales/cs.po (3)
28-52: LGTM! Query extension error translations are correct.The trailing spaces after colons in the error messages are now properly maintained (lines 41, 51), addressing the previous review concern. All Czech translations in this segment are grammatically accurate and consistent with the source strings.
224-228: LGTM! Placeholder translation is accurate.The Czech translation for the string-list input placeholder uses correct imperative forms and natural phrasing.
1-4969: Overall file looks good - Czech translations are accurate.The Czech translation file has been properly maintained with:
- ✅ New query extension error messages with correct trailing spaces
- ✅ Accurate placeholder text translation
- ✅ Grammatically correct plural forms (though could be enhanced)
- ✅ Updated line references reflecting source code changes
All translations follow Czech grammar rules and maintain consistency with the existing translation style.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/dashboard/src/i18n/locales/fa.po(86 hunks)
🔇 Additional comments (9)
packages/dashboard/src/i18n/locales/fa.po (9)
28-52: Extended query error messages: translations + spacing look goodThe new extended-query error messages read naturally in Persian, preserve the technical meaning, and now correctly include the trailing space after the colon where the English msgid has one, resolving the previous spacing issue for prefixes like
"Query extension mismatch: "and"Query extension error: ".
224-228: String-list input placeholder is natural and matches behavior
"Type and press Enter or comma to add..."is well localized as"برای افزودن، تایپ کرده و کلید اینتر یا ویرگول را فشار دهید...", clearly describing both key options and matching the UX.
736-770: Pluralization for collections/zones/shipping methods is consistentThe new plural-form messages for moving/removing collections and countries, and for “Found # eligible shipping method(s)”, correctly preserve ICU plural syntax, keep
#placeholders intact, and use natural Persian constructions (singular noun with numeric quantifier, verb agreement in theotherbranch). No interpolation or grammar issues spotted.Also applies to: 792-796, 2183-2186
1011-1014: Move-collections and stock/location-related strings read wellThe new texts for “Add Stock to Location”, “Collections moved successfully”, “Failed to move collections”, “Filter by collection name”, “Loading collections…”, “Move Collections” / “Move to the top level” / “Moving…”, and “No stock locations available on current channel” are all idiomatic Persian and accurately reflect the English intent for the move-collections and stock-location flows.
Also applies to: 1379-1382, 2179-2182, 2345-2347, 2723-2726, 2846-2857, 3200-3202
1088-1091: Healthcheck/status strings are accurate and consistentStrings like “All resources are up and running”, “Current status”, “Health checks”, “Monitored Resources”, “Refresh”, “Last updated {0}”, and “Some resources are down” are translated clearly and consistently, and the status vocabulary (“در حال اجرا”، “خاموش”، “بررسیهای سلامت”) is coherent across the healthchecks UI.
Also applies to: 1546-1549, 2524-2527, 2681-2683, 2829-2832, 3648-3651, 4158-4161
1387-1392: Address and contact-form labels are coherentLabels like “Company”, “Full Name”, “Street Address / Street Address 2”, “City”, “Postal Code”, “Phone Number”, “Default Billing/Shipping Address”, “Use as the default … address”, and “Save Address” are consistently translated across customer and shipping-address forms, and match existing terminology elsewhere in the catalog.
Also applies to: 2428-2433, 2627-2636, 2945-2949, 3001-3004, 3516-3521, 4181-4185, 4222-4227, 4792-4801, 3800-3803
4047-4055: Global stock-threshold help text matches updated English explanationThe description for the global out-of-stock threshold (including the note about negative values enabling backorders and per-variant overrides) is accurately captured in Persian and aligns with the per-variant help text below.
1947-1949: Order/fulfillment/payment transition messages preserve placeholders correctlyThe various “Error transitioning to state”, “Failed to transition order to state”, “Select next state”, “Select the next state for the order”, and “Transition to {0} / Transition to selected state” messages all keep the placeholders intact and use natural Persian imperative wording.
Also applies to: 2213-2216, 3989-3991, 4001-4003, 4707-4710, 4717-4719
3512-3515: Login “Please wait” text is fine“Please wait” →
"لطفا صبر کنید"is idiomatic and consistent with common Persian UI phrasing.
| #: src/lib/components/layout/channel-switcher.tsx:171 | ||
| msgctxt "active language" | ||
| msgid "Active" | ||
| msgstr "فعال" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor wording tweaks suggested for language/locale texts
The language/locale management strings are generally clear, but a few small polish points would improve correctness and clarity:
- Line 2752 (
msgid "Locale"): current"محلیسازی"describes the process of localization, not the locale setting itself. Consider something like"قالب منطقهای"or"محل (Locale)"instead. - Line 2805 (
msgid "Medium date"):"تاریخ متوسط"reads as “average date”. A more natural label for a medium-length format would be e.g."تاریخ معمولی"or"تاریخ استاندارد". - Line 4601 (
msgid "These languages will be available for all channels to use"):"این زبانها برای استفاده همه کانالها در دسترس خواهد بود"has a singular verb for a plural subject. Prefer plural agreement:"در دسترس خواهند بود".
Example diffs:
-#: src/lib/components/layout/language-dialog.tsx:73
-msgid "Locale"
-msgstr "محلیسازی"
+#: src/lib/components/layout/language-dialog.tsx:73
+msgid "Locale"
+msgstr "قالب منطقهای"-#: src/lib/components/layout/language-dialog.tsx:109
-msgid "Medium date"
-msgstr "تاریخ متوسط"
+#: src/lib/components/layout/language-dialog.tsx:109
+msgid "Medium date"
+msgstr "تاریخ معمولی"-#: src/lib/components/layout/manage-languages-dialog.tsx:316
-msgid "These languages will be available for all channels to use"
-msgstr "این زبانها برای استفاده همه کانالها در دسترس خواهد بود"
+#: src/lib/components/layout/manage-languages-dialog.tsx:316
+msgid "These languages will be available for all channels to use"
+msgstr "این زبانها برای استفاده همه کانالها در دسترس خواهند بود"These are low-impact text-quality improvements and can be applied now or in a follow-up.
Also applies to: 1315-1318, 1402-1405, 1649-1652, 1751-1754, 2443-2446, 2744-2753, 2787-2807, 3956-3959, 3972-3975, 4599-4602, 4945-4950
🤖 Prompt for AI Agents
In packages/dashboard/src/i18n/locales/fa.po around lines 860-863 (and also
review the other occurrences listed: 1315-1318, 1402-1405, 1649-1652, 1751-1754,
2443-2446, 2744-2753, 2787-2807, 3956-3959, 3972-3975, 4599-4602, 4945-4950),
update the Persian translations to use more accurate wording: replace
"محلیسازی" for msgid "Locale" with a term like "قالب منطقهای" or "محل
(Locale)"; change "تاریخ متوسط" for msgid "Medium date" to a more natural label
such as "تاریخ معمولی" or "تاریخ استاندارد"; and for sentences like msgid "These
languages will be available for all channels to use" fix verb agreement from "در
دسترس خواهد بود" to plural "در دسترس خواهند بود"; apply analogous wording fixes
to each listed occurrence ensuring grammatical number and context-appropriate
phrasing.
|
Hi! Thanks for this contribution! Unfortunately in the mean time some other translation stuff got merged which has made a bunch of conflicts. Would you be able to take a look to see if you can resolve those? Then we can get this merged 💪 |



Description
This PR introduces Romanian language support in the Dashboard by adding complete Romanian translations and registering Romanian as an available locale in the Dashboard configuration.
Additionally, this PR:
Breaking changes
No breaking changes
Checklist
📌 Always:
👍 Most of the time:
Summary by CodeRabbit
New Features
Bug Fixes
Localization
✏️ Tip: You can customize this high-level summary in your review settings.