The DTDs mentioned above (topic, concept, task, and reference) have all been tested fully, and have made it all the way through the translation process. However, what happens if your information is too specific for those formats, and you must create a specialized DTD? In that case, the tools will function exactly the same way.
In many cases it is advantageous to create a specialized DTD for just your information. These cases can all be demonstrated by going through an example.
I have a pretty large music collection that I would like to document. This is pretty clearly reference information, so in this case it would be helpful to create a DTD that is based on the existing reference specialization. In that DTD, I will create a very specific template, which requires information such as the album title, band or composer, and song titles. Each of these new elements is simply a more specific type of the elements available in the reference specialization.
As mentioned above, every element in DITA comes with a translate attribute. The default for this in the main DTDs is a value of translate="yes". However, I may decide that in my new DTD, the band name should never be translated. If that is the case, all I have to do is give my new band element a default attribute setting of translate="no".
When editing, all of my new elements will be displayed exactly like the elements upon which they are based. For many XML editors, the specialized DTD has the advantage that it will prompt me for required information, so I will not forget important information such as music genre.
Once my collection is fully documented, I will probably want to translate it, so that my friends around the world will know what sort of music I listen to. When I send in the files for translation, I have two options, depending on the capabilities of my tool. If my translation tool can read DTDs, then I send in the files and the DTDs -- the tool will automatically pick up those ancestry hints by examining the DTDs. The same is true of the translate attribute, which is given a default setting in the DTD. If my tool simply parses the file as XML (as with the tool we use in IBM), I must normalize the document first. This moves the ancestry information and the translate value from the DTD into the topic itself.
In my specialized music DTD, the band element is based on the phrase element in the topic DTD, so the DITA-aware translation tool we use in IBM just sees a phrase. Ordinarily the phrase element is translatable, so band would be translatable as well. However, because I gave the element an attribute value of translate="no", the element will be off limits and our translators will not be able to change the value. When you pay for a translation by the word, this setting gives you a more accurate count, because only the actual translatable text will be evaluated.
Processing overrides
One of the reasons to create a specialization is to create processing overrides. You may want to create an element that gets common headings, which would not appear for the base elements. The "properties" element in the reference specialization is an example of one of these elements.
The properties element is based on a table, and by default it picks up standard table formatting. However, it only allows three specific columns, which in turn should have default headings. This is done using a processing override. The details of processing overrides are not very important here; it is enough to say that you can easily pick and choose which new elements need additional formatting, and which should pick up the default format. In this case, that additional formatting includes headings that must be based on the current language.
All translations in DITA are stored external to the topics and the transformation code, in a simple XML file. There is a common function that searches for the translation of a given string, based on the current language. Of course this works fine for translations that are shipped with the base transforms, but what happens when I need to add a translation of "band" for my music specialization?
The answer is that I create my own set of translations, and store them the same way that existing translations are stored. I put the files in with my transform overrides for the translation process. When I need one of my translated strings (as opposed to the base translations), I can call the same function, and tell it where my new strings are located. It will determine the current language, ensure that a translation for that language is available, and then return the value.
Once all of the topics are translated, the transform (including processing overrides) can be run by the translator, or the topics can be returned and processed locally.
