Lock translated tags or blocks of code in Dreamweaver

In most cases, you want a translator to change the markup so that Dreamweaver can display it, but you want to save the original markup, not the changes. For such cases, Dreamweaver provides special XML tags in which to wrap translated content and to refer to the original code.

When you use these XML tags, the contents of the original attributes are duplicated in Code view. If the file is saved, the original, untranslated markup is written to the file. The untranslated content is what Dreamweaver displays in Code view.

The syntax of the XML tags is shown in the following example:

 <MM:BeginLock translatorClass="translatorClass" ¬ 
type="tagNameOrType" depFiles="dependentFilesList" ¬ 
Translated content 

The values in this example have the following significance:

  • The translatorClass value is the unique identifier for the translator; it is the first string in the array that the getTranslatorInfo() function returns.

  • The tagNameOrType value is a string that identifies the type of markup (or the tag name that is associated with the markup) that is contained in the lock. The string can contain only alphanumeric, hyphen (-), or underscore (_) characters. You can check this value in the canInspectSelection() function of a custom Property inspector to determine whether the Property inspector is the right one for the content. For more information, see Creating Property inspectors for locked content. Locked content cannot be inspected by the Dreamweaver built-in Property inspectors. For example, specifying type="IMG" does not make the Image panel appear.

  • The dependentFilesList value is a string that contains a comma-separated list of files on which the locked markup depends. Files are referenced as URLs, relative to the user’s document. If the user updates one of the files named in the dependentFilesList string, Dreamweaver automatically retranslates the content in the document that contains the list.

  • The encodedOriginalMarkup value is a string that contains the original, untranslated markup, encoded using a small subset of URL encoding (use %22 for ", %3C for <, %3E for >, and %25 for %). The quickest way to URL-encode a string is to use the escape() method. For example, if myString equals '<img src="foo.gif">', escape(myString) returns %3Cimg%20src=%22foo.gif%22%3E.

The following example shows the locked portion of code that might be generated from the translation of the server-side include <!--#include virtual="/footer.html" -->:

 <MM:BeginLock translatorClass="MM_SSI" type="ssi" ¬ 
depFiles="C:\sites\webdev\footer.html" orig="%3C!--#include ¬ 
<!-- begin footer --> 
[<A TARGET="_top" HREF="/">home</A>] 
[<A TARGET="_top" HREF="/products/">products</A>] 
[<A TARGET="_top" HREF="/services/">services</A>] 
[<A TARGET="_top" HREF="/support/">support</A>] 
[<A TARGET="_top" HREF="/company/">about us</A>] 
[<A TARGET="_top" HREF="/help/">help</A>] 
<!-- end footer --> 

Creating a translator that locks code inside a script tag can cause the translator to fail. For example, suppose you have the following code:

 <script language="javascript"> 
function foo() { 
alert('<bean:message key="show.message"/>'); 
// --> 

Then you create a translator for the bean:messagestruts tag, the translator fails because you are creating a MM:BeginLock section inside a MM:BeginLock section. A workaround is to create a JSP wrapper around the bean:message tag that uses regular JSP tags like <%= My_lookup.lookup("show.message") %>. This causes your translator to skip this code, and the translation succeeds.