Describe the problem to be solved
Grist's UI is well localized through the community translations process and Weblate.
However, when a formula fails, the cell shows a raw Python exception (#TypeError, #ValueError, #ZeroDivisionError…) and the tooltip / expanded view shows the untranslated Python message, e.g. TypeError: unsupported operand type(s) for /: 'float' and 'str'.
The people most likely to encounter these errors are non-technical users entering data, not the person who wrote the formula. For non-English speakers (a common Grist audience, e.g. French public administrations and associations), the message is doubly opaque: technical and in a foreign language. It could be hard to tell whether the problem comes from their input or from the document itself.
Formula-level workarounds (try/except, IFERROR()) are not acceptable here: when they suppress the error state itself (no pink highlighting, no #Error indicator, ISERROR() no longer detects it), so a real problem gets silently masked. The goal is the opposite: keep the error fully visible as an error, but make it understandable.
Describe the solution you would like
A dual-message presentation — a sort of exception wrapper that carries both the original and a translated message:
- The short cell indicator keeps the canonical exception name (
#TypeError), which is a stable, language-independent identifier.
- In the tooltip/detail view, if a translation is available for this exception type (or message pattern), show the localized, user-friendly explanation and the original Python message below it. The original must never be replaced or hidden: technical users rely on the exact wording for debugging and for searching the web / Python docs.
- If no translation is available, behavior is unchanged (original message only).
Since errors already reach the client in a structured form (["E", exceptionName, message, details]), this could be implemented client-side without modifying the sandboxed data engine or the stored data.
Instance-level translations
Beyond a common base of translations for frequent exceptions (TypeError, ValueError, KeyError, ZeroDivisionError, circular references…) managed via Weblate, it would be useful to let self-hosted instances provide or override translations locally — e.g. a mounted JSON/YAML mapping exceptionName (or a message pattern) → localized text per locale. This would let an organization tailor wording to its audience and cover additional cases without waiting for upstream releases.
Alternatives considered
try/except / IFERROR() in formulas: rejected — they destroy the error state and highlighting, hide genuine problems, and must be repeated in every formula.- Translating messages inside the Python engine: rejected — it would bake a locale into computed values and complicate the sandbox; presentation-layer translation keeps data locale-neutral.
Happy to discuss about it.
I produced a PoC here: https://claude.getgrist.com/fQh2N113Jvvq/Exemples-dexceptions-de-formules/p/2
Describe the problem to be solved
Grist's UI is well localized through the community translations process and Weblate.
However, when a formula fails, the cell shows a raw Python exception (
#TypeError,#ValueError,#ZeroDivisionError…) and the tooltip / expanded view shows the untranslated Python message, e.g.TypeError: unsupported operand type(s) for /: 'float' and 'str'.The people most likely to encounter these errors are non-technical users entering data, not the person who wrote the formula. For non-English speakers (a common Grist audience, e.g. French public administrations and associations), the message is doubly opaque: technical and in a foreign language. It could be hard to tell whether the problem comes from their input or from the document itself.
Formula-level workarounds (
try/except,IFERROR()) are not acceptable here: when they suppress the error state itself (no pink highlighting, no#Errorindicator,ISERROR()no longer detects it), so a real problem gets silently masked. The goal is the opposite: keep the error fully visible as an error, but make it understandable.Describe the solution you would like
A dual-message presentation — a sort of exception wrapper that carries both the original and a translated message:
#TypeError), which is a stable, language-independent identifier.Since errors already reach the client in a structured form (
["E", exceptionName, message, details]), this could be implemented client-side without modifying the sandboxed data engine or the stored data.Instance-level translations
Beyond a common base of translations for frequent exceptions (
TypeError,ValueError,KeyError,ZeroDivisionError, circular references…) managed via Weblate, it would be useful to let self-hosted instances provide or override translations locally — e.g. a mounted JSON/YAML mappingexceptionName(or a message pattern) → localized text per locale. This would let an organization tailor wording to its audience and cover additional cases without waiting for upstream releases.Alternatives considered
try/except/IFERROR()in formulas: rejected — they destroy the error state and highlighting, hide genuine problems, and must be repeated in every formula.Happy to discuss about it.
I produced a PoC here: https://claude.getgrist.com/fQh2N113Jvvq/Exemples-dexceptions-de-formules/p/2