I am using structured FM 2020. To create my content, I use xml format and DITA. In the xml files, I can set the xml:lang attribute to the language of that topic, e.g: <topic id="bla bla" xml:lang="de"/>, where I set the language to German. Now when I open the xml file in FM, the Language under the Font tab in the Paragraph Designer remains English, ignoring the xml:lang attribute. It means I have to manually change the Language to German.
Is there a way to tell FrameMaker spell checker to choose the language which is set in the xml file using the xml:lang attribute?
Copy link to clipboard
You should be able to do this with an EDD rule.
Thank you. I basically did what you suggested. Instead of the paragraph element, I updated the head element of the topic.edd.fm in DITA_1.3 data structure and imported it into topic.template.fm. However, that did the job only for the p element. Is it possible to apply this rule on all texts in all levels, starting from the title element?
I don't think so. Here is why: there are basically two ways of applying styles in an EDD. One is to call formats for element/attribute combinations and the other is to apply styling directly with EDD elements. You can mix both types in an EDD, but the FrameMaker DITA templates mainly call formats.
The advantage to the second method, applying styling with EDD elements, is that you can use inheritance. You can have a base "Body" format and have a top-level EDD rule change the language and then the rules on other elements just make changes to that format based on element/attribute combinations.
I am probably not explaining this very well, but the bottom line is that the DITA templates call formats and, as a result, you will have to apply this context rule throughout your EDD.
I understand but it sounds like much manual and redundant work if you would like to have the spell check for all the elements in your document.
In another thread (https://community.adobe.com/t5/framemaker/reading-attribute-values-for-autonumbering/m-p/11115932?pa...), you asked something that is relevant here, "Now in the EDD (mainly commonElements.eddmod.fm) I use the Text format rules for each of these elements to check if the xml:lang attribute of their ancestor topic element has a value. Shall I do this check for the ul and ol or directly for the li element? "
I'm answering here, since the question is about language. As Rick explained, your EDD can assign individual formatting properties (such as language) or refer to a format in a catalog by its tag. Notice that whenever you assign a format from the catalog, that format overrides all inherited values. So if you specify the language property for the ul and ol elements and the li element assigns a paragraph format, you'll lose the language specified on ul or ol.
To really be complete, you can check the language in a rule for every element that sets a paragraph format. Doing so would be for a much longer EDD. If I had that requirement, I would either set the language independently of the EDD (see below) or use one of the following techniques to change the EDD:
1. Using a text inset in the EDD. I would create the rule that tests for the various languages either in a reference flow in the EDD or in a separate document. That flow would not be valid because ContextRule is not a valid root element for an EDD. That's OK, because it will be valid where its used. I would insert it as a text inset the first place I need ed to test the language, copy that text inset to the clipboard, and paste it in other locations. Using the text inset prevents typos with repeated insertions and also makes it possible to update all occurrences as once.
2. Using XSLT to insert the context rule. Creating a large number of text insets is a large amount of tedious editing. Remember that an EDD is a structured document and hence can be saved as XML. The context rules for language can be inserted with XSLT and the result opened in FrameMaker to create an EDD that can be used.
3. Scripts and plugins. Especially since you are not changing the language within the document, you can set the language with a script or plugin instead of using the EDD. That would result in an EDD that is much more readable.
4. Supporting various language-dependent constructs. I have worked on projects in which there is more language-dependency than just spell checking. For example, tab stops may differ based on the expected widths of some fields. I believe you've mentioned that running headers may also be language-dependent in your environment. It is sometimes useful to maintain language-specific templates and use a script or plugin to select the correct templates.
Such templates may contain element definitions from language-dependent EDDs. Tassos Anastasiou and I have developed a tool that simplies maintaining variations of a base EDD. Please start another thread if you'd like information about the Reusable EDD Manager.
Lynne, I guess I am understanding more. Looking at the li element, I see that it uses paragraph formats such as ul.bullet and those tags have default languages in the topic templates for instance, which override my rules.
For publishing, I use different templates for different languages in order to have more control on what I publish. These outputtemplates can be saved locally and accessed by individual settings files. However, in order to check if there are typos in the text I decided to incorporate the xml:lang in the EDD and see if there are red underlines and possibly suggestions to correct the mistakes. I would create another thread to learn more about Reusable EDD Manager then.