Liquid localization and formatting: dates, numbers, translations and file sizes

Updated Wednesday, October 28, 2026 · Marc Staine

Customers should see labels, dates and numbers in a form they understand. Supportbench adds localization and formatting filters to DotLiquid for that purpose. Use them consistently so a portal used by several customer organizations does not mix hard-coded English labels, ambiguous dates and raw byte counts.

At a glance

For: portal administrators and designers, including people new to Liquid. Applies to: Supportbench Core.

Start here: Settings → Customer Portal → select the portal → Page templates

Start with the practical purpose · Syntax and supported behavior · Example: localize a label and display an article date · Choose a date format deliberately · Test translated labels as part of the customer task · Remove obsolete platform-specific examples · Apply the example in a working portal page · Troubleshoot the common mistakes · Keep the customization understandable

Start with the practical purpose

Formatting changes how a supplied value is displayed. It does not translate an entire article automatically, convert a date into another timezone or change stored measurements. A missing translation or invalid date needs an honest fallback rather than a plausible-looking invented value.

The standard date filter in this DotLiquid implementation uses .NET date-format strings. Older examples using percent codes such as %Y or %B were written for another dialect and should not be copied into current Core templates.

Syntax and supported behavior

Filter	Purpose and important detail
t: "Fallback"	Look up a localized key, using the optional fallback text where appropriate.
tf: value, "name"	Replace one named placeholder in a translation; the default placeholder name is count. Use a key whose configured text contains the intended placeholder.
tp: count	Select the locale plural form and substitute a count. Use the configured translation keys and test the locale’s actual plural forms.
lnumber	Format a numeric value using the portal locale. It changes presentation, not the number’s meaning or units.
ldate	Format a valid date with the locale’s long-date pattern. Null/invalid input produces an empty result; it is not timezone conversion.
format_bytes	Format an integer byte count as a readable size.
format_empty	Display an empty string as a dash. Decide whether a dash is understandable for that field.
date: "yyyy-MM-dd"	Standard DotLiquid date formatting using a .NET pattern. Core’s standard rendering culture is invariant; use ldate for locale-aware long-date output.
default: "Fallback"	Supply a fallback for an absent/empty value according to the filter behavior. Do not use a fallback to conceal an unknown business state.

Example: localize a label and display an article date

<button type="button">{{ "portal.submit" | t: "Submit" | escape }}</button>
{% if sb.article %}
 <p>Updated: {{ sb.article.modified | ldate | escape }}</p>
{% endif %}

The button is a formatting demonstration, not a complete submission action. Preserve the existing functional button and its handlers when applying the localized label. The modified date is an update date, not proof of a completed editorial review.

Choose a date format deliberately

Need	Example
Unambiguous numeric date	date: "yyyy-MM-dd"
Explicit date and 24-hour time	date: "yyyy-MM-dd HH:mm"
Locale long date	ldate
Readable file size	attachment.size \| format_bytes

In .NET patterns, MM represents month and mm represents minutes. A formatting error can therefore display a believable but wrong value. These filters format the supplied date; confirm the underlying field’s timezone semantics before adding a timezone label.

Test translated labels as part of the customer task

Identify the exact label or message and the supported localization key in your portal configuration.
Use the appropriate t, tf or tp signature from the current designer catalog. Keep a meaningful fallback where the filter supports it.
Preview the relevant language and test longer translations, missing keys and the numeric cases used by a plural message.
Check the actual published customer page in that language. Confirm the link or form still performs the same task.

Do not assume that translating navigation also translates the article body. The article object has separate translation availability and default-language link handling.

Remove obsolete platform-specific examples

Current Core guidance does not use default_errors, default_pagination, highlight, highlight_active_tag, json or weight_with_unit. Those older examples depended on a different platform’s form, store or paging objects. Use native portal forms, supplied search paging URLs and the current Supportbench catalog instead.

Apply the example in a working portal page

Open the intended portal’s Page templates with permission to administer communities or the applicable edit override. Choose the page that supplies the object used by your example.
Preserve a copy of the existing template in your change record. Keep the working forms, routes, input names and script hooks; these examples change presentation.
Make the smallest useful edit, then choose Save Changes → Design. Inspect populated, empty and signed-out preview states as relevant.
Check punctuation, long text, optional values and narrow-screen layout. Confirm the result says what you intend, not merely that it renders.
Use Review changes → Publish for the approved design. Then verify the actual portal as the intended customer and check the full task.

Designer preview data is synthetic. A successful preview confirms neither real customer access nor the effect of a server-side workflow. Liquid cannot grant permission, edit a case or fetch arbitrary database records.

Troubleshoot the common mistakes

Problem	Correction
The date format prints strange percent characters	Replace foreign percent-code patterns with supported .NET patterns or use ldate.
A localized date is blank	Check for null/invalid input and the correct source member.
The date is in a different timezone than expected	Formatting is not timezone conversion. Verify the source field and existing portal date handling.
A plural message is wrong	Check configured locale keys, placeholder names and representative count values.
A fallback hides a missing required value	Use an explicit unknown/absent state appropriate to the task instead of an invented default.

Keep the customization understandable

Review language, date and number presentation with the actual customer task. A localized portal should preserve the meaning of a deadline, request state or article instruction, not merely translate isolated words.

Use descriptive local variable names and keep conditions close to the content they control. Record the customer scenario tested when publishing a change. Recheck the template when its source fields, portal role rules or supported language behavior changes.

Was this article helpful?