Globalize your On Demand Business

The site is now ready to be deployed on a Domino server -- first to content providers, and then to users. Users will access this site via the Web or Notes network. Content providers will access the site via Notes. Content providers can now start working on the creation of new documents or on updating already existing documents.

How content providers create translatable or global documents
Content providers create documents in synchronized databases the same way they create documents in any database. The only difference is that the documents contain hidden fields that are used by the Synchronizer. If the content provider does not need to change the document's translation status, he or she does nothing more than create the document and save it. The Synchronizer will take care of the rest when it runs. However, if site designers or content providers do not want Translatable documents to be viewed by users in other languages until those documents have been translated, they have several options:

• The site developer can mark the forms that create the documents as Local, to prevent the Synchronizer from copying documents created with these forms to the other localized databases for the site, where users could see them in their untranslated state. After the document is translated, the content provider or Web site manager can change the status to Translatable, using one of the Synchronizer agents.
• Another option is for the developer to design the application in such a way that it prevents documents from being published until they are marked as translated.
• The content provider can change the status of a Translatable document to Local, and then after the document is translated, change it back to Translatable.

Translation workflow
The translation step is simply a matter of editing (translating) the individual language documents that have been created by the Synchronizer agent. Many scenarios for this step are possible. It is up to site designers and managers to decide on the workflow and approval process that makes the most sense in any given situation.

Marking documents as translated
In order for a document to be recognized as translated, the field $Lng_State must be set to 1. This should be done only when translation is complete (any extra workflow required to achieve this, such as approval states, is up to the database designer). It is advisable for developers to add action buttons in an untranslated view or in a translator-specific form in order to facilitate the setting of the $Lng_State field. When the translator completes the translation of the document, he or she can simply click the button, and the field will be updated.

Running the Synchronizer
Whenever new documents are added to a site, the Synchronizer must run on the site databases. The Synchronizer is an agent that can only run from the database selected when the synchronized databases were built. A Web site manager can run the Synchronizer manually, but running it at a scheduled time is usually more convenient. To specify a schedule for the Synchronizer, open the agent in Notes (it's called either SynchronizeUnilingual or SynchronizeMultilingual) and specify a frequency in the "When should this agent run?" dropdown box. Click Schedule to specify the time. You can also run the Synchronizer manually. Here is a step-by-step breakdown of what the Synchronizer does when it runs:

1. It copies any new Translatable documents to other language versions and gives them the state
   "Untranslated." In the case of unilingual databases, it copies documents to the appropriate language databases.
2. If the original version of an existing Translatable document has changed, the Synchronizer does one of the following:
   1. If a companion translation document has the state "Untranslated" or "Translated," it changes the state to "Modified."
   2. If a companion translation document has the state "Modified," it does nothing.
   3. It copies new or changed Global documents to other unilingual language databases. In a multilingual database, the Synchronizer simply adds the IDs for the other languages to the document's $Language field. This has the effect of causing the original document to be displayed, untranslated, to all users, no matter which language they have chosen to use.
3. The Synchronizer does nothing to Local documents, unless they were originally Global or Translatable. In that case, it marks the corresponding documents in the other synchronized databases as Local. Note that the Synchronizer will know this document exists and will track it in the Web Reporting database for the site. This way, a Web site manager can know of the document's existence and consider getting the status of that document changed.
4. Finally, it removes any documents that have been marked for deletion. An agent called "MarkDeleted" is added to all synchronized databases to help ensure that documents are not deleted by mistake, since deleting a single synchronized document could break the logic of the application. If the content provider wants to remove a document, he or she runs this agent on the original version of a Translatable document. The MarkDeleted agent will set the document's state ($Lng_State) to "deleted." The next time the Synchronizer runs, it will delete all the language versions of the document, and then the original. What happens if the MarkDeleted agent is not run on a Translatable document that is deleted? When the original version of the Translatable document is deleted, the unlinked translated versions of the document will remain in the database(s). If a translated version of the document is deleted, the document will be created again (as untranslated) the next time the databases are synchronized.

Continue to "Creating a multilingual database with Domino Designer 6"