In this part of our multi-part series about PointFire, we'll cover localization techniques and dive into some of the additional benefits these techniques offer. For Part I click here.
PointFire offers 4 major localization techniques in addition to what SharePoint's MUI (Multilingual User Interface) already offers. As a bonus, PointFire also fixes some bugs within SharePoint's MUI. These 4 techniques cover user interface, UI customization, and, most importantly, content.
The first localization technique is string replacement. It is handy because it is automatic, almost magical. As soon as PointFire is activated on a site, string replacement starts to work. Suppose you have a bilingual site where the original language is in English and the user's language is Dutch, PointFire automatically replaces all the English character strings that it recognizes on a page with their Dutch equivalents. PointFire comes pre-loaded with 170,000 character strings, which covers all out-of-the-box and a lot of custom text. If you customize your user interface, you can add your customizations and their translations to the custom translations list.
As an administrator you can scope access to those translations to ensure that the persons who create the customizations are the ones who manage their translations. A new translation can be site-specific, but can also be shared by many sites, typically an entire site collection. You can even override higher-level translations. Permissions determine who can create string translations. If you don't want site-specific translations, you can exclude or severely restrict that functionality.
The second technique is webpart filtering. You can tag webparts by language. A webpart tagged as Dutch will only appear on a page when the user's language is Dutch. Thus, UI translation can be done by the MUI and by the translations lists, while content translation is done by hiding and showing webparts according to the user's language. All of this is set up without modifying the webpart itself, so it can be used on any webpart. A single web page and a single URL will appear in one language or the other, according to the user's language.
The third technique is list/library filtering. When a list or library is made multilingual, it allows you to tag individual items or documents by language. Then when a user sees the list or library, the items or documents that they see will be the ones in their language. It is also possible to tag something as having all languages, for things that should appear for all users, or to turn off filtering temporarily for some users. This is done deep within the SQL database for efficiency and compatibility, and doesn't require any special views. Different language versions of documents and items are all stored in the same library or list, which means your business rules are automatically applied for all languages and only have to be specified once. Want language-specific business rules? That can be done as well, since PointFire's language tagging is available for you to use in business rules.
The fourth technique is URL sharing, which allows you to have different pages for users of different language. When you switch language on a page, you want PointFire to automatically go to the page that has the same content in the other language, of course, and PointFire does that but PointFire goes much further. If a user follows a link to a page in the "wrong" language, but for which another version of the page exists in the user's language, that other page can be shown instead. So for instance the URL of the root of a wiki, which is a particular page, can point to one page for users whose language is English and to another for those whose language is Dutch. This makes navigation and linking so much easier. A single link can be used for everyone, for instance in a navigation menu or an e-mail, and the same URL will result in a page in the correct language, even if they are in fact two different pages.
In practice, you should only use a limited number of techniques for maintainability so that authors on the site don't have to figure out for themselves which technique is appropriate. If your translations list gets large, you are probably overusing that technique, which is best used on interface elements. If you use a lot of parallel webparts, you may want to consider the limitations in versioning and publishing of webpart contents, compared to pages. Choose the techniques that suit your plan, and train authors to use them effectively.
There are actually more than four techniques, but those are the principal ones that don't require access to the SDK or file system. In part 3, we will deal with those more advanced techniques.