Beth Kirschner - 20-Dec-2006 12:37 Using properties files, as described here, is preferable to using the xml:lang feature (such that translators can focus on only one type of file).

Beth Kirschner - 20-Dec-2006 12:47 Note that synoptic tool titles & descriptions are currently set within the SiteAction class, and also need to be considered when fixing this.

Beth Kirschner - 06-Feb-2007 07:48 David Horwitz (david.horwitz@uct.ac.za) may be working on localization of tool titles in the help text, such that if the tool title is changed, that change will be reflected in the help text. This effort should be coordinated with this issue.

Tom Landry - 15-Feb-2007 12:20 The ToolListener iterates through all the tools xml files and calls the "register" method of the ActiveToolManager for each one of them. The ActiveToolManager instantiate the new tool and sets its title and description to the value contained in the xml file. These properties need to be internationalized. When they're accessed by the getTitle and getDescription functions of the Tool interface, the value reflects the actual locale of Sakai. The desired effect of that particular internationalization is that tool and pages names of newly created sites are in the correct locale. It is understood that these strings are stored in the database and that the modification of the ActiveToolManager won't translate them, or any other database content. The proposed solution is that one properties file, containing all tool titles and description, will be created. It is easier for translators to maintain a single file. The keys will be a concatenation of the tool unique ID and the property, for example "sakai.iframe.myworkspace.description". A RessourceLoader object, using this properties file, will be declared and instantiated in the ActiveToolManager class. The tool.setTitle and tool.setDescription will now pass the string from the bundle, instead that from the tool xml file. This only solves the case of a locale fixed at startup. To be more dynamic, the tool itself needs to be locale aware Is it preferable for the tool to: a) Access the whole ActiveToolManager bundle as a public property? b) Possess a copy (or a reference) to the ActiveToolManager bundle? c) Being injected the whole bundle by Spring? d) Use its own resource bundle and properties file, containing only its title and description?

Stephen Marquard - 15-Feb-2007 12:32 The title and description from the tool xml should still be used if there are no matching properties in the bundle - that way you can still deploy a new tool (say from contrib) and get a title/description, even though the central properties file hasn't been updated.

Tom Landry - 15-Feb-2007 12:47 Stephen, I agree with you. I identified this desired behavior on my personal notes, but it didn't make it through my last comment. If the name/description key is available from the bundle for this tool, use it. If not, take the title and description from the xml file.

Tom Landry - 21-Mar-2007 13:21 Here are all the files needed to fix the issue. I'm working to produce a diff file right now.

Tom Landry - 21-Mar-2007 13:30 The patch to the development trunk.

Tom Landry - 21-Mar-2007 13:31 Sorry if I'm late.

Stephen Marquard - 22-Mar-2007 01:19 This shouldn't be marked Resolved unless it's actually checked into svn, which I don't see?

Tom Landry - 22-Mar-2007 05:27 My bad.

Beth Kirschner - 22-Mar-2007 12:59 Patch has been checked in as suggested. Tool titles and their descriptions are dynamically displayed in the worksite setup tool according to the user's prefered language/locale. QA Note: Once a tool has been added to a worksite, it will retain the title in the language used when it was configured. If an (English) administrator adds the "Discussion" tool and a (French) user views the same tool, he/she will see the tool title in English, not French.

Beth Kirschner - 22-Mar-2007 13:05 For dynamic display of title/page titles, see SAK-8908

Aaron Zeckoski - 13-Jun-2007 05:12 This needs to be done in a way which does not require changes outside the tool itself (though I fully support the idea of having an override). I would recommend an additional properties file which defines internationalized strings for the tool name, description, security names (permissions), and security descriptions. This file is deployed into the components or shared (not sure about which yet) OR maybe just goes in the same place as the tool.xml file (and is just read into memory or perhaps copied somewhere or ????) I am happy to assist with this work, but we should not move tool specific data out of the overall tool project package

Peter A. Knoop - 12-Jul-2007 09:26 Aaron, this code was included in the 2.4.0 release, so it is effectilvey Closed as implemented for that release. If you would like to work on a new approach, please open a new issue. Thanks.