Best Practices from Oracle Development's A‑Team

Internationalize WebCenter Portal - Content Presenter


In this post we are going to explain how to get Content Presenter and its editorials to comply with the current selected locale for the WebCenter Portal session. As you probably know by now WebCenter Portal leverages the Localization support from Java Server Faces (JSF), in this post we will assume that the localization is controlled and enforced by switching the current browsers locale between English and Spanish.

Main Article

There is two main scenarios in internationalization of a content enabled pages, since Content Presenter offers both presentation of information as well as contribution of information, in this post we will look at how to enable seamless integration of correct localized version of the back end content file and how to enable the editor/author to edit the correct localized version of the file based on the current browser locale.

Solution Scenario 1 - Localization aware content presentation

Due to the amount of steps required to implement the enclosed solution proposal, I have decided to share the solution with you in group components for each facet of the solution. If you want to get more details on each step, you can review the enclosed components. This post will guide you through the steps of enabling each component and what it enables/changes in each section of the system.

Enable Content Presenter Customization

By leveraging a predictable naming convention of the data files used to hold the content for the Content Presenter instance we can easily develop a component that will dynamically switch the name out before presenting the information. The naming convention we have leverage is the industry best practice by having a shared identifier as prefix (ContentABC) and a language enabled suffix (_EN) (_ES).  So the assumption is that each file pair in above example should look like following:

  • English version - (ContentABC_EN)
  • Spanish version - (ContentABC_ES)

Based on above theory we can now easily regardless of the primary version assigned to the content presenter instance switch the language out by using the localization support from JSF.  Below is the custom code within the Java bean (oracle.webcenter.doclib.internal.view.presenter.NLSHelperBean), which is enclosed in the customization project available for download at the bottom of the post:

public static final String CP_D_DOCNAME_FORMAT = "%s_%s"; public static final int CP_UNIQUE_ID_INDEX = 0; private ContentPresenter presenter = null; public NLSHelperBean() {    super(); } public void initLocaleForDataFile() {    String dataFile = null;   if(presenter.getConfiguration().getDatasource() != null &&      presenter.getConfiguration().getDatasource().isNodeDatasource() &&      presenter.getConfiguration().getDatasource().getNodeIdDatasource() != null &&      !presenter.getConfiguration().getDatasource().getNodeIdDatasource().equals("") &&      presenter.getConfiguration().getDatasource().getNodeIdDatasource().indexOf("_") > 0) {         dataFile = presenter.getConfiguration().getDatasource().getNodeIdDatasource();         FacesContext fc = FacesContext.getCurrentInstance();         String currentLocale = fc.getViewRoot().getLocale().getLanguage().toUpperCase();         String newDataFile = dataFile;         String [] uniqueIdArr = dataFile.split("_");         if(uniqueIdArr.length > 0) {            newDataFile = String.format(CP_D_DOCNAME_FORMAT, uniqueIdArr[CP_UNIQUE_ID_INDEX], currentLocale);         }         presenter.getConfiguration().getDatasource().setNodeIdDatasource(newDataFile);    } }

With this bean code available to our WebCenter Portal implementation we can start the next step, by overriding the standard behavior in content presenter by applying a MDS Taskflow customization to the content presenter taskflow, following taskflow customization has been applied to the customization project attached to this post:

  • Library: WebCenter Document Library Service View
  • Path: oracle.webcenter.doclib.view.jsf.taskflows.presenter
  • File: contentPresenter.xml


Changes made in above customization view:

  1. A new method invocation activity has been added (initLocaleForDataFile)
  2. The method invocation invokes the new NLSHelperBean
  3. The default activity is moved to the new Method invocation (initLocaleForDataFile)
  4. The outcome from the method invocation goes to determine-navigation (original default activity)

The above changes concludes the presentation modification to support a compatible localization scenario for a content driven page. In addition, this customization does not limit or disables the out of the box capabilities of WebCenter Portal.

Steps to enable above customization

  1. Start JDeveloper and open your WebCenter Portal Application
  2. Select Open Project and include the extracted project you downloaded (CPNLSCustomizations.zip)
  3. Make sure the build out put from CPNLSCustomizations project is a dependency to your Portal project
  4. Deploy your Portal Application to your WC_CustomPortal managed server
  5. Make sure your naming convention of the two data files follow above recommendation

Example result of the solution:



Solution Scenario 2 - Localization aware content creation and authoring

As you could see from Solution Scenario 1, we require the naming convention to be strictly followed. This means in the hands of a user with limited technology knowledge this can be one of the failing links in this solutions. ATEAM strongly recommends that you follow this scenario since this will eliminate this risk and also increase the editors/authors usability with a magnitude.

The current WebCenter Portal Architecture leverages WebCenter Content today to maintain, publish and manage content.  We need to ensure that this part of the architecture is on board with our new naming practice and also simplifies the creation of content for our end users.  As you probably remember, the naming convention required a prefix to be common, so I propose that we enable a new component that help you auto-configure the name of the content item's dDocName (this means that the readable title can still be in a human readable format). The new component (included in the WCP-LocalizationSupport.zip) will enable a couple of things:

  • A new service where a sequential number can be generate on request - service name: GET_WCP_LOCALE_CONTENTID
  • The content presenter is leveraging a specific function when launching the content creation wizard from within Content Presenter

The assumption is that users will create the content by clicking Create Web Content button. When clicking this button, the wizard that is opened is actually running on side of WebCenter Content server, and the file executed is contentwizard.hcsp. This file uses JSON commands that will generate operations in the content server. I have extend this file to create two identical data files instead of one.  It creates the English version by leveraging the new Service and a Global Rule to set the dDocName on the original check in screen. This global rule is available in a configuration package attached to this blog (NLSContentProfileRule.zip)

  • A set of JSON javascripts are used to create the Spanish version with the same details; except for the name where we replace the suffix with (_ES)
  • The content creation wizard ends with its out of the box behavior and then assigns the Content Presenter instance the English version.

See java script markup below - this can be changed in the (WCP-LocalizationSupport.zip/component/WCP-LocalizationSupport/publish/webcenter)

WCM.ContentWizard.CheckinContentPage.OnCheckinComplete = function(returnParams){    var callback = WCM.ContentWizard.CheckinContentPage.checkinCompleteCallback;    WCM.ContentWizard.ChooseContentPage.OnSelectionComplete(returnParams, callback);    var cgiPath = DOCLIB.config.httpCgiPath;    var jsonBinder = new WCM.Idc.JSONBinder();    jsonBinder.SetLocalDataValue('IdcService', 'DOC_INFO_SIMPLE');    jsonBinder.SetLocalDataValue('dID', returnParams.dID);    jsonBinder.Send(cgiPath, $CB(this, function(http) {      var ret = http.GetResponseText();      var binder = new WCM.Idc.JSONBinder(ret);      var dDocName = binder.GetResultSetValue('DOC_INFO', 'dDocName', 0);      if(dDocName.indexOf("_") > 0){         var ssBinder = new WCM.Idc.JSONBinder();         ssBinder.SetLocalDataValue('IdcService', 'SS_CHECKIN_NEW');         ssBinder.SetLocalDataValue('dDocName', getLocalizedDocName(dDocName, "es"));         ssBinder.SetLocalDataValue('primaryFile', 'default.xml');         ssBinder.SetLocalDataValue('ssDefaultDocumentToken', 'SSContributorDataFile');         for(var n = 0 ; n < binder.GetResultSetFields('DOC_INFO').length ; n++) {             var field = binder.GetResultSetFields('DOC_INFO')[n];             if(field != 'dID' && field != 'dDocName' && field != 'dID' &&                field != 'dReleaseState' && field != 'dRevClassID' &&                field != 'dRevisionID' && field != 'dRevLabel') {                ssBinder.SetLocalDataValue(field, binder.GetResultSetValue('DOC_INFO', field, 0));             }         }         ssBinder.Send(cgiPath, $CB(this, function(http) {}));      }    })); } function getLocalizedDocName(dDocName, lang) {    var result = dDocName.replace("_EN", ("_" + lang));    return result; }
  • By applying the enclosed NLSContentProfileRule.zip, the check in screen for DataFile creation will have auto naming enabled with localization suffix (default is English)

You can change the default language by updating the GlobalNlsRule and assign preferred prefix.  See Rule markup for dDocName field below:

<$executeService("GET_WCP_LOCALE_CONTENTID")$> <$dprDefaultValue=WCP_LOCALE.LocaleContentId & "_EN"$>

Steps to enable above extensions and configurations

  1. Install WebCenter Component (WCP-LocalizationSupport.zip), via the AdminServer in WebCenter Content Administration menus
  2. Enable the component and restart the content server
  3. Apply the configuration bundle to enable the new Global Rule (GlobalNlsRule), via the WebCenter Content Administration/Config Migration Admin

New Content Creation Experience Result



Content Editing

Content editing will by default be enabled for authoring in the current select locale since the content file is selected by (Solution Scenario 1).  This means that a user can switch his browser locale and then get the editing experience adaptable to the current selected locale.

A-Team are planning to post a solution on how to inline switch the locale of the WebCenter Portal Session, so the Content Presenter, Navigation Model and other Face related features are localized accordingly.

Content Presenter examples used in this post is an extension to following post: Enable Content Editing


CPNLSCustomizations.zip - WebCenter Portal, Content Presenter Customization : CPNLSCustomizations

WCP-LocalizationSupport.zip - WebCenter Content, Extension Component to enable localization creation of files with compliant auto naming : WCP-LocalizationSupport

NLSContentProfileRule.zip - WebCenter Content, Configuration Update Bundle to enable Global rule for new check in naming of data files : NLSContentProfileRule

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content