Applying Security and Specialized Translator User Roles for Languages

Each language in MicroStrategy is represented by a specific MicroStrategy object. You can apply security to a language in MicroStrategy by using the language object's ACLs, which permit or deny specific use of an object.

You also use the language object's ACLs in combination with MicroStrategy user privileges to create a translator or linguist role. This type of role allows a user to translate terms for an object in a given language, but keeps that user from making changes to the object's translations in other languages or making changes to the object's name and description in the object's default language.

Maintaining Language Objects and Controlling Security

Each language that is part of your MicroStrategy system (whether out of the box or languages you have added) exists as an object that can be edited, can have ACLs (security) set on it, can have its name translated, and so on.

ACLs can be used on a language object to control user access to certain languages. You can take advantage of this feature to allow users to serve themselves in terms of choosing language preferences, while restricting them from languages that may not be supported for areas of the software the user commonly uses.

For example, you can create 2 groups of users and provide Group 1 with browse and use access to the English language object and the French language object, and provide Group 2 with browse and use access to Spanish only. In this scenario, users in Group 2 can only choose Spanish as their language preference, and can only access Spanish data from your warehouse. If an object which is otherwise available to Group 2 users does not have a Spanish translation, Group 2 users will be able to access that object in the project's default language (which may be English, French, or any other language.)

To Access a Language Object

In Developer, from the Folder List on the left, within the appropriate project source, go to Administration > Configuration Managers.
Select Languages.
Right-click any language object to edit or otherwise maintain that object.

Creating Translator Roles

You can set up MicroStrategy so that certain users can translate object names and descriptions into a given language. At the same time, you can restrict these users from changing the object's translations in languages other than the one they are translating, and from making any other changes to the object.

When an object is translated or an existing translation is edited, the object's version ID and modification timestamp are changed. This allows you to easily identify the latest translated objects when merging objects across projects or environments.

Creating a translator or linguist role can be useful if you have a translator who needs access to an object to translate it, but who should not have the ability to make any other changes to the object.

A common approach to setting up the MicroStrategy environment to support this type of user role requires creating a MicroStrategy user account specifically for each translator, allowing certain privileges to that user, and setting ACLs on one or more language objects to allow access to a given language for translation purposes. The steps below provide a common approach to setting up your system to support translator roles. The end goal is to create a list of user accounts made up of translators who have a limited set of permissions in MicroStrategy to translate a project's objects (schema objects, application objects, report/document objects), without the ability to write to any object or make changes to an object.

You can modify this approach to customize your language object security as it fits your specific needs. Suggestions are provided after the steps, to modify the translator role setup for specific situations.

The following terms are used:

Source language: The object's default language
Reference language: Any language other than the source language which the translator needs to translate from
Target language: Any language other than the source language which the translator needs to translate to

To Create a Translator Role

Create a User Account for Each Translator

Create a user account for each translator.

Grant each user the Use Developer privilege, in the Analyst privilege group.
Grant each user the Use Translation Editor privilege, in the Common privilege group.
Grant each user the Use Translation Editor Bypass privilege, in the Developer privilege group.
This privilege allows the user to use the Translation Editor to change an object's name and/or description for a given language, and does not require the user to have Write access to the object whose name/description is being changed (the system bypasses the normal check for Write access).

For steps on creating a user account and assigning privileges to a user account, see the Setting Up User Security section.

Allow Each Translator User to Add/Edit Translations for a Given Language

Grant the View permission on the ACL (access control list) for a language object to the user account that is allowed to translate objects into that language. This permission should be granted to the target language. The View permission allows a user to:

See an object's name and description in the source language (the object's default language) as well as in all other languages.
Translate object names and descriptions in the language the user has View permission for.
To grant the View permission for a language object, use the following substeps:
1. In the Folder List, within the appropriate project source, expand Administration, then Configuration Managers, and select Languages.
2. Right-click a language from the list of language objects, and select Properties.
3. On the left, select Security.
4. On the right, click Add to add the appropriate user account to the security for this language. Navigate to the appropriate translator user, select the user, and click OK.
5. Click the field in the Permissions column next to the newly added user and select View.
  A user who has View permissions to a language will be able to add or modify translations in that language using the Translation Editor. Translating an object's name/description in the source language (the object's default language) is equivalent to renaming the object. This may not be desirable, especially for schema objects. To prevent this, be sure that the View permission is not granted to the source language (the default language) of the objects that will be translated.

Allow Translators to View Translations in Specific Reference Languages

Grant read-only access to one or more reference languages by granting the Browse and Read permissions (ACL permissions on the language object) for those languages that the translator needs to be able to view. Granting Browse and Read permission to a user for a language allows the translator to be able to see object names and descriptions in that language, but not to translate or otherwise make changes to object names/descriptions in that language. Read-only permission is generally granted to the source language (the object's default language), so that the source language can be used as the reference language during translation.

Allowing translators to see translations for an object in a language other than just the source language can provide translators useful context during translation, and is necessary if a translator needs to see a reference language that is different from the source language.

Use the following substeps:
1. In the Folder List, within the appropriate project source, go to Administration > Configuration Managers > Languages.
2. Right-click a language from the list of language objects, and select Properties.
3. On the left, select Security.
4. On the right, click Add to add the appropriate user account to the security for this language. Navigate to the appropriate translator user, select the user, and click Custom.
5. Click the field in the Permissions column next to the newly added user and select Browse and Read.
  Be sure you do not grant the Use permission on any language object that represents a language you do not want the translator to be able to make changes to.
Repeat these substeps for any other languages in the list of language objects that you want this user to be able to see.
To deny a translator the ability to see an object's name and description in a given language, assign the user the Deny All privilege for the language object(s) that the user should not be able to see or add/edit translations for.

Minimum Requirements and Additional Options for Creating a Translator Role

The following table shows the minimum privileges and permissions that a user needs to be able to view a language and to translate schema objects, application objects, and report/document objects in a MicroStrategy project:

To View an Object's Name and Description in a Given Language	To Translate an Object's Name and Description in a Given Language
The Use Developer privilege, in the Analyst privilege group.	The Use Developer privilege, in the Analyst privilege group.
The Use Translation Editor privilege, in the Common privilege group.	The Use Translation Editor privilege, in the Common privilege group.
	The Use Translation Editor Bypass privilege, in the Developer privilege group.
The Browse permission on the language object that the translator will be translating into, and on a reference language object.	The Browse permission on the language object that the translator will be translating into, and on a reference language object.
The Read permission on the language object that the translator will be translating into, and on a reference language object.	The Read permission on the language object that the translator will be translating into, and on a reference language object.
	The Use permission on the language object that the translator will be translating into.

Be sure you do not grant the Use permission on any language object that represents a language you do not want the translator to be able to make changes to.

To provide a translator the greatest possible context for objects:
- Allow the translator user to see an object's name and definition in the source language and in any other language that the object uses, as well as the translator's target language. To do this, grant the translator user the Browse and Read permissions for each language object listed in Administration > Configuration Managers > Languages. The Browse and Read permissions allow the user to see translations in the Translation Editor but not edit the translation strings.
- Grant the user privileges to access the object within the various Developer object editors. These privileges allow the user to execute the object so that it opens within its appropriate editor, thus displaying additional detail about the object. Access can allow context such as seeing a string as it appears within a dashboard; a metric's expression/formula; an attribute's forms and the data warehouse tables that the data comes from; and so on. For example, in the User Editor, grant the translator the Execute Document and Use Report Editor privileges from the Analyst privilege group. Also grant Use Custom Group Editor, Use Metric Editor, Use Filter Editor, and so on, from the Developer privilege group.
To deny a translator the ability to see an object's name and description in any language except the source language and the language that the translator has permission to Browse, Read, and Use, grant the user the Deny All privilege for the language objects that the user should not be able to see.
For example, if you grant a translator Browse, Read, and Use permissions for the French language object, Browse and Read permissions for the object's default language, and Deny All for all other languages, the translator will only see the French translations column and the default language column in the Translations Editor in Developer.
However, be aware that this limits the translator to only being able to use the object's default language as their reference language. If the translator can benefit from seeing context in other languages, it is not recommended to Deny All for other languages.
You can create a security role to support per-project translator access. A security role is a set of project-level privileges. You can then assign the security role to individual users or groups. A user can have different security roles in different projects. For example, a user may have a Translator security role for the project they are supposed to translate, but the normal User security role in all other projects. Security roles are assigned to users or groups on a project-by-project basis.
Because security roles are project-level roles, setting up translation based on security roles does not allow for the translation of configuration objects, such as database instances, schedules, events, and any other object that exists at the project source level. A translator can be set up to translate configuration objects using the information in the next bullet.
To allow a translator to translate configuration objects (such as user and group descriptions, database instance names and descriptions, schedule and event names and descriptions, and any other objects that can be accessed by all projects in a project source), grant the translator the Use Translation Editor Bypass privilege at the user level (rather than at the project level). Also, grant the translator user the following privileges in the User Editor, which allow the user to access the various configuration object managers in the Administration folder in Developer:
- Create and edit database instances
- Create and edit database logins
- Create and edit schedules and events
- Create and edit security filters
- Create and edit security roles
- Create and edit users and groups
- Create configuration objects
To allow users to translate objects using MicroStrategy's bulk translation tool, the Repository Translation Wizard, grant the user the Use Repository Translation Wizard privilege.
If this privilege is assigned, be aware that the user will be able to export strings and import translations for those strings in all languages that the project supports. This is true no matter what other language restrictions are applied.