Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-18477

Default locale is not always set for document translations


    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 12.10.5
    • Fix Version/s: None
    • Component/s: Old Core
    • Labels:
    • Difficulty:
    • Similar issues:


      The default locale field is not always set on document translations:

      • it is empty for translation pages created by the user because the save action doesn't set it and the edit form doesn't include this field when editing document translations
      • it may be set for translation pages that are part of an XWiki extension because the XAR Maven plugin used to build the extension has a rule to enforce it

      One reason for not setting the default locale on document translations is probably to avoid the need to keep all document translations synchronized. You can easily end up having different translations of the same document indicating different default locales. It's better to have a single source for the default locale, which is the original document.

      The consequence is that calling getDefaultLocale() on a document translation is not always accurate, i.e. it doesn't return the real default locale. ATM the best is to get the default locale from the original document. This is easy for server side scripts where we have both $doc and $tdoc bindings but it's tedious if you have to use the REST resources: you need to make another HTTP request for the original document in order to get the actual default locale.

      I see 4 options:

      1. make sure we always set the default locale on document translations; this won't prevent inconsistencies between different document translations (which can indicate different default locales) and we still need to handle existing document translations that don't have the default locale set (needs a migration)
      2. modify getDefaultLocale() to return the real default locale by looking at the original document, but it may be seen as a breaking change
      3. introduce a getRealDefaultLocale() but it feels awkward
      4. change the places that call getDefaultLocale() to make sure they call it on the original document, e.g. the page REST resources

      Regarding the page REST resources, there's always the question of whether they should return the raw values or the real values. For instance we currently return the locale not the real locale, which means all clients that want to display/know the actual locale need to fallback on the default locale when the locale is empty. This feels wrong to me.


          Issue Links



              • Assignee:
                mflorea Marius Dumitru Florea
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: