Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Translating Resources Gets Simpler with the Localization Management Toolkit  : Page 3

The global reach of many applications means organizations must manage the process of translating and keeping track of thousands of resources. The Localization Management Toolkit (currently in beta form) simplifies the process.


advertisement
Using the Administration Tool
The Administration Tool is currently a Windows application (see Figure 4), but a subsequent version will add the functionality of this tool to the Web Application.
 
Figure 4. The Enterprise Administrator Application: This Windows Forms application lets you add applications to the database, import and export resources, and see reports.
The term "Master Resx File" designates a file that comprises all the resources used in the application per defined culture. The main purpose of this file is to hold all the resources shipped for translation, because it's easier to keep track of a single file in the translation process than to keep track of multiple local resource files sent to a translation team. There is one "Master Resx File" per culture supported by the application

The translators can use any of the available tools, such as the ResxEditor, to read .resx files. We usually ship the culture-specific file along with the Invariant Culture Master file for translation. Translators can also use the Web application to translate terms online. Concurrency is resolved by the "last-in wins" policy; however, the database tracks when a PropertyValue was last updated. Eventually, it will be easy to add a reconciliation mechanism based on the date the file was received from the translators and the Updated column in the CultureProperties table. Adding a Culture to an Application
Adding a specific culture or neutral culture to the application will not automatically add the invariant culture to the list of cultures—although doing so should be considered a good practice. Unless indicated otherwise, the invariant culture will be the same as the 'en' English culture. Figure 5 shows how to manage application cultures using the Administration Tool.

Importing ResX Files with the Administration Tool

 
Figure 5. Managing Cultures: The figure shows the culture-management screen that lets you manage cultures for multiple applications using the Administration Tool.
The Administration Tool option "Import Resx Files" asks users to select the application name from the list of applications on the enterprise, opens a dialog so users can choose the folder where the application base code resides, and recursively grabs every file with a .resx extension from the given folder and from any child folder. Administrators must have these resource files on a local hard drive. They can generally pull these files from a central repository that has version control and save them locally. While importing, the Administration Toolkit relies on the common resource file-naming convention where the culture associated with a resource file appears in the file name before the .resx extension. For example, a typical filename might be strings.es-ES.resx, meaning that culture associated with the file is es-ES (Spanish from Spain). Resource files that do not have a culture indicator are considered invariant.


The DataSourceName field in the DataSources table keeps track of the filename where a particular resource is located. Importing Master Resx With the Administration Tool
The option "Import Master Resx File" also takes into account the filename convention and the name of each resource. In this case, the ElementKey column value is a concatenation of the DataSourceName and the actual ElementKey. This helps ensure that the application imports terms to the correct Element, given that an ElementKey must be unique for each DataSourceName. The key in the key.value pairs on every resource file is unique in that resource file.

 
Figure 6. Exporting Resource Files: The figure shows the process of exporting the resource files for a given application using the Administration Tool.
Exporting Resx Files with the Administration Tool
Completing the translation process for an entire application usually requires several iterations. Because the resources are stored in the database, you must export them as .resx files for testing or for final deployment, and attach the exported .resx files to your application. The process of exporting one .resx file per data source and per culture is also straightforward with the Administration Tool (see Figure 6). Exporting Master Resx Files with the Administration Tool
The Administration tool also lets you export one Master Resx File per culture. In this case, to avoid ElementKey collisions, the tool exports resource key names as a DataSourceName.ElementKey combination. Translators can then use any XML reader or resx file editor to perform their translations in an offline mode.

Finally, the Administration tool offers you a way to keep track of the generated resx files. Whenever an administrator generates a resx file, the tool tags it with a version number and stores a copy in the database, thus keeping an archive of the resources generated by date. You can view the generated resx file history (see Figure 7), and you can also export any previously generated resource file from the archive.

 
Figure 7. Resource File Archive: The Administration Tool tracks and archives exported resource files; you can select any archived resource file and export it.
Accessing Archived Resx Files with the Administration Tool
This toolkit assumes the applications will use satellite assemblies as the ultimate repository of resources. You can, however, modify the Resource-Provider Model for ASP.NET 2.0 and use the database directly, pulling out resource key.value pairs. For example, suppose you were shipping the final version of an application to a customer; you won't have any more chances to update its content. However the customer might like to be able to change the wording of some of the content of the application on the fly. To avoid forcing the customer to generate resource files and deploy them into a bin directory with the application, you can provide a content management system that will let the customer change the content dynamically. You can do this by using the database directly as the unique repository rather than satellite assemblies. This eliminates the need to generate resource files and deploy them, and customers can alter and show the content retrieved directly from the database.

A recent MSDN article, "Extending the ASP.NET 2.0 Resource-Provider Model," expands on this subject. You can modify the sample code provided in that article to work with this Localization Toolkit.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap