|Acrolinx Server||4.7, 5.0, 5.1, 5.2, 5.3, 5.4, 5.5|
If your company has a lot of regional markets, the chances are you'll need to manage terminology for different regions that share the same language. This poses a challenge when certain regions use different terms for the same concept. Acrolinx can help your writers check for regional differences in terminology and guide them to use the correct regional term.
When is a Biscuit not a Biscuit?
A classic example of regional difference is American English and British English. As you might know, the word "biscuit" conjures up completely images depending on who you talk to. Take the following image for example.
For an American, a "biscuit" is the big yellow puffy thing, whereas for a British person, biscuits are the brown long brown flat things. The American equivalent term for the British "biscuit" is "cookie". So what if you actually needed to check for terms like this in Acrolinx?
You might wonder why the American term isn't set as "English (US)". If you use American English as the default region for all English content, then American English would be your parent language. You don't need to specify it as a sublanguage, because for you, American English is the default version of English that you use. British English is an exception to the rule, so you'll need to set it up as a sublanguage.
Setting up Sublanguages
If you didn't have British English set up already, you would add it as a data category like in the following illustration.
In the hierarchy of languages, English is the "parent" and English (GB) is the sublanguage. For sublanguage checking to work properly, you must organize all sublanguages like this. For each language, create all regional variants as sublanguages underneath the "parent" language.
You can get more details on organizing data categories in the article " Managing Lists and List Items for Data Categories ".
Once you've got you languages set up correctly, you need to turn on sublanguage checking. You do this by updating your language configuration properties .
How Sublanguage Checking Works
Once you've turned on sublanguage checking, the behavior for terminology checking works a little differently from what you might be used to. Let's compare the behavior for the previous example. Suppose that you wanted to check the following sentence:
"The cookie and the biscuit both looked delicious, but only one would go well with gravy" .
Without sublanguage checking, you'd only get the option to check the sentence in the parent language "English".
Once the check completes, Acrolinx wouldn't report anything unusual. Acrolinx would treat both "cookie" and "biscuit" as preferred terms because that's how they're set up in the Terminology Manager.
With sublanguage checking turned on, you'd get the option to check in both "English" and "English (GB) ".
If you checked the sentence in "English", Acrolinx would report the word "biscuit" as a terminology issue.
If you checked the sentence in "English (GB) ", Acrolinx would report the word "cookie" as a terminology issue.
So what's different when you use sublanguage checking? When sublanguage checking is turned on, Acrolinx overrides the status for terms in other regional variants. Terms that are in your selected sublanguage are preferred over terms in other regional variants.
In our "biscuit" example, the word "cookie" is suddenly treated as deprecated because although it's English, it's not British English. When an entry contains multiple terms in same language family, Acrolinx prefers terms that match the checking language most specifically. Acrolinx treats all other terms as deprecated except the term in the specific sublanguage that you're checking. British English is more specific than just "English", so Acrolinx treats the English term as deprecated and the British English term as preferred.
But What about Terms That Belong to Multiple Languages?
In the Terminology Manager, you can also give terms the language "mul" or "Multiple Languages". Usually, you set terms to "Multiple Languages" when the term stays the same, no matter what language you use. These terms are often brand and product names. For example, our own company name "Acrolinx" is always written the same way, regardless of the language we write in.
When you turn on sublanguage checking, the language "multiple languages" works in a similar way to a normal language. For example, suppose that you have the brand name "Cookie King". You want to use it in all regions except Britain, where you'll use the alternative brand name "Biscuit Baron".
You would create both terms as "preferred" and set "Cookie King" to have the language "Multiple languages" and "Biscuit Baron" to English (GB).
If you check any language except British English, Acrolinx would treat "Cookie King" as preferred and "Biscuit Baron" as deprecated.
- If you check in British English, it would be the other way around - Acrolinx would treat "Cookie King" as deprecated, and "Biscuit Baron" as preferred.
Turning on Sublanguage Checking
Once your languages are set up correctly, you can turn on sublanguage checking in the language configuration properties.
To turn on sublanguage checking, follow these steps:
Open your overlay of the relevant language configuration file.
If you have not yet created an overlay of this file, create a new version of the file at the following location:
If this location does not yet exist, create the required subdirectories first.
Add the following line:
- Save your changes and reload the language configuration on the relevant language servers.
A Reminder About Checking Profiles
If you use checking profiles , you'll need to create checking profiles for your sublanguages. Checking profiles contain checking presets such as the checking language and term sets.
This means that writers don't have to select the checking language or any other check settings. They just select the required checking profile. Suppose that US English is your default for English content and you only have a checking profile for default English. Without a second checking profile, there would be no way for your writers to check in British English.
In this case, you could copy the default checking profile for English and call it "British English." You would change the checking language to "English (GB)" and any other settings that are specific to British English such as the rule set. Then your writers would have a choice between checking profiles for "default" English or British English.