LogoLogo
Give FeedbackGovStack Home
25Q2
25Q2
  • GovStack
  • Contributing
  • Architecture and Nonfunctional Requirements
    • 2 Introduction
    • 3 GovStack Architecture
    • 4 Building Block Design Principles and Considerations
    • 5 Cross-Cutting Requirements
    • 6 Onboarding Products
    • 7 Standards
    • 8 UX Switching and Handover
    • 9 Other Resources
  • Security Requirements
    • 2 Description
    • 3 Terminology
    • 4 Security Management
    • 5 Cross-Cutting Requirements
    • 6 Standards
    • 7 Authorization Services
    • 8 Additional Security Modules
    • 9 Other Resources
  • GovStack UI/UX Guidelines
    • 1 Version History
    • 2 Description
    • 3 Service design good practice guidelines
      • 3.1 User-centred design
        • 3.1.1.1 Understand needs and requirements
        • 3.1.1.2 Involve others in the design process
        • 3.1.2.1 Test with users
        • 3.1.3.1 Share findings
        • 3.1.3.2 Monitor performance
          • 3.1.3.3 Set up analytics
      • 3.2 Accessibility and inclusion
        • 3.2.1.1 Test for accessibility
        • 3.2.2.1 Involve a diverse user group in the design
        • 3.2.2.2 Support multiple languages
        • 3.2.2.3 Foster a culture of inclusion
      • 3.3 Consistency
        • 3.3.1.1 Use simple language
        • 3.3.2.1 Implement a consistent style guide
        • 3.3.2.2 Use design patterns
        • 3.3.2.3 Use a frontend framework
        • 3.3.3.1 Interoperability
        • 3.3.3.2 Use integrations
        • 3.3.4.1 Work in the open
      • 3.4 Technology choices
        • 3.4.1.1 Choose the right level of security
        • 3.4.1.2 Design for privacy
        • 3.4.2.1 Optimise load times
        • 3.4.2.2 Account for connectivity issues
        • 3.4.3.1 Test across platforms
        • 3.4.3.2 Design cross-channel
    • 4 Design patterns
      • 4.1 Service patterns
      • 4.2 User flows
        • 4.2.1 Register
        • 4.2.2 Authenticate
        • 4.2.3 Asking users for feedback
        • 4.2.4 Find a service
        • 4.2.5 Check a users eligibility
        • 4.2.6 Make an application
      • 4.3 Page templates
        • 4.3.1 Feedback
        • 4.3.2 Perception survey
        • 4.3.3 Satisfaction
        • 4.3.4 Before you start
        • 4.3.5 Service sheet
        • 4.3.6 Asking users for consent
        • 4.3.7 Task list
        • 4.3.8 Asking users for information
        • 4.3.9 Check answers
        • 4.3.10 Outcome
    • 5 Use-case examples
    • 6 References
    • 7 Other Resources
  • Building Blocks
    • About Building Blocks
    • Cloud Infrastructure
    • Consent
    • Digital Registries
    • E-Marketplace
    • E-Signature
    • Geographic Information System (GIS)
    • Identity
    • Information Mediation
    • Messaging
    • Payments
    • Registration
    • Scheduler
    • Workflow
    • Wallet
  • Use Cases
    • Reference Use Cases
  • Public Administration Ecosystem Reference Architecture (PAERA)
    • PAERA
  • Tools
    • Sandbox
  • Release Notes
    • 23Q4
Powered by GitBook

Apache-2.0 license

On this page
  • Identify the languages users speak
  • Make a plan for multilingual support
  • Use simple language
  • Language Detection and Preferences
  • Clear Language switching options
  • Support for right-to-left (RTL) languages

Was this helpful?

Export as PDF
  1. GovStack UI/UX Guidelines
  2. 3 Service design good practice guidelines
  3. 3.2 Accessibility and inclusion

3.2.2.2 Support multiple languages

Was this helpful?

Identify the languages users speak

Analyse user demographics data to determine the languages spoken by your users. This data can be obtained through user surveys, usage data analysis, or from market research. You may also find legislation for languages the government must support.

Read more about .

Make a plan for multilingual support

Consider the feasibility and utility of providing multilingual support. This includes the translation of key content, interface elements, instructions, and forms into the most commonly spoken languages of your user base. Automated translation services can be a cost-effective starting point, but human review is essential to ensure cultural appropriateness and accuracy.

Use simple language

Even in the primary language of the service, avoid using complex jargon and technical terms. Use plain, simple language that can be easily understood by a broad audience. This will also facilitate more accurate translations.

Language Detection and Preferences

Implement language detection based on the user's browser or system settings and offer the option for users to manually set their language preferences.

Use the Accept-Language HTTP header to detect the language preferences set by the user in their browser or device settings. This can give you a default language to serve to the user initially.

Store the user's language preference (in cookies or user profiles) so that you can load the website or app in their preferred language in subsequent visits or sessions.

Clear Language switching options

Options to switch languages are clearly visible and easily accessible across all pages of the service. Users should not have to search or dig deep into settings to find this option. See the design pattern for .

Support for right-to-left (RTL) languages

If you're offering support for languages that are read right-to-left (like Arabic or Hebrew), make sure your user interface can handle that transition seamlessly. This is not just about text direction; UI elements and navigation should also mirror to offer a consistent RTL experience.

Read more about .

using data to make decisions
switching languages
using frontend frameworks