武汉竟升公司 WebSphere Portal 内容管理升级实施方案

1

客户环境


4

2

升级步骤


4

3

准备工作


5

3.1

WPS5机器


5

3.1.1

验证数据库连接是否正确


5

3.1.2

准备迁移工具的
Fix

5

3.2

WPS6机器


6

3.2.1

安装
Portal6.0.1.3+WCM

6

3.2.2

迁移数据库
+启用安全性


6

3.2.3

获取相关管理员账号


7

3.2.4

修改
HTTP
Server 的超时时间


7

3.2.5

收集
WPS5必要的文件，便于从
WPS6访问
WPS5

7

3.2.6

确认所有已经发布的
Portlet在
WPS5 的
PortalServer/installableApps当中有
WAR包


8

3.2.7

重新创建虚拟门户


9

3.2.8

调整迁移的性能


9

4

迁移客户化资源


10

5

迁移门户配置


11

5.1

在
WPS6使用命令行方式迁移


11

5.2

从
WPS5导出门户数据


11

5.3

从
WPS5导出虚拟门户数据


12

5.4

导入门户数据到
WPS6

12

5.5

导入虚拟门户数据


13

5.6

迁移
FileServlet
Portlet(可选
)

13

5.7

重起
WPS6

13

6

迁移权限相关数据


14

7

迁移
WCM数据


16

7.1

安装迁移工具
(Web
content migration tool)

16

7.2

清理
WPS5的
WCM的错误数据


17

7.2.1

Reference checker

17

7.2.2

Site checker

17

7.2.3

Resource checker

17

7.2.4

Member fixer

17

7.2.5

确定没有加密的
Excel,WORD，
PPT等文件


18

7.3

WCM内容迁移


18

7.4

迁移
user
profiles

22

7.5

迁移
local
rendering portlet

23

7.6

迁移
remote
rendering portlet

24

7.7

WCM迁移成功后修改工作


25

7.7.1

Web content configuration files

25

7.7.2

Anchor tags and URLs

26

7.7.3

Links to Web Content Management content
from external sites

26

7.7.4

Siblings with the same name

27

7.7.5

Draft items

27

7.7.6

Navigator elements

27

7.7.7

Menu elements

28

7.7.8

Name and title fields

28

7.7.9

Connect tags

28

7.7.10

Web Content Management search

28

7.7.11

Moving objects to new libraries

28

7.7.12

API code

29

7.7.13

JSP files

29

7.7.14

Authoring portlet access changes

29

7.7.15

Referential integrity

29

7.7.16

Authoring portlet pages

29

7.7.17

Presentation templates

30

7.7.18

Removing the migration tool

30

8

迁移后验证任务


30

8.1

Verify Notes and Domino Web Access
(iNotes) portlets migration

30

8.2

Verify migration of portal clients

31

8.3

Verify migration of user customizations

31

8.4

Verify migration of credential vault
segments and slots

31

8.5

Verify migration of themes and skins

32

8.6

Verify migration of portlet applications

32

8.7

Verify migration of portlet
configuration data

32

8.8

Verify migration of virtual resources

33

8.9

Verify migration of pages

33

1

客户环境

源环境：

WPS5

平台：
windows

门户：
WebSphere
Portal Server enable 5.1.0.2+WCM (WCM
发布的服务器，最好是从发布服务器迁移
)

数据库：
Oracle
9i













目标环境：

WPS6

平台：
windows

门户：
WebSphere
Portal Server Enable 6.0.1.3 +WCM+WAS6.0.2.23

数据库：
Oracle
9i





WPS1

10.195.88.221
10.195.88.201

WPS2

10.195.88.220

LDAP

10.195.88.221







补丁：

6.0.1-WP-FP003

6.0.1.3-WP-Multi-IFPK59655

6.0.1.3-WP-Multi-IFPK61633



6.0.2-WS-WAS-WinX32-FP00000023

6.0.2-WS-WASJavaSDK-WinX32-FP00000023

2

升级步骤

任务	列表	天数
环境准备	WPS5 准备（客户提供）	1
WPS6 准备（现场安装） + 启用安全性 + 数据库迁移 +Fixpack
迁移前门户系统配置修改
WCM 数据清理
迁移门户数据	迁移客户化资源 ( 主题、皮肤等 )	1
迁移门户配置
迁移权限数据
迁移 WCM	WCM 内容迁移	1.5
User Profile 迁移
Local Rendering Portlet 迁移
Remote Rendering Portlet 迁移
验证迁移	验证迁移的数据	0.5

3

准备工作

3.1

WPS5

机器

3.1.1

验证数据库连接是否正确

查看
wpconfig.properties
配置是否正确，测试是否正常连接数据库。

PortalServer/Config
目录下执行命令
:

WPSConfig.bat
validate-database-connection-wps

3.1.2

准备迁移工具的
Fix

a.

Create an update directory in your previous WebSphere Portal
directory; for example,
C:/Program
Files/WebSphere/PortalServer/update

.

b.

Download the WebSphere Portal Update Installer from http://www.ibm.com/software/genservers/portal/support/
and then unpack the Installer to the update directory you created in the previous
step.

c.

Unzip the interim fixes from the appropriate directory of
the current WebSphere Portal directory to the update directory created in the
previous step:

§

portal_server_root

/migration/fixes/5102



Note:

All interim
fixes are already built in for version 5.1.0.4; therefore, there are no interim
fixes to apply.



For version 5.1.0.2:

§

PK14100

§

PK14103

§

PK15013

§

PK19790

§

PK20467

§

PK16371

§

PK16597

§

PK18538

§

PK21688

§

PK17690

§

PK21136

§

PK22244

§

PK23901

§

PK11536

§

PK40171 – Apply this fix using the WebSphere Portal database check and update tool wpdbupdate



d.

Enter the following command on the command line to set the
WAS_HOME environment variable for the previous version directory where you will
run the WebSphere Portal Update Installer:

Windows:


set WAS_HOME=was_old_root


For example:
set WAS_HOME=C:/Program Files/WebSphere/AppServer/setupCmdLine.bat


e.

Enter the following command on the command line to install
one or more interim fixes:

Windows: ./updatePortal.bat -install -installDir
wp_old_root -fix -fixDir wp_old_root/update -fixes list of fixes

For example
: updatePortal.bat
-install -installDir "C:/Program Files/WebSphere/PortalServer" -fix
-fixDir "C:/Program Files/WebSphere/PortalServer/update" -fixes
PK07258 PK07872

3.2

WPS6

机器

3.2.1

安装
Portal6.0.1.3+WCM

要备份。包括目录备份
+
数据库备份。

3.2.2

迁移数据库
+

启用安全性

LDAP
目录最好是同一个或者数据是一样，
LDAP
版本也一致，或者数据应该一致，否则
WCM
数据当中做用户检测部分可能存在问题。

3.2.3

获取相关管理员账号

WPS5
的管理员账号和密码：
WAS
和
PORTAL

WPS6
的管理员账号和密码：
WAS
和
PORTAL

3.2.4

修改
HTTP Server

的超时时间

Because migration can be a lengthy process,
we suggest that you change the timeout length of your HTTP server to unlimited
timeout while performing the migration task. Refer to your HTTP server
documentation for information on how to change the timeout value.

3.2.5

收集
WPS5

必要的文件，便于从
WPS6

访问
WPS5

Run the migrate property
collector task

to collect required files from the
previous version to allow the migration scripts to access the previous version:

Important:

You will need to stop the previous version of your Portal server if any
of the following statements are true for your environment:

o

If you are using a Cloudscape database

o

If there is a port conflict or resource conflict when you start the
current portal server

o

If you modified the number of groups

d.

Copy the
propcollector.xml
and

propcollector.jar

files from the
portal_server_root

/migration
directory of the current version to the
wp_old_root/config/includes
directory of the previous
version and run the following command from the
wp_old_root/config
directory of the previous
version:

Note:

If using i5/OS, the directory path is
portal_server_root_user

for the current version of WebSphere Portal and
wp_user_old_root
for the previous version of WebSphere
Portal.

§

Windows and UNIX:


WPSconfig.{sh|bat} prop-collector -DDbPassword=wpsdb_password



§

i5/OS:

Choose one of the following commands
based on the version of WebSphere Application Server that you are using:

§

WebSphere Application Server 5.x:


WPSconfig.sh -instance instance_name

prop-collector -DDbPassword=wpsdb_password



where instance_name

is the name of the
WebSphere Application Server profile where WebSphere Portal is installed.

§

WebSphere Application Server 6.x:


WPSconfig.sh -profileName profile_root

prop-collector -DDbPassword=wpsdb_password



where profile_root

is the name of the
WebSphere Application Server profile where WebSphere Portal is installed; for
example, wp_profile.

§

Important:

The following information
applies to running the above command:

§

-DDbPassword=wpsdb_password

is not required if the value is already defined in the
wpconfig.properties

file.

§

Ensure that the values for
DbUrl
and
DbName
are
defined in the
wpconfig.properties

file.

§

Ensure that the value for
WpsHostName
in the
wpconfig.properties

file is the fully-qualified host name of the Web server that WebSphere
Application Server is configured to use and is NOT

"localhost".

e.

Copy the
wp_old_root/config/includes/propcollectorOutput.zip
file from the previous version to the
portal_server_root

/migration
directory on the current version.

f.

Run the following command from the
portal_server_root

/migration
directory of the current version to extract the
propcollectorOutput.zip
file:

WPmigrate.{sh|bat} collector-extract

3.2.6

确认所有已经发布的
Portlet

在
WPS5

的
PortalServer/installableApps

当中有
WAR

包

Make portlet applications available to migration
tasks for deployment



The
portal_server_root

/installedApps

directory
contains a list of all portlet applications that are deployed on your previous
WebSphere Portal system. Depending on the features that are used by these
portlets, they might have to first be upgraded to work with the current version
of WebSphere Portal. Refer to the instructions that are provided in the Migrating
your customized resources
section to determine if you need to upgrade your
portlets.

Some of the WAR files in the
portal_server_root

/installedApps

directory
might have been shipped with the current version of WebSphere Portal. In that
case, there is no need to manually upgrade corresponding portlets. You can
safely use the corresponding WAR file from the
portal_server_root

/installableApps

directory as
an upgraded version of the portlet.

Before running migration tasks, all the upgraded
portlets must be made available in the
portal_server_root

/installableApps

directory of
your current WebSphere Portal system. This directory has the sample portlets
that ship with the current version of WebSphere Portal; do not overwrite these
with the sample versions that shipped with earlier versions of WebSphere
Portal.

3.2.7

重新创建虚拟门户

Create the virtual portal from your previous version in the
current version:

In order to migrate the data from your previous
virtual portal into the current version, you must recreate the virtual portal
in the current version. Use the Virtual Portal Manager to create the virtual
portal in the current version.

3.2.8

调整迁移的性能

Required performance tuning for exporting and
importing large groups and resources



a.

Check your LDAP server to determine the number of groups and
perform the appropriate steps if the number is greater than 200:

§

Perform the following steps on the previous
version of WebSphere Portal if migrating from version 5.1.x:





i.

Change to the
wp_old_root/wmm

directory of
the 5.1.x directory.



ii.

Open the
wmm.xml

file and the
maximumSearchResults

attribute.
You must change the numerical value of
maximumSearchResults

to a number
greater than the actual number of groups on the LDAP server; for example if the
LDAP server has 300 groups, then enter 301.



iii.

Save your changes.



iv.

If this is a clustered environment, change to the
was_old_root/config/wmm

directory of
the 5.1.x system.



v.

Open the
wmm.xml

file and the
maximumSearchResults

attribute.
You must change the numerical value of
maximumSearchResults

to a number
greater than the actual number of groups on the LDAP server; for example if the
LDAP server has 300 groups, then enter 301.



vi.

Save your changes.



vii.

If this is a clustered environment, change to the
dmgr_old_root/config/wmm

directory on
the deployment manager machine of the 5.1.x system.



viii.

Open the
wmm.xml

file and the
maximumSearchResults

attribute.
You must change the numerical value of
maximumSearchResults

to a number
greater than the actual number of groups on the LDAP server; for example if the
LDAP server has 300 groups, then enter 301.



ix.

Save your changes.

§

Perform the following steps on the current
version of WebSphere Portal after completing any security-related tasks, such
as, but not limited to, running the

enable-security-ldap

task:





i.

Change to the
portal_server_root

/wmm

directory of
the current version.



ii.

Open the
wmm.xml

file and the
maximumSearchResults

attribute.
You must change the numerical value of
maximumSearchResults

to a number
greater than the actual number of groups on the LDAP server; for example if the
LDAP server has 300 groups, then enter 301.



iii.

Save your changes.

b.

Change the LDAP server search parameters based on your
server's documentation to an unlimited value or a value large enough to handle
the exporting and importing of large groups and resources; for example:

§

Search size limit: Unlimited

§

Search time limit: Unlimited

§

Idle time out for paged searches: 172800

Note:

This value
should be 48 hours or more; no unlimited option is documented (value is in
seconds).

4

迁移客户化资源

主题和皮肤：

WPS5的皮肤和主题和WPS6有些不一样，在WPS6的基础上新建一个主题，把相关的资源替换（css
or Images）。

其他：

如果客户部署了协作的Portlet、Structs
Framework的portlet、业务流程的Portlet或者Portal搜索数据，请参考Inforcenter的章节:

l

Migrating
cooperative portlets that use IBM Portlet API

l

Migrating
portlets built with Struts Portlet Framework

l

Migrating
business process applications

l

Migrating
Portal Search between portal versions

5

迁移门户配置

5.1

在
WPS6

使用命令行方式迁移

命令在
portal_server_root

/migration

目录

Windows:


WPmigrate.bat

5.2

从
WPS5

导出门户数据

The
export-portal-content

task exports the WebSphere Portal content from the previous version.

Important:

Before running the
export-portal-content

task, perform the following steps:

1.

Stop the current WebSphere Portal server.
(
停止
WPS6)

2.

Start the server for your previous version of WebSphere Portal and ensure
it is accessible to the network.
(
启动
WPS5)

The syntax for invoking a migration task is as follows:

Windows:


WPmigrate.bat export-portal-content
-DPrevPortalAdminId=portaladminid

-DPrevPortalAdminPwd=password



PrevPortalAdminId

indicates a portaladminid

from the previous version
of WebSphere Portal

PrevPortalAdminPwd

indicates the password

for the above portaladminid

5.3

从
WPS5

导出虚拟门户数据

如果没有虚拟门户，跳过这一步。

The
export-portal-content

task exports the WebSphere Portal content from the previous version.
但是在
WPS6
的
portal_server_root

/migration

目录运行。

Important:

Before running the
export-portal-content

task, perform the following steps:

1.

Stop the current WebSphere Portal server
(
停止
WPS6).

2.

Ensure the server for your previous version of WebSphere Portal is running
and accessible to the network.
（启动
WPS5
）

The syntax for invoking a migration task is as follows:

Windows:


WPmigrate.bat export-portal-content
-DPrevPortalAdminId=portaladminid

-DPrevPortalAdminPwd=password

-DVirtualPortal=URL context



where:



PrevPortalAdminId

indicates a portaladminid

from the previous version
of WebSphere Portal

PrevPortalAdminPwd

indicates the password

for the above portaladminid



URL
context

is the context extension for the virtual
portal URL; see the URL Context description row in the Virtual Portal
Manager portlet

5.4

导入门户数据到
WPS6

The
import-portal-content

task imports the content
from the previous version of WebSphere Portal into the current version of
WebSphere Portal.

在
WPS6
的
portal_server_root

/migration

目录运行。

Important:

Before
running the
import-portal-content

task, perform the
following steps:

1.

Stop the previous WebSphere Portal server.
(
停止
WPS5)

2.

Start the server for your current version of WebSphere
Portal and ensure it is accessible to the network.
(
启动
WPS6)

3.

Specify the
WasUserid

and
WasPassword

in the
wpconfig.properties

file; see Configuration
properties reference
for information about editing the properties file.

The syntax for invoking the migration task is as follows:

Windows:


WPmigrate.bat
import-portal-content -DPortalAdminId=

portaladminid

-DPortalAdminPwd=

password



where:



PortalAdminId

indicates a portaladminid
from the current version of WebSphere Portal

PortalAdminPwd

indicates the password
from the above portaladminid


Note

:

If running
the
import-portal-content

task multiple times, you
must Restart
the servers
before rerunning the task.

5.5

导入虚拟门户数据

如果没有虚拟门户，跳过这一步。

The
import-portal-content

task imports the content
from the previous version of WebSphere Portal into the current version of
WebSphere Portal.

Important:

Before
running the
import-portal-content

task, perform the
following steps:

1.

Stop the previous WebSphere Portal server.
(
停止
WPS5)

2.

Ensure the server for your current version of WebSphere
Portal is running and accessible to the network.
(
启动
WPS6)

Tip:

Before importing each
Virtual Portal, backup your database.

The syntax for invoking the migration task is as follows:

Windows:


WPmigrate.bat
import-portal-content -DPortalAdminId=

portaladminid

-DPortalAdminPwd=

password

-DVirtualPortal=

URL context



where:



PortalAdminId

indicates a portaladminid
from the current version of WebSphere Portal

PortalAdminPwd

indicates the password
from the above portaladminid


URL context

is the context
extension for the virtual portal URL; see the URL Context description row
in the Virtual Portal Manager portlet

Note:

If running the
import-portal-content

task multiple
times, you must Restart
the servers
before rerunning the task.

5.6

迁移
FileServlet Portlet(

可选
)

If you cloned the FileServer
portlet in previous versions and supplied HTML files in the
wp_old_root/installedApps/FileServer.war/FileServerPortlet/html

directory,
you must copy those files to the
portal_server_root

/installedApps/FileServer.war/FileServerPortlet/html

directory,
after running the import task and before restarting the server, to make the
files accessible in the current version.

5.7

重起
WPS6

After completing the
import-portal-content
task, restart the following server on the current version only:

1.

Open a command prompt and change to the following directory:

o

Windows:


was_profile_root

/bin


2.

Enter the following command:

o

Windows

:
stopServer.bat WebSphere_Portal -user admin_userid

-password admin_password



3.

Enter the following command:

o

Windows:


startServer.bat WebSphere_Portal

6

迁移权限相关数据

虽然前面成功的迁移了门户配置数据，但是有些权限配置相关数据，是没有迁移的，例如：凭证保险库相关数据，资源许可权的数据等等。





1.

Migrating permissions on All Authenticated
Portal Users and All Portal User Groups group



Permissions on User
Groups allows principals to perform the following tasks:

o

Edit group information

o

Change group membership

o

Change the access rights of the group members

Follow this step to migrate permissions on user
groups:

On the current WebSphere Portal system, use the
User and Group Permissions portlet, the Resource Permissions portlet, or the
XML configuration interface to assign the principals to roles on the
appropriate user groups. For more information, refer to the portlet helps or The
XML configuration interface
. Follow these steps to assign the principals to
roles on the appropriate user groups using the Resource Permissions portlet:



i.

Log in to portal using an administrator account.



ii.

Open the Resource permissions
portlet.



iii.

Select the Resource type
User
Groups.



iv.

Select the All Authenticated Portal
Users
option and analyze the existing role assignments on that user
group.



v.

Use the Resource permissions
portlet to create the same role assignments on the new portal.



vi.

Repeat these steps for All Portal
User Groups
.

2.

Migrating
permissions on WebSphere Portal 5.1.x administrative resources



Log onto your previous version of WebSphere
Portal and go to the Manage pages portlet. View and make note of the access
control settings for your previous version. Then log into your current version
of WebSphere Portal and go to the Manage pages portlet. Recreate the access
control from your previous version in your current version.

5.1.x Administrative Page	5.1.x Administration Portlet title
Portal User Interface o Manage Pages o Themes and Skins	Manage Pages Themes and Skins
Portlet Management o Web Modules o Applications o Portlets o Web Services o Web Clipping	Manage Web Modules Manage Applications Manage Portlets Web Service Configuration Web Clipping Editor
Access o Users and Groups o Resource Permissions o User and Group Permissions o Credential Vault	Manage Users and Groups Resource Permissions User and Group Permissions Credential Vault
Portal Settings o Global Settings o URL Mapping o Custom Unique Names o Supported Markups o Supported Clients o Search Administration o Import XML	Global Settings URL Mapping portlet Manage Custom Unique Names Manage Markups Manage Clients Manage Search Collection Import XML
Portal Analysis o Frequent Users o Enable Tracing	Frequent Users Enable Tracing
Portal Content o Manage Document Libraries	Manage Document Libraries
Virtual Portals o Manage Virtual Portals	Virtual Portal Manager
Page Customizer o Content Layout o Appearance o Locks o Wires	Edit Layout Appearance portlet Page Locks Portlet Wiring Tool
Page properties	Page properties
Organize Favorites	Organize Favorites
Login	Login portlet
Edit My Profile	Edit My Profile

3.

Migrating credential vault data



When you migrated the WebSphere Portal configuration using either the
command line script or the wizard, the Credential Vault slots and segments were
also migrated. This section assumes that the WebSphere Portal migration was
successfully completed.

Existing credential secrets
must be handled differently depending on your environment:

o

WebSphere Portal Default Vault: complete the following procedure if you
want to migrate existing credential secrets to the current WebSphere Portal
system.

o

Third-party vault implementation (Tivoli Access Manager): No additional
steps are required. Existing credential secrets can be used in the current
WebSphere Portal system.

Note:

If you decide not to migrate existing credential secrets, users must
provide their credential information the first time a Version 6.0 portlet
attempts to use the data.



（参考
Inforcenter
）

7

迁移
WCM

数据

7.1

安装迁移工具
(Web content migration
tool)

Run the WPSconfig.
{sh | bat} configure-wcm-migration task from the portal_server_root

/config directory of
your new system.

Windows:

WPSconfig.bat
configure-wcm-migration -DWasUserId=username -DWasPassword=password

The user specified in
the command must be a WebSphere Application Server administrator.

7.2

清理
WPS5

的
WCM

的错误数据

7.2.1

Reference checker

To view a report:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEReferenceChecker

To correct reference errors, use the following URL:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEReferenceChecker&fix=true

7.2.2

Site checker

To view a report, use the
following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPESiteChecker
To correct site errors, use
the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPESiteChecker&fix=true

7.2.3

Resource checker

To view a report, use the
following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEResourceChecker
To correct resource errors,
use the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEResourceChecker&fix=true

7.2.4

Member fixer

To view a report, use the
following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=MemberFixer
To update changes to Member
Manager users and groups in Web Content Management items, use the following
URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=MemberFixer&fix=true

7.2.5

确定没有加密的
Excel,WORD

，
PPT

等文件

有加密的
excel/word/ppt
在
WCM
作为附件，会迁移失败，应该在迁移之前去掉保护。

7.3

WCM

内容迁移

1.

Copy the
portal_server_root

/wcm/config/

folder from
your old system(WPS5) to a temporary migration folder on the new system(WPS6).
Do not overwrite the
portal_server_root

/wcm/config/

on the new
system.

2.

Depending on which data repository your old system uses, you
will need to copy the following files from your old system to the
portal_server_root

/wcm/migration/exporter/lib

folder of
your new system. These will typically be:

o

Oracle Enterprise Edition

: ojdbc14.jar

3.

Update the
portal_server_root

/wcm/migration/exporter/classpath.properties

by adding the
names of the files you copied in step 2 to the value of the
exporter.classpath

property.

4.

If migrating from a DB2 repository, you will need to edit
the following files located in the
/wcm/config/

folder you
created in step 1:

o

aptrixjpe.properties

: Ensure
jdbc.url=jdbc:db2://<db2
host name>:<port number>/wcmdb

is configured to point
to the database of the old system and ensure that there are no spaces before or
after the URL.

o

connect.cfg

: Ensure
<jdbc:db2://<db2
host name>:<port number>/wcmdb
driver="com.ibm.db2.jcc.DB2Driver" />

Note:

The port
number for DB2 on your new system can be found under
%systemroot%/system32/drivers/etc/services

on Windows
systems or
/etc/services

on UNIX systems.

5.

If migrating from an embedded Cloudscape repository, stop
the portal server on the old system and then copy this database to your new
system before migrating Web Content Management. You will need to edit the
following files located in the
/wcm/config/

folder you
created in step 1:

o

aptrixjpe.properties

: Ensure
jdbc.url=jdbc:db2j:<path_to_database>

is configured
to point to the location of the Cloudscape database on the new system and
ensure that there are no spaces before or after the URL.

o

connect.cfg

: Ensure
<jdbc:db2j:<path_to_database>
driver="com.ibm.db2j.jdbc.DB2jDriver" />

6.

Update the
portal_server_root

/wcm/migration/config/migration.properties

file on your
new system. Confirm that the following parameters are set as specified and
modify them if necessary:

o

export.path

:

The path on
the local file system where exported data will be saved.

o

import.path

:

The directory
on the local file system where transformed data is saved.

o

summary.path

:

The path on
the local file system where summary configuration files will be created. These
files will be used when migrating a secondary system.

o

legacy.config.path

:

The path on
the local file system where the old Web Content Management configuration is
located. See step 1.

o

import.servlet.url

: The URL of
the import servlet, running on the new system. Replace
localhost

with the
appropriate host name for the new system.

o

import.library.name

:

The name of
the library created during import.

o

import.library.locale

:


zh



7.

Increase the
total transaction lifetime timeout

of your new
WebSphere Portal server to 1200 seconds through the WebSphere Application
Server administrative console. Go to Application Servers
>
server

>
Container Services
>
Transaction Service
.
See the WebSphere Application Server information center for more information.
Make a note of the current
total transaction lifetime timeout

so that it
can be restored in step 10.

8.

Restart the portal application server.

9.

Run the
wcmmigrate all-data

task from the

portal_server_root

/wcm/migration

directory of
your new system.

Important:

Before you
run the
wcmmigrate

task, make sure that the portal server on the
new system is running.

o

Windows:


wcmmigrate.bat
-user username -password password all-data



The user specified in the command must be a
WebSphere Portal administrator.

Notes:

All errors, information and warnings are logged to the console as migration is performed. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to do the following: Review any error messages displayed during the migration. Review the migration log files located under the portal_server_root /wcm/migration/log folder. Make sure you have copied the correct files and directories as described in the primary and secondary migration tasks. Review the settings in the portal_server_root /wcm/migration/config/migration.properties file. Running individual wcmmigrate all-data commands When you run the wcmmigrate all-data task, a set of commands are executed. To troubleshoot the wcmmigrate all-data task, you can run each of the commands separately. They should be run in the order shown below. validate This validates the migration.properties file, network connectivity and user permissions. This requires a user-name and password. estimate-data This provides an estimate of the time taken and space required for data migration. export-data This exports items from the old system. transform-data This transforms exported items so that they are ready to be imported into the new system. import-data This imports the transformed items. This requires a user-name and password. For example, to run the validate command, run the following command from the portal_server_root /wcm/migration directory. Windows: wcmmigrate.bat -user username -password password validate The user specified in the command must be a WebSphere Portal administrator. Resuming or restarting wcmmigrate commands Once you have identified and fixed the issue that was causing a migration to fail, you have a choice of either restarting a wcmmigrate command, or resuming a wcmmigrate command from the point where a migration error occurred. For example, to restart the wcmmigrate all-data command, enter the following from the portal_server_root /wcm/migration directory. Windows: wcmmigrate.bat -user username -password password all-data -restart UNIX: ./wcmmigrate.sh -user username -password password all-data -restart i5/OS: wcmmigrate.sh -user username -password password all-data -restart The user specified in the command must be a WebSphere Portal administrator. To resume the wcmmigrate all-data command from the point where migration failed, enter the following from the portal_server_root /wcm/migration directory. Windows: wcmmigrate.bat -user username -password password all-data -resume UNIX: ./wcmmigrate.sh -user username -password password all-data -resume i5/OS: wcmmigrate.sh -user username -password password all-data -resume The user specified in the command must be a WebSphere Portal administrator. Log tracing levels By default, the migration log trace level is set to "fine". This is set in the portal_server_root /wcm/migration/config/migration.properties file. If you change this setting to "finer" or "finest", data migration may slow or fail. If migration is still slow with a trace level of "fine", you should change the trace-level to "info".

10.

Verify the migration by reviewing the migration console. The
message "command successful" is displayed after a successful
migration. If the message "command failed" is displayed upon
completion you will need to review the previous steps. See Troubleshooting
Web Content Management migration
for further information.

Note:

The total
number of items exported, transformed and imported may not be equal, as some
items will be merged and other items added during the migration process.

11.

Restore the
total transaction lifetime timeout

setting to
the original setting that was changed in step 7.

12.

Restart the portal application server.

13.

Review the configuration of the library created when the
data was migrated and make changes as required. For example, you will need to
enable user access to this library by adding users and groups to each library
role. See Working
with libraries
for further information on configuring a Web content
library.

14.

Syndicate the migrated data to all the other servers in your
new Web content system. See Syndication
for further information.

7.4

迁移
user profiles

After
migrating your primary data you must update the portal users to use the
migrated data.

Note:

If you are using dynamic
keywords then you must migrate Member Manager before migrating user profiles.
See Migrating
the remaining access control configuration
for further information. If you
are not using dynamic keywords, or if you have already migrated Member Manager
as part of your core IBM®
WebSphere®
Portal migration,
you do not need to do migrate Member Manager.

1.

If you are migrating users on a primary system, go to step
3. If you are migrating users on a secondary system, copy the summary configuration
files created when migrating your primary system to a folder on the secondary
system. See
summary.path

in the data
migration
topic.

2.

Update the
portal_server_root

/wcm/migration/config/migration.properties

file. Confirm
that the following parameters are set as specified and modify them if
necessary:

o

summary.path

:

The path on
the local file system where the old IBM Workplace Web Content Management™
summary configuration files were copied in step 1.

3.

If your LDAP server contains more than 200 users, you must
perform the following steps. Otherwise, proceed to step 4.

a.

Stop your WebSphere Portal server.

b.

Make a backup
of
portal_server_root

/wmm/wmm.xml

named
wmm.xml.bak

.

Note:

If using
i5/OS,
wmm.xml

is located under
portal_server_root

.

c.

Edit
portal_server_root

/wmm/wmm.xml

and change
the following settings:

§

Change
maximumSearchResults

,
maximumSearchResultsForSortingAndPaging

and
maximumTotalSearchResultsForSortingAndPaging

to a number
higher than the total number of users. For example, if you have 300 users, you
must change these settings to at least 301.

§

Change
searchTimeOut

to 2,000,000.

4.

Increase the
total transaction lifetime timeout

of your new
WebSphere Portal server to 3600 seconds through the WebSphere Application
Server administrative console. Go to Application Servers
>
server

>
Container Services
>
Transaction Service
.
See the WebSphere Application Server information center for more information.
Make a note of the current
total transaction lifetime timeout

so that it
can be restored in step 7.

5.

Restart the portal application server.

6.

Run the
wcmmigrate users

task from the

portal_server_root

/wcm/migration

directory,
where portal_server_root
is the install directory path of the
current version of WebSphere Portal.

o

Windows:


wcmmigrate.bat
-user username -password password users



The user specified in the command must be a
WebSphere Portal administrator.

7.

Verify the user migration by reviewing the migration
console. The message "command successful" is displayed after a
successful migration. If the message "command failed" is displayed
upon completion you will need to review the previous steps. See Troubleshooting
Web Content Management migration
for further information.

8.

Restore the
total transaction lifetime timeout

setting to
the original setting that was changed in step 4.

9.

If you performed step 3, you must do the following:


.

Stop your WebSphere Portal server.

a.

Restore the
wmm.xml.bak

file you
created in step 3.b to
portal_server_root

/wmm/wmm.xml

.

10.

Restart the portal application server.

7.5

迁移
local rendering portlet

After
migrating your primary data you must re-configure all local rendering portlets
to use the migrated data.

Note:

You must migrate Web
content data before migrating a local rendering portlet. See Migrating
Web content data
for further information.

Note:

If you have a small
number of local rendering portlets, it may be simpler to install and configure
new local rendering portlets to use the migrated data instead of migrating any
existing portlets. See Configuring
the local rendering portlet
for further information.

1.

If you are migrating one or more local rendering portlets on
a primary system, go to step 3. If you are migrating one or more local
rendering portlets on a secondary system, copy the summary configuration files
created when migrating your primary system to a folder on the secondary system.
See
summary.path

in the data
migration
topic.

2.

Update the
portal_server_root

/wcm/migration/config/migration.properties

file. Confirm
that the following parameters are set as specified and modify them if
necessary:

o

summary.path

: The path on the local
file system where the old IBM Workplace Web Content Management™ summary
configuration files were copied in step 1.

o

virtual.portal

: If migrating a local
rendering portlet located on a virtual portal, you must enter the name of the
virtual portal.

3.

Run the
wcmmigrate configure-local

task from the

portal_server_root

/wcm/migration

directory,
where portal_server_root
is the install directory path of the
current version of WebSphere Portal.

o

Windows:


wcmmigrate.bat
-user username -password password configure-local



The user specified in the command must be a
WebSphere Portal administrator.

4.

Verify the migration by reviewing the migration console. The
message "command successful" is displayed after a successful
migration. If the message "command failed" is displayed upon
completion you will need to review the previous steps. See Troubleshooting
Web Content Management migration
for further information.

5.

Verify the configuration of the migrated local rendering
portlet. See Configuring
the local rendering portlet
for further information on configuring a local
rendering portlet.

Note:

Restart the
portal server after completing the above steps to verify that the portlets have
been configured correctly.

7.6

迁移
remote rendering portlet

After
migrating your primary data you must re-configure all remote rendering portlets
to use the migrated data.

Note:

You must migrate Web
content data on the system that the remote rendering portlet is configured to
use before migrating a remote rendering portlet. See Migrating
Web content data
for further information.

Note:

If you have a small
number of remote rendering portlets, it may be simpler to install and configure
new remote rendering portlets to use the migrated data instead of migrating any
existing portlets. See Configuring
the remote rendering portlet
for further information.

1.

If you are migrating one or more remote rendering portlets
on a primary system, go to step 3. If you are migrating one or more remote
rendering portlets on a secondary system, copy the summary configuration files
created when migrating your primary system to a folder on the secondary system.
See
summary.path

in the data
migration
topic.

2.

Update the
portal_server_root

/wcm/migration/config/migration.properties

file. Confirm
that the following parameters are set as specified and modify them if
necessary:

o

summary.path

:

The path on
the local file system where the old IBM Workplace Web Content Management
summary configuration files were copied in step 1.

o

virtual.portal

: If migrating a remote
rendering portlet located on a virtual portal, you must enter the name of the
virtual portal.

3.

Update the
portal_server_root

/wcm/migration/config/remote_rendering.properties

file. Confirm
that the following parameters are set as specified and modify them if
necessary:

o

remote.host.base.path.list

:

Enter the
remote host base path of old remote rendering portlet. This is the "Web
Content Management Server Host" specified in the old remote rendering
portlet configuration. For example,

o      

remote.host.base.path.list=http://oldhostname:9081

Note:

If all your
old remote rendering portlets use data from a single system you can specify
remote.host.base.path.list=all

.

o

WCM_REMOTE_HOST_BASE_PATH

:

Enter the
remote host base path of the server the remote rendering portlet is being
migrated to. For example,

o      

WCM_REMOTE_HOST_BASE_PATH=http://newhostname:9081

4.

Run the
wcmmigrate configure-remote

task from the

portal_server_root

/wcm/migration

directory,
where portal_server_root
is the install directory path of the
current version of IBM WebSphere Portal.

o

Windows:


wcmmigrate.bat
-user username -password password configure-remote



The user specified in the command must be a
WebSphere Portal administrator.

5.

Verify the migration by reviewing the migration console. The
message "command successful" is displayed after a successful
migration. If the message "command failed" is displayed upon
completion you will need to review the previous steps. See Troubleshooting
Web Content Management migration
for further information.

6.

Verify the configuration of the migrated remote rendering
portlet. See Configuring
the remote rendering portlet
for further information on configuring a
remote rendering portlet.

Note:

Restart the
portal server after completing the above steps to verify that the portlets have
been configured correctly.

7.7

WCM

迁移成功后修改工作

The
IBM®
Workplace Web Content Management™ migration process does not
automatically update your Web content to use all the new features of the
current release. The following steps are recommended to update your old Web
content to take advantage of the new Web Content Management features.

7.7.1

Web content configuration files

The
Web content configuration files
connect.cfg

and
aptrixjpe.properties

have been
deprecated and replaced by the
WCMConfigService.properties

file. No
configuration settings from your old system are migrated to this file. You will
need to edit this file and update settings to match your old configuration if
required.

The
WCMConfigService.properties

file is
located under:

Windows:


portal_server_root

/wcm/shared/app/config/wcmservices



Note:

The JDBC URL
property


Database driver URLs now need to contain escape characters. You
will need to edit any JDBC URLs copied from an old
connect.cfg

file. For
example:

Old URL:

connect.connector.sqlconnector.databases.jdbc:microsoft:sqlserver://host:port;DatabaseName=dbname

New URL:

connect.connector.sqlconnector.databases.jdbc/:microsoft/:sqlserver/://host/:port;DatabaseName/=dbname

7.7.2

Anchor tags and URLs

You
should replace any anchor tags or URLs in presentation templates or element
designs by using either a link element, or using the "add link"
feature in HTML and rich text fields and elements. See the Link
element
and Inserting
a link in an element
topics for further information.

To assist in this process, the following files are created under
the summary path folder specified during data migration:

transformed_contents.links

transformed_library_components.links


transformed_content_components.links


transformed_presentation_templates.links


These
files can be used as reference material as they list the old and new names and
paths of content items, components (library components), elements (content
components) and presentation templates.

7.7.3

Links to Web Content Management content from external sites

During
migration, some items will be merged, added or renamed. You may need to update
links to Web Content Management content from external sites.

To assist in this process, the following files are created under
the summary path folder specified during data migration:

transformed_contents.links

transformed_library_components.links


transformed_content_components.links


transformed_presentation_templates.links


These
files list the old and new names and paths of content items, components
(library components), elements (content components) and presentation templates.

7.7.4

Siblings with the same name

Unlike
previous versions of Web Content Management, you are not able create two
sibling Web Content items using the same name in IBM WebSphere®
Portal version 6.0.

For example, your old system may have the following site
framework:

MySite

MySiteArea

MySiteArea

During migration, the second site area will be renamed as
"MySiteArea_1". The site framework will now look like this:

MySite

MySiteArea

MySiteArea_1

Any
references to the path "MySite/MySiteArea" will be left unchanged,
but will now only point to the site area named "MySiteArea". You will
need to edit any paths that should now point to "MySite/MySiteArea_1"
instead.

This
example also applies to other siblings such as categories and content items.

7.7.5

Draft items

Any
draft sites, site areas and taxonomies that have child items will be published
during migration, as will their children. Any items that have had there status
changed from draft to published are listed in
published_draft_items.txt

located under
the summary path folder specified during data migration. You should review this
file and check that any changes to these published items are valid.

If no
items have had there status changed from draft to published, this file will not
be created.

7.7.6

Navigator elements

Paging
is now supported in the design of navigator elements. After migration, the
maximum number of items to be displayed per page is set at one hundred by
default. If any or your navigators display more than one hundred items, you
will need to edit this figure. You can also add a paging element to your
navigator design. See Defining
navigator element design options
for further information.

7.7.7

Menu elements

A
"no result" design has been added to menu elements. You must edit all
your menus and enter appropriate text in the "no result" design.
Otherwise, nothing will be displayed when a menu finds no results. See Defining
menu element formatting options
for further information.

7.7.8

Name and title fields

A
title field has been added to the identification section of all items. The
title is the text displayed to end-users when viewing a list of items in the
authoring portlet. Unlike the name, titles can use double-byte and non-ASCII
characters. When migrated, the current name is also copied to the title field.
You will need to edit any items where you would like to use a different title
than one created during migration.

Any
Web content tags that use the
field="name"

attribute,
such as the placeholder tag, can be changed to use
field="title"

as well.

7.7.9

Connect tags

The
use of "connect" tags has been deprecated, with the exception of
component caching. Content that uses "connect" tags will still work,
but it is recommended that "connect" tags be replaced with other
standard Web content features. See Displaying
data from external sources
for further information.

7.7.10

Web Content Management search

The
Web Content Management search module is no longer supported. The WebSphere
Portal search features are now used to search for Web Content.

Any
search forms that use the Web Content Management search module must be replaced
or updated with search forms using the WebSphere Portal search features. See Searching
Sites
for details on using the WebSphere Portal search features with Web
content.

7.7.11

Moving objects to new libraries

The
Web Content Management migration process will only create a single library. To
implement multiple libraries, you will need to create new libraries and move
items from the migrated library into the new libraries. See Copying
and moving items
for further information.

7.7.12

API code

After
migration, any Web Content Management API code should still function as normal.
The API will, by default, use the library specified in the
WCMConfigService.properties file.

Once
you create new libraries and add items to those libraries, you will need to
update your API code to be library-specific by using the
setCurrentDocumentLibrary method. See the Javadoc HTML files located under the
was_profile_root

/AppServer/profiles/wp_profile/installedApps/nodename/wcm.ear/ilwwcm.war/webinterface/

folder for
further information on using this method.

7.7.13

JSP files

Any
JSP files used on your old system will need to be manually copied to your new
system. See JSP
elements
for details on where to store JSP files.

7.7.14

Authoring portlet access changes

You
no longer assign access to the different views in the authoring portlet by
configuring the authoring portlet. Access to the different views in the
authoring portlet is now determined by the role assigned to users and groups.
See Using
item type roles within a library
for further information.

7.7.15

Referential integrity

Referential
integrity features have been added in this release. See Collaborative
authoring
and Deleting
items
for further information.

These
features are not applied to a migrated items that contain element or component
tags until the item is opened and saved in the authoring portlet.

7.7.16

Authoring portlet pages

Although
authoring portlets are not migrated, any portal pages that previously displayed
an authoring portlet on your old system are migrated as blank pages. You can
either delete these pages, or add a new authoring portlet to the blank page.

7.7.17

Presentation templates

Migrated
presentation templates may contain additional HTML header information not
present in the original presentation template. The additional header
information will not affect any content rendered in the presentation template
and can be deleted.

7.7.18

Removing the migration tool

To
remove the migration tool, run the
remove-wcm-migration

task from the

portal_server_root

/config

directory of
your new system.

Windows:


WPSconfig.bat
remove-wcm-migration

8

迁移后验证任务

This
section provides information that you can use to verify the success of the
migration tasks.

Perform the appropriate tasks to verify that your migration was
successful:

1.

Verify
Notes and Domino Web Access (iNotes™) portlets migration


2.

Verify
migration of portal clients


3.

Verify
migration of user customizations


4.

Verify
migration of credential vault data


5.

Verify
migration of themes and skins


6.

Verify
migration of portlet applications


7.

Verify
migration of portlet configuration data


8.

Verify
migration of virtual resources


9.

Verify
migration of pages

8.1

Verify Notes and Domino Web Access
(iNotes) portlets migration

a.

Log in to the current WebSphere Portal Administrative
Interface.

b.

Click Portlet Management
> Portlets
.

c.

There should be a portlet in the portlet list for each
portlet that existed in the previously installed version.

Note:

In some
previous versions of WebSphere Portal, these portlets were individual portlets,
while in the current version, they are copies of one portlet.

d.

Select each migrated portlet, click Configure
Portlet
, and verify that the portlet settings were migrated correctly.
If you are migrating pages that had Notes portlets in them, the portlets should
be on the page after migration and should work as they did on the previous
version.

8.2

Verify migration of portal clients

e.

Log in to the current WebSphere Portal Administrative
Interface.

f.

Click Administration
> Portal
Settings
> Supported Clients
.

g.

Verify that the portal clients that you migrated show up in
the list of supported clients.

h.

Select the clients that were migrated and click Edit
Selected Client
to verify that all settings for the client were
migrated.

i.

Verify that your migrated clients are able to access
WebSphere Portal.

8.3

Verify migration of user customizations

User customizations are artifacts that are
attributed to a portal user that has EDIT but not MANAGE permissions on a page.
These are created when such a user changes the layout of a page or edits
portlet settings.

j.

Log in to the current WebSphere Portal with credentials of
users having the customizations.

k.

Verify that all user customizations from the previous
version are present in the current version. You can also pick users at random
and ensure that the users see the correct customizations in the current version
by comparing them visually to customizations in the previous version.

8.4

Verify migration of credential vault
segments and slots

These procedures help verify that the credential
slots and segments were migrated successfully. Existing credential vault data
must be migrated with a separate manual procedure that is described in the Migrating
the remaining access control configuration
section.

l.

Log in to the current WebSphere Portal Administrative
Interface.

m.

Click Access
and then click Credential
Vault
on the left navigation.

n.

Using the Manage vault segments
and Manage
system vault slots
options, verify that credential segments and slots
from the previous version are now also present in the current version.

8.5

Verify migration of themes and skins

o.

Log in to the current WebSphere Portal Administrative
Interface.

p.

Click Portal user interface
> Themes
and Skins
in the left navigation.

q.

Verify that the themes and skins that are listed are the
ones that you migrated from the previous version to the current version.

r.

Verify that you are able to associate migrated themes and
skins to existing pages and portlets, and verify that they produce the required
view.

8.6

Verify migration of portlet applications

s.

Log in to the current WebSphere Portal Administrative
Interface.

t.

Click Portlet Management > Applications
on the left navigation.

u.

Verify that the portlet applications that are listed are the
ones that you migrated from the previous version.

v.

For each Web Module, verify that all your portlet
applications also display in the Portlet Applications
list.

w.

For each portlet application that is migrated and for which
you have set up parameters on the previous version, click Edit portlet
application
next to the portlet applications list and verify that the
parameters were migrated correctly.

You should also verify
the access control for migrated portlet application and portlets using the
Administrative Interface.

x.

Click Access
> Resource
Permissions
and select Portlet Applications
from Resource
Types
.

y.

Click Assign Access
to verify the access
control information.

z.

Click Access
> Resource
Permissions
and select Portlets
from Resource
Types
.

aa.

Click Assign Access
to verify the access
control information.

You can also perform a full export of the
current WebSphere Portal after migration is complete and verify the roles in
the exported XML file. Refer to The
XML configuration interface
for more information.

8.7

Verify migration of portlet configuration
data

bb.

Log in to the current WebSphere Portal Administrative
Interface.

cc.

Click Portlet Management
> Portlets
on the left navigation.

dd.

Verify that all portlet configuration data migrated from the
previous version are present in the current version by selecting the portlet
from the list and clicking Configure portlet
.

8.8

Verify migration of virtual resources

ee.

Log in to the current WebSphere Portal Administrative
Interface.

ff.

Click Access
> Resource
Permissions
on the left navigation.

gg.

Select Virtual Resources
from Resource
Types
.

hh.

Verify that all virtual resources migrated from the previous
version are present in the current version.

8.9

Verify migration of pages

If only the Welcome and Getting Started pages
display, see Problem:
After migration, only the Welcome and Getting Started pages are available
for information; otherwise, migration of pages was successful.





附件：



Technical
contents of ISO 639:1988 (E/F)

"Code
for the representation of names of languages".



Typed
by Keld.Simonsen@dkuug.dk 1990-11-30

<ftp://dkuug.dk/i18n/ISO_639>

Minor
corrections, 1992-09-08 by Keld Simonsen

Sundanese
corrected, 1992-11-11 by Keld Simonsen

Telugu
corrected, 1995-08-24 by Keld Simonsen

Hebrew,
Indonesian, Yiddish corrected 1995-10-10 by Michael Everson

Inuktitut,
Uighur, Zhuang added 1995-10-10 by Michael Everson

Sinhalese
corrected, 1995-10-10 by Michael Everson

Faeroese
corrected to Faroese, 1995-11-18 by Keld Simonsen

Sangro
corrected to Sangho, 1996-07-28 by Keld Simonsen



Two-letter
lower-case symbols are used.

The
Registration Authority for ISO 639 is Infoterm, Osterreichisches

Normungsinstitut
(ON), Postfach 130, A-1021 Vienna, Austria.



aa Afar

ab
Abkhazian

af
Afrikaans

am
Amharic

ar
Arabic

as
Assamese

ay
Aymara

az
Azerbaijani



ba
Bashkir

be
Byelorussian

bg
Bulgarian

bh
Bihari

bi
Bislama

bn
Bengali; Bangla

bo
Tibetan

br
Breton



ca
Catalan

co
Corsican

cs
Czech

cy
Welsh



da
Danish

de
German

dz
Bhutani



el
Greek

en
English

eo
Esperanto

es
Spanish

et
Estonian

eu
Basque



fa
Persian

fi
Finnish

fj Fiji

fo
Faroese

fr
French

fy
Frisian



ga
Irish

gd
Scots Gaelic

gl
Galician

gn
Guarani

gu
Gujarati



ha
Hausa

he
Hebrew (formerly iw)

hi
Hindi

hr
Croatian

hu
Hungarian

hy
Armenian



ia Interlingua

id
Indonesian (formerly in)

ie
Interlingue

ik
Inupiak

is
Icelandic

it
Italian

iu
Inuktitut



ja
Japanese

jw
Javanese



ka
Georgian

kk
Kazakh

kl
Greenlandic

km
Cambodian

kn
Kannada

ko
Korean

ks
Kashmiri

ku
Kurdish

ky
Kirghiz



la
Latin

ln
Lingala

lo
Laothian

lt
Lithuanian

lv
Latvian, Lettish



mg
Malagasy

mi
Maori

mk
Macedonian

ml
Malayalam

mn
Mongolian

mo
Moldavian

mr
Marathi

ms
Malay

mt
Maltese

my
Burmese



na
Nauru

ne
Nepali

nl
Dutch

no
Norwegian



oc
Occitan

om
(Afan) Oromo

or
Oriya



pa
Punjabi

pl
Polish

ps
Pashto, Pushto

pt
Portuguese



qu
Quechua



rm
Rhaeto-Romance

rn
Kirundi

ro
Romanian

ru
Russian

rw
Kinyarwanda



sa
Sanskrit

sd
Sindhi

sg
Sangho

sh
Serbo-Croatian

si
Sinhalese

sk
Slovak

sl
Slovenian

sm
Samoan

sn
Shona

so
Somali

sq
Albanian

sr
Serbian

ss
Siswati

st
Sesotho

su
Sundanese

sv
Swedish

sw
Swahili



ta
Tamil

te
Telugu

tg
Tajik

th Thai

ti
Tigrinya

tk
Turkmen

tl
Tagalog

tn
Setswana

to
Tonga

tr
Turkish

ts
Tsonga

tt
Tatar

tw Twi



ug
Uighur

uk
Ukrainian

ur Urdu

uz
Uzbek



vi
Vietnamese

vo
Volapuk



wo
Wolof



xh
Xhosa



yi
Yiddish (formerly ji)

yo
Yoruba



za
Zhuang

zh
Chinese

zu Zulu