Tool and Page Title

See also SAK-8909 - Getting issue details... STATUS and Tool and Page Title Work Notes.

Proposal written and submitted.

Some previous work by Tom Landry.
Also, Raúl Enrique Mengod López submitted a proposed fix based on an XML file to contain translations. Beth and I don't much like this approach.

Analysis

Here is an illustration of a typical (small, actually) site:

Page title shows up in page tab button and in the tool frame title.

Tool names appear in the Site Info tool, Worksite Setup tool, and Sites tool. Page names are going to come from the tool name, unless user entered like in the Web tool. Tool names show up explicitly in the Sites tool as well.

The Sakai portal (Charon) generates names for page tabs using the Site Service. In particular, two methods from SitePage are of interest:

public interface SitePage extends Edit, Serializable {
	/** @return The human readable Title of this SitePage. */
	public String getTitle();

	/** @return the layout title for this page. */
	public String getLayoutTitle();

	...
}

getLayoutTile() doesn't seem to be relevant. I think it just means Single or Double column. It shows up in the Sites tool.

The getTitle() method is likely used to display page tab names.

The Site service has property bundles which might be used to contain translations, but this would be on a global basis (not specific to a site context).

Part of the problem is that page tab are usually created from site templates. While they often correspond to a tool name, they don't have to. The templates can be edited and still retain the tool id's for the tool that belongs on that page. Perhaps tool names (and descriptions) could be registered with a global dictionary at startup time?

Raul's previous approach to solving this problem seemed reasonable. He was saving the tool ids into the DB tables for site and tool title. Then used tool-local bundles for translation of these titles. However, some problems were noted:

when even tool or page names were requested of a user, it was necessary to enter the tool id instead. - Where does this happen?
if a tool was included more than once in a site (like the web tool), different tool id's needed to be created and entered.

It seems to me that these problems could be solved using the older approach, rather than moving to Raul's new solution of a global XML file.
In fact, why enter the tool id's into the database pages at all? Leave the existing names there and use them as defaults/fall back. The tool id can still be used to fetch a translated tool or page title, since it is known a priori (at least for the tool).

User Interface Implications

In general, users of Sakai won't see any real interface changes other than tool and page titles appearing in a localized language.

However, some changes are likely need to administrative tools (Worksite Setup and Sites). A checkbox may be needed to flag page titles that should not be translated.

Correspondence

Tom Landry 4/7/08

Just two things before I begin. First, do you want the patch for 2.4 or 2.5 (or both) ?

Second, there is a reason why our patch wasn't commited. The implementation breaks the renaming of the pages. There are also some specific cases that cannot be translated, such as web content tools. In our case, the tradeoff was worth it, but I'm not sure that it's the case for the whole community.

We felt that a much broader (and complex) translation mechanism was needed to solve this issue. We did explorations on that, using database tables for example. After discussion with Raul Enrique Lopez at the last Sakai conference, we thought about lighter approaches using XML.

By the way, did you received, tested or applied Raul patch for tool titles?

Tom Landry 4/7/08

The patch bypasses the part where the real page name (the one in the database) is sent to the interface. It uses the unique tool id as a key to the bundle files and returns it instead of the real name.

The rename still works, but the modifications aren't shown anymore.

I guess we could add a new bit field in SAKAI_SITE_PAGE to indicate if the i18n override should take place, or in other word we want to force our own page name.

Tom Landry 4/7/08

Here it is, the patch to translate page titles for trunk. A couple of details for you :

First, I added a possibility to deactivate the translation for specific pages, so the user can still customize page names. As I told you earlier, this is necessary since the patch overrides the GetTitle property, so every page in every site is translated the same.

In the following print screen, you see a new checkbox (sorry for the missing key, it IS included in the patch - I was lazy). When you click the checkbox, you tell the system to use the name entered in the input box just over it. In fact, this is a new bit column in the database. If you left it unchecked, the page name WILL be translated.
The patch does translate tool titles also, but I didn't have the time to add the "Do not automatically translate" checkbox for the tools. It should be easy, this is the same mechanism.

(image)

The magic (black or white, I'm not sure) takes place in the GetTitle function in BaseSitePage. Please take a look at it. I had no choice but to omit translation for certain tool types (news and webcontent). It's ugly, but I had no choice.

Requirements

Tool titles must be displayable in a language based on locale.
Translated tool titles should be included in message bundles, if possible.
Site page names must be displayable in a language based on locale, except when site page name is not drawn from a tool title (multiple instance, multiple tools on page).
The Home page should never be translated.
A means should be provided to disable translation for a site page so that administrators can re-name the site page.