Localizable resource structure and use
Glossary Item Box
Introduction
Starting with version 7.8.3, the storage location of localized package resources has changed. In previous versions, the resources were stored in the SysSchemaResource table as BLOB data. Now, the localized resources are stored in the SysLocalizableValues table in text form.
For each set of schema resources in the package-schema-culture bundle, the checksum is stored in the SysPackageResourceChecksum table, which allows you to quickly determine if there are any changes to the package resources when updating the package. The checksum allowed for resources to be separated from schemas, enabling users to create translation packages.
 |
ATTENTION The approach to working with language cultures has changed in bpm’online 7.11.1. Now, the application uses only the cultures that have [Active] checkbox selected. This improves performance of different types of tasks, such as logging in, opening a record page, etc. However, all installed language cultures will be used when working with section and detail wizards, process and case designers and the [Translation] section. |
Storing resources
Resource storage structure
The resources have been moved from schemas to a package, enabling users to create translation packages. To store schema resources with the same name, but with different managers (e.g. Entity and ClientUnitSchema), the names of the schema managers with the prefix "SchemaManager" clipping were added to the resource package names.
Fig. 1. Storing resources in a package
A package can contain resources for a schema that is defined in another package. In addition, the package can contain resources without containing schemas ("translation package").
The SysLocalizableValue table
The resources are stored in the SysLocalizableValue table for every localizable string or image. Each record is bound to the package and the base schema identifier. The main fields of the SysLocalizableValue table are listed in Table 1.
Table 1. The main fields of the SysLocalizableValue table
| Column name | Description |
|---|---|
| Id | Record identifier. |
| ImageData | Graphic resource value. |
| IsChanged | A checkbox for specifying if the resource has been changed. |
| Key | Resource key. |
| ResourceManager | Resource manager name. Populated only for core resources. |
| ResourceType | Resource type. |
| SysCultureId | Culture identifier. |
| SysPackageId | Package identifier. |
| SysSchemaId | Base schema identifier. Populated only for configuration resources. |
| Value | String resource value. |
Schema import and export
The format for storing resources in exported schemas has also changed. Now the resources in the exported schemas are stored in XML format.
Working with localizable resources
Updating the package from the repository
By using the new resource storage mechanism, all changes to localized resources are displayed when the package is updated (Fig. 2).
Fig. 2. Displaying resources when updating a package
Possible resource states:
- [Modified] – the resource was changed.
- [Added] – a new resource has been added.
- [Deleted] – a resource has been deleted.
- [Conflict] – a resource was modified and fixed in SVN when another developer was working on it.
Committing a package to storage
When the package is committed, all changes to the localized resources are also displayed in the repository (Fig. 3).
Fig. 3. Displaying resources when a package is committed
Conflicts when a package is committed and updated
It is not currently possible to block resources in the application. If the developer modifies the schema resources, and the package has already been modified and the same resources have been modified in it, they will see a list of those resources with the [Conflict] state. This means that the version and contents of the resources modified by the developer do not match the version and contents committed in SVN. When the developer commits again, their modifications will block the modifications committed in SVN. Such conflicts must be resolved manually in SVN clients (e.g. Tortoise).
Fig. 4. Displaying conflicts when updating a package
Editing resources in the file system.
Editing resources directly is available starting with version 7.8.3. To do this, you need to upload them to the file system (e.g. with Tortoise), and then make changes and commit to SVN.
|
ATTENTION For each resource value in the SysLocalizableValue table, there is only one record with the corresponding references to SysPackageId, SysSchemaId, SysCultureId, and a specific Key value. Therefore, when you commit a resource with the [Conflict] state, the table will write the last value. |
Updating resources with a direct SQL query to the database
If you change the SysLocalizableValue table value with an SQL query, you must also change the value of the IsChanged column in the SysPackageResourceChecksum table for the corresponding schema. Otherwise, when the package is updated, the application will not detect a conflict.
You can not add data to the SysLocalizableValue table with a direct SQL query, because there is no information about the added resources in the corresponding schema metadata.
