Appearance, Language, and Translations
Configure visual preferences, language, region, and translation settings.
Appearance and language settings affect how the app looks and how dates, language, and translated text appear.
Review these settings before inviting a larger team or sharing public pages in a new market. Small formatting differences can affect finance documents, scheduling, and customer-facing copy.
Appearance
Appearance settings can control theme and visual preferences where available.
Use Settings > Appearance to choose theme and layout preferences such as sidebar style and density.
Appearance settings are usually personal or workspace presentation settings, not data settings. If a teammate sees a different layout, confirm whether the setting is personal, role-based, or workspace-wide before troubleshooting data.
When changing density or sidebar style, check data-heavy pages such as CRM tables, finance lists, task boards, and reports. A compact layout can help power users but may make long labels harder to scan.
If support screenshots do not match what another user sees, compare appearance preferences before assuming the user is on the wrong page. Sidebar style, density, theme, and role permissions can all change what the interface looks like.
Language and Region
Language, date, and regional settings help the app display information in the format your team expects.
Use Settings > Language to enable or disable workspace translation overrides.
Review language and region before setting up scheduling, payroll, timesheets, and finance due dates. These areas are sensitive to timezones, date formats, and week-start assumptions.
Before Changing Language Settings
Confirm whether the change is for one user, the whole workspace, or customer facing pages. A workspace-wide language change can affect internal navigation, email templates, public forms, checkout, booking pages, and finance documents.
Notify admins before changing workspace-wide language settings. They may need to review saved templates, customer emails, public page copy, and translated labels before the change reaches customers.
Translations
Translation settings are useful when your workspace needs customized labels or localized customer-facing copy.
Assign ownership for translation changes. Custom labels should be reviewed after product updates, new modules, template changes, and public-page changes so users do not see outdated or inconsistent wording.
Translation Safety
Keep translated labels short where they appear in navigation, table headers, buttons, and compact cards. If a translation needs more explanation, put the detail in help text or template copy rather than stretching a small UI label.
Test Changes
After changing appearance, language, or translation settings, refresh the app and check a dashboard, a table page, a finance document, and a public page. This confirms the change works in both internal and customer-facing areas.
Also test compact areas such as buttons, table headers, sidebar items, and mobile-width public pages. Long translated labels can overflow where normal sentences would still read well.
Translation Change Checklist
Before rolling out translated copy:
- preview internal navigation and table headers
- preview finance, document, booking, and checkout public pages
- test the longest expected customer name or document title
- confirm support and recovery instructions still make sense
- assign someone to review labels after product or template changes
Troubleshooting Display Differences
If two users see different language or layout, compare personal appearance settings, browser locale, workspace language, permissions, and whether both users refreshed after the change.
If public pages still show older text, check the source template or public-page copy. Translation settings do not replace every custom sentence written inside a form, booking page, finance document, or email template.