As far as I can tell, FrameMaker assigns the text and formatting for note types from the EDD, i.e., when you set the type attribute of a note to "danger", you get DANGER: as the prefix. To translate the prefixes to a different language, do I need to edit the EDD?
Yes, that is correct. These strings are set in Prefix rules in the EDD.
Does this mean that I would have to localize the choices in the attribute list, i.e., 1. in the following screenshot and reimport the EDD into each DITA file?
It is not necessary to translate the attribute choice values.
Pardon my ignorance, but where are the text strings that I would need to translate, i.e., danger, caution, notice, etc?
Actually, this is a little more complicated than I thought. I just checked the EDD and this is what it uses for most of the Prefix rules:
This is "clever" because it simply means that if you choose type="danger", you will get the prefix "DANGER". (The note.type Character Format uses Uppercase.). The problem is that you don't want to translate all of the type choice values, because anywhere a <note> is used in a localized document, you will have to change it's attribute value. *** You definitely don't want to do this. ***
The best approach is to edit the EDD so that it doesn't use <$attribute[type]>; instead, you will need a series of ElseIf elements: (pseudo-code) if [type="danger"] then prefix = (translated string danger).
You'll need to set the ElseIf to key off of the language attribute as well, or you'll need to produce a structapp for each language localized.
I always heard that DITA would be so convenient to translate.
Is Heavensbog2 really the first one who has to get this translated?
Isn't there a method to get all text, the actual content and numbering, translated easily?
Convenient? Depends on perspective.
Less expensive? Should be. Depends on capability of vendor.
Requires effort when changing workflow? Certainly.
When implementing or modifying structure models and workflows, there is typically time and money to be spent in specifying and customizing the environment.
You might consider creating a duplicate of your structapp, with a language-specific identifier. You could then modify a language-specific duplicate of the EDD.
This would let you switch the prefixes by switching structapps when you open the content.
I managed to export and modify an EDD and reimport it with the note type changes. Although that works, I can't figure out which EDD I have to modify to make the changes permanent in task, reference, and concept files because the structapps.fm does not point to any EDDs and neither do the files in ..Structure\xml\DITA_1.3\app\technicalContent\template folder. Which EDDs do I need to edit in \Structure\xml\DITA_1.3\app\technicalContent\edd ?
BTW: I'm currently evaluating (and struggling with) the FrameMaker DITA implementation to see if my company can use it and despite the obvious benefits, I'm seriously thinking of abandoning this project entirely and just continuing with unstructured FrameMaker because setting up the text formatting for several languages and preparing files for localization seems unnecessarily complicated. I don't have a budget for an outside consultant and IT can't support me because they don't know FrameMaker as well as I do.
You need to find the appropriate DITA templates and import the Element Definitions (EDD) into the templates (File > Import > Element Definitions). The DITA template path for each topic type should be in the structapps.fm file.
Setting up the environment shouldn't be more than a few hours per language, for someone who has previously noodled with the connected DITA templates.
It's worth the effort, because, respectfully, if you will continue to spend money on localization, you do have a budget to work with if your company is interested in improving profit.
If your current localization expenses are $50,000 annually, and that your "new" DITA implementation reduces cost by 30%. (Plug in whatever numbers relate to your environment, but I've worked with larger budgets, and gotten more than 30% savings with structure, rather than MIF-based localization)
Over 5 years, the budget would be the net present value of that $15,000 annual savings, or somewhere in the high $30,000's, depending on your organization's expected internal rate of return.
Forgetting all the finance stuff, if you want approval for the project, you need to show how and why this project will result in a financial benefit for the organization. Only when you can't show that benefit, should you abandon the effort.