Pimcore Localized Fields Fixer

When you import a catalog into Pimcore, every translatable attribute becomes a localized field with one value per language, and the moment a supplier file is missing a locale or mixes language columns inconsistently, those records import blank, fall back to the wrong language, or silently overwrite good translations. This Pimcore localized fields fixer reads your CSV or JSON export (save XLSX files as CSV UTF-8 first), maps each language column to a Pimcore locale, and flags exactly which products are missing translations before you push them into the data object tree.

Pimcore Localized Fields Fixer

Runs in your browser · no upload

Paste your import file (CSV/TSV with locale columns, or JSON), or upload it

Configured Pimcore languages (optional, comma-separated)

Default language (auto) Output headers Same style as filename.de_DEname#de_DEname_de_DEname (de_DE)localizedfields~name~de_DE

Repair mojibake and whitespace in the output Fill blanks from a same-language locale (e.g. de_AT from de_DE)

Check file Upload a file Try an example Clear

Checks the file, not your Pimcore instance: list your configured languages above so missing locales are measured against them. XLSX files: save as CSV UTF-8 first. See how Claro fills translation gaps with sourced values →

What it checks

The tool inspects the structure and coverage of the localized columns in your import file and reports:

• Locale header detection — recognizes Pimcore-style suffixes like name.en_US, description.de_DE, or name (fr_FR) and confirms each maps to a valid Pimcore locale code: a language such as de, or language_COUNTRY such as de_DE.
• Missing locale columns — lists configured languages that have no column at all, so a furniture range exported only in en_GB does not import as empty de_DE fields.
• Per-row coverage gaps — flags products where some locales are populated and others are blank, the most common cause of partial translations after onboarding.
• Fallback leakage — detects rows where every non-default locale repeats the default-language value verbatim, which usually means an untranslated value will quietly satisfy Pimcore’s language fallback and ship as if it were localized.
• Encoding and whitespace damage — surfaces mojibake (for example a CPG brand name where é became é) and stray non-breaking spaces that break exact-match validation.
• Inconsistent locale codes — catches mixed conventions in the same file, such as de in one header and de_DE in another, which Pimcore treats as two different fields.

How localized fields work in Pimcore

Pimcore stores translatable attributes in a separate localized-values table keyed by object ID and language, and a flat import file has to flatten that structure into one column per language. The standard pattern is a base field name plus a locale suffix, where the locale follows Pimcore’s ICU-style form: a bare language (en, de) or language_COUNTRY with an underscore (en_US, fr_FR, nl_NL), matching the languages configured in your system settings. If a column header does not resolve to a configured locale, the importer either drops it or creates an unexpected field. If a cell is empty, Pimcore’s language fallback may substitute the default-language value at read time, which masks the gap until a customer in another market sees English text on a German storefront.

This fixer applies those same rules to your file before import. It parses headers, normalizes locale codes, builds a coverage matrix of products by language, and grades each column and row as pass, warning, or fail with a plain-language reason. It does not connect to your Pimcore instance or change your data model — it simply tells you what will break so you can fix the file first.

For a repeatable onboarding flow, the same coverage checks belong upstream of your PIM as part of a governed pipeline — that is what Claro’s product data onboarding and enrichment layer automates across thousands of SKUs, with provenance on every translated value.

Related resources

FAQ

What are localized fields in Pimcore? +

Localized fields are attributes Pimcore stores once per language rather than once per object. A single product can hold a separate name, description, or keywords value for en_US, de_DE, fr_FR, and any other configured locale. In a flat import file these become one column per language, usually with a locale suffix on the base field name.

Why do my Pimcore translations import as blank? +

The usual causes are a missing or mis-named locale column, an empty cell for that language, or a locale code that does not match a configured language (for example de instead of de_DE). Pimcore may then leave the field empty or apply language fallback, so the gap is easy to miss. This tool lists the exact products and locales affected.

What is language fallback and why is it risky? +

Language fallback means Pimcore returns a default-language value when a requested locale is empty. It is useful for graceful display, but during onboarding it hides untranslated content: a German storefront can show English copy that looks intentional. The fixer flags rows where non-default locales merely repeat the default value so you can tell real translations from fallbacks.

What locale format does Pimcore expect? +

Pimcore uses ICU-style locale codes: a bare language such as en or de, or language_COUNTRY with an underscore such as en_US, en_GB, de_DE, and nl_NL, matching the languages configured in your system settings. A hyphenated de-DE is not the same code, and mixing a bare language code with a full locale in the same file creates two separate fields. The tool normalizes and validates each header against this format and warns on inconsistencies.

Is it safe to check a confidential supplier file here? +

Yes. All parsing happens in your browser and nothing is uploaded or stored. You can validate pre-release furniture, industrial, or CPG catalogs and confidential price files without sending data anywhere.