This space contains the documentation for the common Atlassian User Management interface, as used in Confluence, JIRA and Stash.

Version of this documentation: User Management 4.0

Note to Readers

Please refer to the JIRA Administrator's Guide, the Confluence Administrator's Guide or the Stash Administrator's Guide instead of the documentation in this space. This documentation is not intended to be read independently of the product documentation in those guides.

Note to Authors

  • All the content in this space is in the form of re-usable chunks, in the inclusions library.
  • The user management UI plugin is versioned independently of the backend libraries. To solve this problem, we will version the documentation space independently of the software. The documentation space will start at version 1.0 (010), and will then move to version 2.0 (020), and so on. We will create a new version of the documentation for any change in either the UI or the backend that impacts the behaviour of the software, from the user's perspective.
  • ラベルなし

3 Comments

  1. Rocha Jennifer

     Confluence, JIRA, and other products depending on what type of PluginSettingsFactory (e.g. ConfluencePluginSettingsFactory) is in use, which depends on what product a plugin is for.

    Plugin developers benefit from the use of the abstract factory pattern here in several ways. No matter what the target product for a plugin, one syntax can be used to interact with plugin settings. So it is not necessary for developers to learn and remember multiple, distinct settings storage syntax for different products. And a particular plugin could potentially have multiple target products without special handling, at least as far as plugin settings are concerned.

    These are benefits often seen when using factories for object creation: users of the object are insulated from the specific objects used and their implementations, and maintenance changes only need to occur in one location rather than in each client.??

  2. Rocha Jennifer

    If your has already been internationalised, follow these steps to translate the plugin:

    1. Extract the contents of the plugin JAR file.
    2. Locate the properties file which contains i18n key-value pairs.
    3. Create a copy of this file with the same file name and desired locale extension. For example, if the default properties file is calledmypluginprops.properties, make a copy of this file and rename it to MyPluginName_ll_CC.properties, where '_ll_CC' is the locale extension for your required language and country.
    4. In your copied properties file, replace the default string values (not the keys) with your translated strings as desired.
    5. When you rebundle your plugin into a JAR file, ensure that your translated file is copied to the same location from where you obtained the original properties file. For example, if the original properties file was in path/to/, your copied and translated properties file needs to be in the same location.!!........?

  3. Rocha Jennifer

    The exact attribute name for this process may vary based on the type of module in your atlassian-plugin.xml file. For example, the Confluence Component Module requires the attribute i18n-name-key for its localisation key. You should consult the relevant documentation for the module you wish to localise. A good starting place is the Plugin Module Types documentation.

    For a list of plugin modules specific to:

    In your properties file, src/main/resources/com/example/mypluginname/MyPluginName.properties, add the property key with the value in English.....? !