Improvements to Localization Manager
A number of changes have been made to Localization Manager as a result of various issues raised recently. The key problems identified result from two areas:
- Volume of information. These problems were reflected in slower than expected performance. There have been several changes to improve performance. Several functions have been rewritten to deal with volume more efficiently with some areas having improved performance of over 300%. Progress indicators have been added to areas where tasks are taking a long time so it is obvious that the system has not crashed.
-and-
- Localization Rules and overwrite/update decisions. This was also related to information volume, in that it was assume that the person updating locales would make more atomic decisions which become impractical with large amounts of volume. To address this issue, we have changed some of the functionality to avoid many of the usability mistakes that were too easy to make, and change the focus of an update to be on updating a locale for an individual project rather than a whole library.
The following changes have been made:
- A process has been added during the creation of an update to include all dependencies for all objects selected as part of the rules. This will avoid some of the problems where dependencies were not being made available through the choice of Localization Rules.
- The special folders, Modified, and Made Available in this Update have been removed, and some new special folders added that are more practical for someone updating a locale and enables them to make decisions in bulk. All objects (and their dependencies) now appear in only one of the following special folders.
- New Objects - lists all objects in the update that are new to the target library. This includes newly created objects, and objects that had previously not been been made available in the locale but have now been included due to a change to the Localization Rules. All objects in this folder are automatically marked as Accepted as they do not exist in the target locale.
Note: Declining any of these objects is likely to result in the update not being able to continue due to dependencies not being included.
- Target Objects Offline - lists all objects that are part of the update that have been checked out of the target library to an offline library. Unless you are creating offline libraries directly from your target libraries this folder should always be empty. All objects in this folder are automatically marked as Declined as they cannot be overwritten while the target objects are locked.
- Target Objects Out For Translation - lists all objects that are part of the update that are already in the process of being translated in the target library and have been sent out in a translation job. All objects in this folder are automatically marked as Declined so they don't overwrite objects already in the process of translation. You can override this by selecting the object and accepting it, but this should only be done where a change to the source object is critical and requires retranslation. Any objects accepted will be overwritten with the source and will prevent that object from being imported with the original job it was exported in.
- Target Objects Localized - lists all objects that are part of the update that are already translated/localized in the target library. All objects in this folder are automatically marked as Declined so they don't overwrite objects already translated. You can override this by selecting the objects you need to retranslate and accepting them. This should only be done when you are actually updating a previous translation of an object. Any objects accepted are overwritten with the source and will require retranslation.
- Target Objects Exist - lists all objects that are part of the update that already exist in the target library but have not yet been localized. Any object listed here does not appear in any of the other special folders. All objects that have been modified since the previous update are automatically marked as Accepted as they have changed. We are not able to determine the importance or significance of the change, just that a change has occurred. It is reasonably safe to accept these as the target objects are not yet localized.
Important: If someone manually deletes the previous update library, Localization Manager will not be able to determine what has changed as there is nothing to make the comparison with.
The general performance of the Library Compare function has been improved so it will be much easier to work with.
Recommended Process for Creating an Update:
- Ensure the localization rules are set to include all Books for the project you are updating. This should also include any folders that are always included (such as Styles). Make these changes to all locales you are updating for this project.
- Create the update, either individually or by using the bulk update function.
- For each locale you are updating, select the last update (this should be the one you have just created above) and open the Library Compare function.
- If any objects are listed in the Target Objects Offline folder, then you must check those offline libraries in first, or they cannot be accepted.
- In the Target Objects Localized folder, accept all the objects you wish to overwrite. This results in the current translation for those objects being overwritten with the updated content from the source library.
- In the Target Objects Out For Translation folder, accept any objects that are in the process of translation that you wish to cancel and retranslate.
Remember: This will prevent those objects from being imported in the job they are currently out in. You will need to advise the localization vendor translating them that they will be reissued in a new job. - Once you have made all your selections, click Imported Accepted Objects. The target library is updated with the accepted objects.
- For each locale you are updating, create the necessary translation jobs.
Important: It is recommended that you go through a complete update cycle (as described above) as part of acceptance testing and in a test environment prior to working with the live data. Do not create a translation job in a test environment and send it out for translation as it will not import into the live system. Translation jobs, updates, and target libraries, should never be created in a test environment and copied into a live environment.
|