Each label has its own XWiki tags object.

• Page labels are set as tags on the document
• Space labels are set as tags on the space home page
• Attachment labels are dropped

In Confluence, a label belongs to a user. We drop this information.

An XWiki space and all its children

often a root space, though not necessarily if the "root space" parameter of the migrator is used

The confluence space key is, by default, translated to a XWiki entity name, following the XWiki page name validation, at the root of the wiki or in the space set in the "root space" parameter.

Note: A confluence space is not the same thing as an XWiki space.

• A confluence space is something at the root of the instance that contains a document tree, among other things
• A XWiki space is just one level in the tree and is not necessarily at the root

Confluence users might be confused by this subtle semantic difference and could cause misunderstandings between us and the clients.

Documents are migrated as XWiki WebHome documents in their own space.

Their name is built from their title in confluence (optionally and by default converted to a valid name in the page naming strategy of XWiki).

Content marked as deleted, archived or draft is not imported. If the locale parameter is set, it will be used for the locale of all imported documents.

These properties will be set from the Confluence page object property:

• The parent
• The revision
• The revision comment

The creation author, the creation date and the title of the document are set from the revision author, the revision date and the title present in the Confluence Page object.

Note: the "Preserve version" output filter stream parameter needs to be set to true for dates to be kept after migration, or the document date will be set to the time at which the document was migrated. The creation author can also be overridden using an output filter stream parameter. Output filter stream parameters are hidden from the Confluence Migrator Pro UI.

For the content, the confluence syntax are translated into XWiki syntax, including macros. Some macros need special handling and  are imported in a specific way (especially if for some Confluence macro named X, there exists a XWiki macro named X that does not do the same thing. Then X is renamed to a macro Y that implement X with similar functionality as in Confluence, either in XWiki Standard or in the Pro Macros).

At the time of writing, title is set to the blog space name, postsLayout is set to "image" and is displayType is set to "paginated".

If the actual attachment file is not found in the export package, the attachment won't be imported at all.
The attachment size is taken from the confluence export XML file if present, fallback to the actual file content size if not found.

Confluence XML 9.78.0+ Attachments history is imported.

All confluence object has an integer id. This id isn't kept in XWiki. When applicable, its key (for spaces) or title (for documents) is used instead and converted (using page name validation for document and space names).

If the "Store Confluence details" is set to true, confluence detail are stored in a Confluence.Code.ConfluencePageClass object (id : the page id, url: the reconstructed confluence url, space: the space key).

The way it works in Confluence: in the same document, you add macros named french, or english (Ieach supported language probably has a macro of its name, unprefixed). Then, when you display the document, only the parts matching your language are displayed. There's an "All" mode that displays everything.

If the Translated content support is enabled (which is the default; see input-parameters), pages containing different languages are converted to translated XWiki documents. If the support is disabled,  all the content is migrated, leaving these language macros as is (with a confluence_ prefix by default), in one document.