Configure the incremental localization process

The incremental localization process allows you to start the localization process without having all the objects in the Authoring:done status (or the equivalent status in your deployment).

Important: The incremental localization process is applicable only to the sequential localization model.
Note: If you localize individual topics and images, IXIASOFT strongly recommends that you implement the incremental localization process.

Normally, the map and all its children should be in the Authoring:done status (or the equivalent in your deployment) before you can start the localization process. When you implement the incremental localization process, you define what other statuses are acceptable before the objects can be sent to the Localization cycle. For example, instead of having the map, the topics, and all the images in Authoring:done before starting the localization process, you can configure it so you can begin the localization process even if some of the topics are still in Authoring:work.

To incorporate the incremental localization process in the workflow, you need make the following changes in the configuration files:
  • A new status called Localization:do not translate must be added to the configuration files which define the statuses available for each object. The Localization:do not translate status identifies the objects that are not authorized to be translated.
  • In the Localize action in the access rights configuration file, you must define the statuses objects must be set to before they can be sent to the Localization cycle.
  • In the localize_api action in the access rights configuration file, you must define which statuses for each object are set to Localization:tb translated when they are sent to the Localization cycle. All statuses not defined in the localize_api action will automatically be set to Localization:do not translate when they are sent to the Localization cycle.
  • In the Prepare kit action in the access rights configuration file, you define which objects in which statuses are included in the localization kit.

If objects in the Localization:do not translate status are included in the localization kit when it is prepared, DITA CMS automatically adds the translate="no" attribute to the root element of those objects so translation vendors can identify which files are not to be localized, and removes all the ixia_locid attributes from the elements contained in the objects to ensure that they cannot be imported after the localized files are received.

To configure the incremental localization process:

  1. Open the TEXTML Administration perspective by clicking the TEXTML Administration shortcut on the tool bar. If the shortcut is not displayed, follow these steps:
    1. Select Window > Open Perspective > Other
    2. Click TEXTML Administration.
    3. Click OK.
  2. In the TEXTML Administration view, double-click the server. If your server is not displayed in the view, you must add it to the view.
  3. When the Connect as dialog opens, type your username and password and click OK.
  4. Double-click the name of your docbase to open a connection to the Content Store.
  5. Locate the status.xml file in the repository's /system/conf collection.
  6. Right-click the file and click Check Out.
  7. Double-click the file to open it in the editor.
  8. In the section <collection="/content/localization/" >, add the do not translate state (do not alter the name) by copying the following lines and pasting them inside the states element.
    <state level="0" name="do not translate" type="work">
    	<lockable>
    		<objtypes>
    			<type>none</type>
    		</objtypes>
    	</lockable>
    	<milestone/>
    	<nextStates/>
    </state>

    Therefore, it should look like the following example:

    <cycle collection="/content/localization/" description="" initial="false" lastworkcycle="false"
    	level="0" name="Localization" type="localization">
    	<nextCycle/>
    	<states>
    		<state level="0" name="do not translate" type="work">
    			<lockable>
    				<objtypes>
    					<type>none</type>
    				</objtypes>
    			</lockable>
    			<milestone/>
    			<nextStates/>
    		</state>	
    		<state initial="true" level="0" name="tb translated" type="work">
    			<lockable>
    				<objtypes>
    					<type>image</type>
    				</objtypes>
    			</lockable>
    			<nextStates>
    				<next>in translation</next>
    			</nextStates>
    		</state>
    		
    		[ . . . ]
    
    	</states>	
    </cycle>	
  9. Repeat the previous steps you completed for status.xml to add the new state to the following files:
    • map_status.xml
    • topic_status.xml
    • image_status.xml
  10. Save, close, and check in the files.
  11. Open the Access Manager window.
    1. Right-click the Content Store.
    2. Click DITA CMS.
    3. Click Manage Access.
  12. In the Actions column, click Localize and click Lock to configure the localization process for DITA CMS.
  13. For each condition, define which objects in which statuses can be sent to the Localization cycle:
    1. In the Conditions column, click a condition.
    2. Click the arrow next to an object to expand the list of cycles.
    3. Click the arrow next to Authoring to expand the list of statuses.
    4. Select each status which is authorized to be sent to the Localization cycle.
    5. Repeat for each object.
    6. Repeat for each condition.

    For example, if you wanted to allow the map and all its children to be able to be sent to the Localization cycle regardless their status, you would select all the statuses for all the objects.

  14. In the Actions column, click localize_api to define which statuses are set to Localization:tb translated (or the equivalent status in your deployment) when objects are sent to the Localization cycle. All other statuses will be set automatically to Localization:do not translate.
  15. For each condition, define which statuses can be sent through the localization process:
    1. In the Conditions column, click a condition.
    2. Click the arrow next to an object to expand the list of cycles.
    3. Click the arrow next to Authoring to expand the list of statuses.
    4. Select each status for which you want to authorize to be translated.
    5. Repeat for each condition.

    For example, if you only wanted objects in Authoring:done and Authoring:accepted (or the equivalent in your deployment) to be translated, you would select only those statuses. This means that objects in the Authoring:done and Authoring:accepted statuses will be set to Localization:tb translated when they are sent to the Localization cycle. All objects in any other status will be set to Localization:do not translate.

  16. In the Actions column, click Prepare kit.
  17. For each condition, define which objects in which statuses are included in the localization kit:
    1. In the Conditions column, click a condition.
    2. Click the arrow next to an object to expand the list of cycles.
    3. Click the arrow next to Localization to expand the list of statuses.
    4. Select each status you want included in the localization kit.
    5. Repeat for each object.
    6. Repeat for each condition.

    For example, if you only want to include the objects that you want translated in the kit, you would select only Localization:tb translated (or the equivalent in your deployment).

  18. In the Actions column, click Retranslate.
  19. For each condition, define which objects can be retranslated:
    1. In the Conditions column, click a condition.
    2. Click the arrow next to an object to expand the list of cycles.
    3. Click the arrow next to Localization to expand the list of statuses.
    4. Select each status you want included in the localization kit.
    5. Clear the checkbox beside do not translate.
    6. Repeat for each condition.
    Tip: It is recommended to selected all the statuses, except do not translate.
  20. When you are done, click CheckIn Document to commit the changes to the access rights back to the Content Store.
  21. Test your implementation. If it is not behaving as expected, verify the access rights are configured correctly for each object and status in each condition.
  22. Inform users of the changes.
    The changes will be applied automatically once users close and then reopen their DITA CMS. Users can also apply the changes without restarting their DITA CMS by clicking DITA CMS > Synchronize Configuration.