Internationalisation & Localization

Building a community that welcomes users from different linguistic and cultural backgrounds requires careful planning for Internationalization (I18n) and Localization (L10n).

  • Internationalization (I18n): Designing the UNA platform and its apps so they can be adapted to various languages and regions without engineering changes. UNA core is built with I18n principles.
  • Localization (L10n): The actual process of adapting the interface, content presentation, and potentially community structure for a specific language and region (locale).

As an Operator, you have several tools and strategies within UNA Studio and beyond to manage localization effectively. The Polyglot app is central for translating the user interface and system messages, but a full localization strategy often involves community organization decisions as well.

Core Distinction: UI Translation vs. Content Localization

It is absolutely critical to understand this difference:

  • UI/Interface Translation (Handled by Polyglot): This involves translating the static text elements of the UNA software itself – button labels, menu items, system messages, form field names, site emails, etc. The Polyglot app (Studio > Polyglot) is the primary tool for managing these translations.
  • Content Localization (Handled by Community Structure & Users): This refers to the language of the user-generated content – the posts, comments, articles, group descriptions, etc., created by your community members. Polyglot does NOT automatically translate user-generated content. Managing content in multiple languages requires specific community organization strategies, discussed later in this guide.

UI Localization: Using the Polyglot App

The Polyglot app (Studio > Polyglot) is your command center for managing the translated interface elements and regional settings.

Managing Language Packs

Adding support for a new interface language requires installing a Language Pack, which is essentially a specialized UNA app containing translated text strings.

  1. Adding Languages:
    • Go to Studio > App Store.
    • Search for available language packs (e.g., "Spanish Language," "German Language").
    • Install the desired language pack(s).
  2. Setting Default Language:
    • Once installed, navigate to Studio > Polyglot > i18n Settings.
    • Select the primary language for your site from the Default Language dropdown menu. This affects guests and new users.
  3. Removing Languages:
    • Go to Studio > App Store.
    • Find the language pack app, deactivate it, and then use the Uninstall option. Caution: This removes all translations for that language.

i18n Settings (Regional Formats & Defaults)

(Studio > Polyglot > i18n Settings)

This tab controls site-wide defaults related to language display and regional formats:

  • Default Language: As mentioned, sets the primary site language from installed packs.
  • Substitute (during compilation) missing translations with english ones: (Recommended: Keep Checked) Ensures that if a specific piece of text isn't translated into the current language, the English version is shown instead of an unhelpful system key (e.g., _EXAMPLE_KEY).
  • Date Format: Customize how dates appear (e.g., D MMM YYYY -> '14 Apr 2025').
  • Time Format: Customize how times appear (e.g., HH:mm -> '15:30').
  • Date And Time Format: Customize the combined date and time display.
  • Use 'time ago' format for dates less than this number of seconds: Set threshold for using relative time display ("5 minutes ago") vs. absolute date/time.
  • Use 24h Format For Calendar input: Determines if calendar time inputs use 24-hour format.

Click Save after adjustments.

Text Keys (Translating the Interface)

(Studio > Polyglot > Text Keys)

This section lists every piece of interface text defined by the core system and installed modules, identified by unique Keys.

  • Functionality: Allows Operators to find specific text strings (filter by Module or Search) and provide translations for each installed language.
  • Editing: Click the pencil icon (✏️) next to a key to open the editor. Enter the appropriate translation for each language active on your site.
  • Adding/Deleting Keys: While possible (Create New Key, X icon), adding keys is usually for developers, and deleting standard keys is strongly discouraged as it can break the interface.

This is where the bulk of UI translation work happens.

Email Texts (Translating System Emails)

(Studio > Polyglot > Email Texts)

Manage the content (Subject and Body) of automated system emails (registration, notifications, etc.).

  • Editing: Click the pencil icon (✏️) to edit the Subject and Body for each email template in every installed language.
  • Macros: Use macros like {site_name}, {recipient_name}, {email_footer} which are dynamically replaced when the email is sent. The available macros depend on the specific email context.

Email Template (Styling System Emails)

(Studio > Polyglot > Email Template)

Control the shared visual header and footer that wraps around all system emails.

  • Visual Editor: Use the editor to add your site logo, adjust colors, and include standard links (e.g., Contact Us, Privacy Policy, Unsubscribe).
  • Consistency: Ensures all system emails have consistent branding and structure.

Content Localization Strategies (Beyond Polyglot)

As Polyglot only handles the interface, managing user-generated content in multiple languages requires a deliberate strategy implemented through community structure and user behavior. Here are common approaches:

  1. Single Site, Mixed Languages (Simplest):

    • How it Works: Allow users to post content in any language within the main, shared community spaces (groups, forums, timeline). The interface adapts via Polyglot, but content remains in its original language.
    • Pros: Easy to set up, low administrative overhead.
    • Cons: Can lead to mixed-language discussions that are hard to follow, difficult content moderation if staff don't speak all languages, potential SEO challenges.
    • Best For: Communities where multilingualism is expected and users can generally navigate mixed content, or where one language heavily dominates.

  2. Language-Specific Contexts (Groups/Spaces):

    • How it Works: Create parallel Groups or Spaces dedicated to specific languages (e.g., "General Discussion (English)," "General Discussion (Spanish)"). Encourage users to join and post content within the context corresponding to their language.
    • Pros: Keeps discussions language-specific and easier to follow/moderate, clearer community structure for users.
    • Cons: Duplicates community structure, can fragment the user base, requires clear naming conventions.
    • Best For: Sites with distinct, active language groups where separate discussion areas are beneficial.
    • Operator Tasks: Create the language-specific groups/spaces; guide users via site announcements or descriptions.

  3. Encourage Content Language Tagging:

    • How it Works: Instruct users to use specific Hashtags or Labels (if configured for user application, which is less common) to indicate the language of their content (e.g., #MyPost #English, #MiPost #Español).
    • Pros: Flexible, doesn't require duplicating structure.
    • Cons: Relies heavily on user discipline, filtering based on these tags might require customization or specific module features.
    • Best For: Technically savvy communities or situations where dedicated spaces aren't desired.

  4. Separate UNA Instances:

    • How it Works: Set up completely separate installations of UNA CMS, each configured with a different default language and potentially hosted on country-specific domains (e.g., mysite.com, mysite.de, mysite.fr).
    • Pros: Provides the most tailored experience per locale, simplifies compliance with vastly different regional laws/regulations, allows independent moderation teams and configurations.
    • Cons: Highest cost and complexity (separate hosting, databases, user bases, updates), no cross-site interaction between language communities by default.
    • Best For: Large-scale operations targeting distinct geographical markets with significantly different legal requirements, content policies, or community focuses.

Developer Considerations: Creating New Language Packs

While Operators typically install existing language packs, creating a pack for a language not yet available involves development:

  • The process usually involves copying the files of an existing language pack (like English), translating all the text keys found within its PHP and configuration files, and packaging it as a new UNA app installable via the App Store.
  • This requires familiarity with UNA's file structure and translation key syntax. Detailed steps are available in the developer documentation (Creating new language module).

Compliance, Legal & Regional Considerations

Localization goes beyond just language:

  • Data Privacy Laws (GDPR, CCPA, etc.): Regulations vary significantly by region. If operating separate instances or targeting specific regions, ensure each configuration complies with local data privacy laws regarding data storage, user consent, and data access rights.
  • Terms of Service & Privacy Policy: These legal documents should ideally be available in the languages of the primary user bases and may need adjustments based on regional legal requirements.
  • Content Moderation Policies: Cultural norms and legal restrictions on content can differ. Moderation guidelines may need to be adapted for different language communities or regional instances.
  • Payment Systems: Ensure chosen payment gateways support currencies and regulations relevant to your target regions.

Best Practices for Operators

  • Define Your Strategy: Decide early on how you will handle multilingual content (mixed, separate spaces, separate sites) based on your community goals and resources.
  • Install Languages Early: Add necessary language packs during the initial site setup if possible.
  • Utilize Polyglot Fully: Translate UI keys and system emails thoroughly for installed languages. Keep the "substitute missing" option enabled.
  • Set Regional Formats: Configure appropriate date/time formats in Polyglot's i18n Settings.
  • Guide Users: Clearly communicate your site's language policy and how users can find/post content in their preferred language (e.g., direct them to language-specific groups).
  • Multilingual Staff: If feasible, have administrators or moderators who speak the primary languages of your community.
  • Test Thoroughly: View the site as a user with different language preferences selected to catch untranslated elements or formatting issues.

Conclusion

Effectively localizing your UNA community involves translating the user interface via the Polyglot app and implementing a clear strategy for managing user-generated content in multiple languages. Operators use Studio to install language packs, translate UI text keys and system emails, set regional formats, and configure the community structure (like language-specific groups) to support their chosen content localization approach. Considering compliance and regional differences is also crucial for creating a welcoming and legally sound global community.

On This Page