Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-57384

Confluence: Support multiple page versions per language

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Unresolved
    • None
    • None
    • None
    • 1
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

      (related to I18n, Internationalization, Localization)

      Requirements

      • Pages should be able to have multiple versions per language.
      • Search results should display the versions of articles in user's logged-in language. This should apply when using the search from the Service Desk portals as well.
      • When viewing a page, a user should see links to the different language versions (like Wikipedia does.)
      • The translated pages should know which language should be considered the "primary language". The primary language should have a Space-level default and be switchable per page.
      • When a user views a secondary language version, the page should display a warning indicating when the primary version has been updated more recently (i.e. "This page may no longer be current").
      • Admins should be able to see a list of pages which have either not yet been translated into a given locale (e.g. "How to Cook Tacos" is available in English but not Japanese) or have had updates to the primary version.
      • Provide API hooks when a translated page was updated, along with change list (e.g. to facilitate marketplace integration of translation services.)
      • Admins should be able to define locale fallbacks at the space-level, for example, "Simplified Chinese" falls back to "Traditional Chinese" if available, otherwise falls back to "English" (meaning that Chinese users will see English content if the Chinese version isn't available.)
      • Ideally, URLs for other language versions would use the same slug as the primary version, could be something like /my-blog-post?lang=en and /my-blog-post?lang=fr

      Wikipedia should be considered a reference for this functionality. There is also a requirement doc from 2006 here https://confluence.atlassian.com/pages/viewpage.action?spaceKey=DISC&title=Translation+of+content which is still relevant.

      Current Workarounds

      Currently, the recommended solution is to make multiple Confluence Spaces, one for each language. This approach is fraught with problems, for example, since one Service Desk can only be linked to one Confluence space, you effectively can't use Service Desks in multiple languages with Confluence.

      Note about Marketplace

      The related tickets CONFCLOUD-1076 / CONFSERVER-1076 were closed 5 years ago with a note saying this would be handled by the marketplace, However, in 5 years the marketplace has not produced a tenable solution in either the cloud or server versions.
      There are some translation management solutions such as Appfusions (http://www.appfusions.com/display/LNGOTKC/Home) however these are not substitute for the core issue here, which is that Confluence lacks the proper datastructure. If Atlassian makes the proper datastructure (described above) then it will facilitate more translation solutions (e.g. human, machine, etc) being made available on the marketplace, especially if API hooks are made when content changes.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              f80e4f11602e Johnny Shields
              Votes:
              48 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

                Created:
                Updated: