Gap 2: You Need to Support Multiple Languages in SharePoint
Portal Server
Windows SharePoint Services 2.0 improved the product's support of localized
languages to match the languages that Office supports. By installing Windows
SharePoint Services 2.0 language template packs (collectively referred to as
the Windows SharePoint Services 2.0 Language Template Pack) and configuring
regional settings, you can host multiple language sites on a Windows Share-Point
Services virtual server or in a server farm.
After installing the Language Template Pack and during site creation, you add
Windows SharePoint Services sites in the supported languages. The only additional
step necessary during site creation is to select the chosen language from a
Language drop-down box at the bottom of the New Share-Point Site page. (Figure
2 shows a resulting site in French; Figure
3 shows the same site in Spanish.) You can also create localized sites by
using stsadm.exe and the create-site operation, specifying the appropriate language
pack by using the -lcid switch and the appropriate locale ID (LCID).
The Language Template Pack adds translated Windows SharePoint Services site
templates to the file system for every applied pack. Windows SharePoint Services
translates all supported pages and common site elements, including the navigation
bar, top link bar, and quick-launch bars. Out-of-the-box Web Parts (including
the inline content) are also translated, but all custom Web Parts require separate,
manual localization. To see the LCIDs of the installed language packs, look
under %programfiles%\ common files\microsoft shared\web server extensions\60\template
on the server or servers that host Windows SharePoint Services. Each pack resides
in the applicable LCID in that directory. Installed language packs also appear
in the server's Control Panel Add/ Remove Programs applet.
SharePoint Portal Server doesn't provide the same flexibility in language support
as Windows SharePoint Services does. Although SharePoint Portal Server and Windows
SharePoint Services support the same languages, SharePoint Portal Server support
is restricted to one language per portal instance. The language you select when
creating a portal is the only language that any portal instance will support
and is also the default language for all Windows SharePoint Services sites in
that portal, even though you can host sites in multiple languages within a single
Windows SharePoint Services site collection.
Solve it. If you need multilanguage support at the portal level,
the most practical solution is to install multiple instances of SharePoint Portal
Server. If you need multilanguage support in Windows SharePoint Services as
well, you can create one Windows SharePoint Services virtual server that has
multilanguage packs installed.
Even though this solution is the best one available now, be aware that installing
multiple instances of SharePoint Portal Server increases the burden of administration.
You must maintain multiple languages across each Share-Point Portal Server installation
and must separately maintain the configuration of each portal server instance.
Additionally, there's no easy way to support multiple languages on a single
instance of a Windows SharePoint Services site. Trying to resolve these gaps
through mirroring content on side-by-side portal instances or multiple sites
(each instance or site being configured with a different language) is an additional
maintenance burden. But the reality is that supporting multiple languages on
any Web platform (Microsoft or otherwise) is an enormous maintenance
effort. Each piece of content written in one language must be translated into
any other language you plan to support. Automatic language translation technologies
are available, but the results are poor. The burden of supporting a multilanguage
Web platform can outweigh the maintenance burden of the solution we present
here.
Gap 3: You Need to Search Across Windows SharePoint Services Sites
If you've installed Microsoft SQL Server with the Full-Text Search component
and have configured Windows SharePoint Services to use SQL Full-Text Search,
you can take advantage of Windows SharePoint Services' site-search facility.
(See the sidebar "Set Up Site Search," page 42, for details of this setup.)
Even with the SQL Server Full-Text Search component installed and integrated with Windows SharePoint Services, you can't search beyond the boundaries of the Windows SharePoint Services site from which you run a search. You can't include in the query parent or child sites in the site collection or across site collections, or content from other sources outside of Windows SharePoint Services (e.g., the file system, Internet sites). Furthermore, you can use only simple search phrases, no advanced search capability exists, and you can't search attachments to list items.
Solve it. The simplest solution is to install SharePoint Portal Server as the portal layer front end, linking it to your Windows Share-Point Services virtual server and its site collections. Then, from the portal's Site Settings—Configure Search and Indexing page, you can approve or reject sites for content indexing. The SharePoint Portal Server Search (SharePointPSSearch) service will crawl and index approved sites. After indexing is complete, a search from the portal returns results from the portal and all approved Windows SharePoint Services sites.
If you've enabled Advanced Search Administration Mode through SharePoint Portal
Server Central Administration, you can further extend this site-directory search
capability by creating a site-directory content source. You can add instructions
to crawl non-portal content such as file shares, Microsoft Exchange Server public
folders, and other Internet sites.
Programming solutions for extending Search also exist. If you host your Windows
SharePoint Services sites in SharePoint Portal Server, you can replace the Windows
SharePoint Services search Web control with a portal search?capable Web control
to search the local site (or all sites in a site-collection hierarchy) from
a Windows SharePoint Services site. Third-party solutions, such as CorasWorks
Workplace Suite, include Web Parts that perform searches within a site collection
or across site collections.
Mind the Gap
There are no perfect software products. Every sophisticated application has some sort of shortcoming, especially when the user base is large and diverse. Identifying gaps and proposing solutions is an essential part of assessing a product or making it work to meet specific needs. If you've identified other SharePoint gaps, tell us about them; we'll try to explore them in future articles.
Ethan Wilansky
(ewilansky@windowsitpro.com) is a contributing editor for Windows IT Pro and a chief technologist for EDS in its Technology Strategy and Architecture practice. He has authored or coauthored more than a dozen books for Microsoft.
Jeff Sandler
(jsandl01@gmail.com) is a lead technologist at EDS in its Technology Strategy and Architecture practice. He has been with EDS for 15 years as an architect and developer with experience on a wide range of technology platforms.