Enabling multilingual support in an MXI file
To enable multilingual support in an MXI file, you need to specify the attribute ismultilingual="true" to load strings from external files. If you want to localize the name of the extension, you can specify a name_resid attribute in the <macromedia-extension> tag. If no corresponding language tag is found for the id, "name_ID", Extension Manager falls back to the name in the name attribute.
<macromedia-extension name="Extension Name" name_resid="name_ID" version="1.0.0" ismultilingual="true" >
<author name="FooBar" author_resid="author_ID"/>
<![CDATA[ Inline Description ]]>
Setting up the folder hierarchy for localized XML files
At the same location as your .mxi file, create a folder with the exact name of your .mxi file and append "Resources" to it. For example if you have an .mxi file named "Calendar.mxi", create a folder named "Calendar.mxi_Resources". In this folder, you add an XML file for each language you are localizing the extension into. Each file will have a two-letter ISO language code followed by an underscore character, and then the two-letter ISO country code in upper case. For example, for English you specify "en_US.xml" and for French "fr_FR.xml".
If your extension needs to install localized files, you may want to create a subfolder for each of the languages. The folder hierarchy should look as follows:
Calendar.mxi - MXI File
en_US.xml - XML File containing English strings
fr_FR.xml - XML File containing French Strings
en_US (Folder Containing English files)
fr_FR (Folder Continaing French files)
Formatting XML for language-specific strings
The Extension Manager looks up localized strings from XML files that you provide for each language. Each XML file should use Adobe's zstring format. Below is an example of the French xml file. The locale (in this case, "fr_FR") should match the locale of the language. Extension Manager looks up the localized strings based on the name="" attribute and subsitutes the localized
strings in the <val> tags. In the following example, we use name_ID for the localized Extension Name, "French Extension Name". And description_ID will be used for the Description displayed when you click the Extension in the Extension Manager.
<?xml version="1.0" encoding="utf-8" standalone="no" ?>
<!DOCTYPE asf SYSTEM "http://ns.adobe.com/asf/asf_1_0.dtd">
<asf locale="fr_FR" version="1.0" xmlns="http://ns.adobe.com/asf">
<val>French Extension Name</var>
<val>French Extension Description. </val>
Installing localized files
To specify that a set of localized files get installed for a particular language, use the xml:lang attribute on the files tag containing files for that language.
<file source="en_US/Jacket.htm" destination="$dreamweaver/configuration"/>
<file source="fr_FR/Jacket.htm" destination="$dreamweaver/configuration"/>
<file source="styles.css" destination="$dreamweaver/configuration" />
Thank you for the response, Carl.
Sorry not to have made my question clearer. What I don't understand is why the strings for the default language are required to be CDATA, while the localized strings are shown in all the documentation as simple text nodes.
What does one do if the localized string content includes somethnig that requires the use of CDATA? Is it permissible, but just not required, to put a CDATA section inside a <val> element in the localized file?
You CAN use CDATA in the localized files such as fr_FR.xml but it is not required. So if the localized string doesn't contain special characters you can simply use plain text.