Lately we have been involved in engagements where internationalization has been holding the project back from success. 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.
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 java bean (oracle.webcenter.doclib.internal.view.presenter.NLSHelperBean) is enclosed in the customization project available for download at the bottom of the post:
1: public static final String CP_D_DOCNAME_FORMAT = "%s_%s";
2: public static final int CP_UNIQUE_ID_INDEX = 0;
3: private ContentPresenter presenter = null;
4:
5:
6: public NLSHelperBean() {
7: super();
8: }
9:
10: /**
11: * This method updates the configuration for the pageFlowScope to have the correct datafile
12: * for the current Locale
13: */
14: public void initLocaleForDataFile() {
15: String dataFile = null;
16: // Checking that state of presenter is present, also make sure the item is eligible for localization by locating the "_" in the name
17: if(presenter.getConfiguration().getDatasource() != null &&
18: presenter.getConfiguration().getDatasource().isNodeDatasource() &&
19: presenter.getConfiguration().getDatasource().getNodeIdDatasource() != null &&
20: !presenter.getConfiguration().getDatasource().getNodeIdDatasource().equals("") &&
21: presenter.getConfiguration().getDatasource().getNodeIdDatasource().indexOf("_") > 0) {
22: dataFile = presenter.getConfiguration().getDatasource().getNodeIdDatasource();
23: FacesContext fc = FacesContext.getCurrentInstance();
24: //Leveraging the current faces contenxt to get current localization language
25: String currentLocale = fc.getViewRoot().getLocale().getLanguage().toUpperCase();
26: String newDataFile = dataFile;
27: String [] uniqueIdArr = dataFile.split("_");
28: if(uniqueIdArr.length > 0) {
29: newDataFile = String.format(CP_D_DOCNAME_FORMAT, uniqueIdArr[CP_UNIQUE_ID_INDEX], currentLocale);
30: }
31: //Replacing the current Node datasource with localized datafile.
32: presenter.getConfiguration().getDatasource().setNodeIdDatasource(newDataFile);
33: }
34: }
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 NLSHelperBean3. 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 do not limit or disables the out of the box capabilities of WebCenter Portal.
Steps to enable above customization
Start JDeveloper and open your WebCenter Portal Application
Select "Open Project" and include the extracted project you downloaded (CPNLSCustomizations.zip)
Make sure the build out put from CPNLSCustomizations project is a dependency to your Portal project
Deploy your Portal Application to your WC_CustomPortal managed server
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. Therefore I strongly recommend that you also follow this part 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, therefore we need to make few efforts in making sure 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 we enable a new component that help you auto name the content items dDocName (this means that the readable title can still be in a human readable format). The new component (WCP-LocalizationSupport.zip) built for this scenario will enable a couple of things:
1. A new service where a sequential number can be generate on request - service name: GET_WCP_LOCALE_CONTENTID
2. The content presenter is leveraging a specific function when launching the content creation wizard from within Content Presenter. Assumption is that users will create the content by clicking "Create Web Content" button. When clicking the button the wizard opened is actually running in side of WebCenter Content server, file executed (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.- First 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)- Secondly we run a set of JSON javascripts to create the Spanish version with the same details except for the name where we replace the suffix with (_ES)- Then content creation wizard ends with its out of the box behavior and assigns the Content Presenter instance the English versionSee Javascript markup below - this can be changed in the (WCP-LocalizationSupport.zip/component/WCP-LocalizationSupport/publish/webcenter)
1: //---------------------------------------A-TEAM---------------------------------------
2: WCM.ContentWizard.CheckinContentPage.OnCheckinComplete = function(returnParams)
3: {
4: var callback = WCM.ContentWizard.CheckinContentPage.checkinCompleteCallback;
5: WCM.ContentWizard.ChooseContentPage.OnSelectionComplete(returnParams, callback);
6: // Load latest DOC_INFO_SIMPLE
7: var cgiPath = DOCLIB.config.httpCgiPath;
8: var jsonBinder = new WCM.Idc.JSONBinder();
9: jsonBinder.SetLocalDataValue('IdcService', 'DOC_INFO_SIMPLE');
10: jsonBinder.SetLocalDataValue('dID', returnParams.dID);
11: jsonBinder.Send(cgiPath, $CB(this, function(http) {
12: var ret = http.GetResponseText();
13: var binder = new WCM.Idc.JSONBinder(ret);
14: var dDocName = binder.GetResultSetValue('DOC_INFO', 'dDocName', 0);
15: if(dDocName.indexOf("_") > 0){
16: var ssBinder = new WCM.Idc.JSONBinder();
17: ssBinder.SetLocalDataValue('IdcService', 'SS_CHECKIN_NEW');
18: //Additional Localization dDocName generated
19: ssBinder.SetLocalDataValue('dDocName', getLocalizedDocName(dDocName, "es"));
20: ssBinder.SetLocalDataValue('primaryFile', 'default.xml');
21: ssBinder.SetLocalDataValue('ssDefaultDocumentToken', 'SSContributorDataFile');
22:
23: for(var n = 0 ; n < binder.GetResultSetFields('DOC_INFO').length ; n++) {
24: var field = binder.GetResultSetFields('DOC_INFO')[n];
25: if(field != 'dID' &&
26: field != 'dDocName' &&
27: field != 'dID' &&
28: field != 'dReleaseState' &&
29: field != 'dRevClassID' &&
30: field != 'dRevisionID' &&
31: field != 'dRevLabel') {
32: ssBinder.SetLocalDataValue(field, binder.GetResultSetValue('DOC_INFO', field, 0));
33: }
34: }
35: ssBinder.Send(cgiPath, $CB(this, function(http) {}));
36: }
37: }));
38: }
39:
40: //Support function to create localized dDocNames
41: function getLocalizedDocName(dDocName, lang) {
42: var result = dDocName.replace("_EN", ("_" + lang));
43: return result;
44: }
45: //---------------------------------------A-TEAM---------------------------------------
3. 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
Install WebCenter Component (WCP-LocalizationSupport.zip), via the AdminServer in WebCenter Content Administration menus
Enable the component and restart the content server
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 EditingContent 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.
NotesA-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:https://blogs.oracle.com/ATEAM_WEBCENTER/entry/enable_content_editing_of_iterative
Downloads
CPNLSCustomizations.zip - WebCenter Portal, Content Presenter Customization https://blogs.oracle.com/ATEAM_WEBCENTER/resource/stefan.krantz/CPNLSCustomizations.zip
WCP-LocalizationSupport.zip - WebCenter Content, Extension Component to enable localization creation of files with compliant auto naminghttps://blogs.oracle.com/ATEAM_WEBCENTER/resource/stefan.krantz/WCP-LocalizationSupport.zip
NLSContentProfileRule.zip - WebCenter Content, Configuration Update Bundle to enable Global rule for new check in naming of data fileshttps://blogs.oracle.com/ATEAM_WEBCENTER/resource/stefan.krantz/NLSContentProfileRule.zip
