Translations >  Documentation >  Import documentation  

Display all Hide all

This function is used to integrate all the paragraphs of a documentation previously extracted in the form of an XML file. The main objective is to enable the reintegration after translation of said documentation with software designed to translate XML files.

The integration is performed from a default xml directory, created, if it does not exist, in the documentation directory defined by the DIRDOC parameter.

The files need to have previously extracted by the documentation workbench or documentation extraction function.

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

Entry screen

Presentation

The directory where the documentation to be integrated can be found is entered in the screen, along with a few options. Following this, the files present in the directory are read and integrated.

Close

 

Fields

The following fields are present on this tab :

Selections

  • Directory (field REPERT)

It specifies the directory from which the documentation import will be carried out, remembering that the field helps will be recovered from the corresponding FLD sub-directory, and the linked files to the FILE sub-directory, provided that they contain the language code chosen in their names..

The DIRDOC user parameter is used by default to select this directory.

The extraction directory can be entered under these 4 different formats:

  • Locally on a client workstation: #@C:\TEMP
  • On the application server. Ex: /app/produits/solution/DOSSIER/tmp
  • On a distant server. Ex : aydaix05:2050@/app/produits/solution/DOSSIER/tmp
  • On a volume of the application server. Ex: [TMP]/repertoire_personalise

Warning: The use of volumes is only possible if the tree structure of the volume is included in the tree structure defined in the SANDBOX so that the Runtime can allow Reading/Writing in this directory.

If the language is entered, a control will be performed to check that the language defined in the files that have been found is the same.
  • Field helps (field HLPFLD)

If this box is checked, the field documentation is also processed.
  • Linked files (field HLPFIL)

If this box is checked, the field helps relating to the function or object documentation that are also processed are included. To find out which field helps need to be processed, the screens associated with the corresponding documentation paragraphs can be explored.

Import

  • Import of new paragraphs (field NEWFLG)

It authorizes the import of new paragraphs.

  • For all the groups (field ALLCREGRP)

 

Close

 

Error messages

The only error messages are the generic ones.

Tables used

SEEREFERTTO Refer to documentation Implementation

Appendix: format of the files created

The format of the XML file of the function or object documentation, as it can be found in the xml directory, is as follows:

  • a standardized xml header,
  • a DOC tag with the TYPE and NAME attributes (that define the type and code of the documentation),
  • inside the DOC tag, for each paragraph, a PAR tag with the LAN, LEV, SUBLEV, PAR, MSK, STY, VLDDAT, VLDFLG, ACT and MOD attributes (that define the language, level, sub-level, paragraph code, screen, style, validity date, validity flag, activity code and module),
  • inside the PAR tag, a TIT tag is given for the title of the paragraph (if any),
  • inside the PAR tag, an HTML tag contains the text of the paragraph in XHTML format.

The field documentation files are located in the FLD sub-directory of the xml extraction directory. The format is as follows:

  • a standardized xml header,
  • an FLD tag with the NAME, LAN, MOD, GEN, LNKHLP, LNKORD, CREDAT, UPDDAT attributes (that define the name, language, module, generic attribute of the documentation, linked help, link, creation date and modification date),
  • Inside the FLD tag, an HTML tag contains the text of the paragraph in XHTML format.

The files linked to a documentation are located in the FILE sub-directory of the xml extraction directory. The name of the file is constructed in the following fashion:

COD_LAN_TYP_LEV_SUBLEV_LIG_NOMFICHIER_LGCLE.EXT, where:

  • COD_LAN_TYP_LEV_SUBLEV_LIG is generated from the the key of the linked file in the ADOCBLB table (this aims at ensuring the name unicity).
  • LGCLE contains the length of the previous key in order to be able to correctly extract the documentation code.
  • NOMFICHIER and EXT correspond to the name of the file (name and extension) if it is mentioned in the ADOCBLB table, or to a name composed of "IMG" characters, followed by the line number on 3 characters (prefixed with zeros, if necessary), then followed by the ".jpg" extension.