Get Past the Gaps in SharePoint

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.

End of Article

   Previous  1  [2]  Next