Plan multiple languages carefully for Office 2007
Our ORK article, Deploy multiple language versions of the 2007 Office system, states that it is important to plan languages at the beginning of your deployment. In the words of one of the support engineers here at Microsoft, it is “really, really important—yes, we really mean it!” I didn't phrase it that way in the article, because I'm sure our editor would have protested, so I put it here instead—sorry, Chuck!
Here are a couple of case studies to illustrate what can happen:
Case Study #1
Description: A company deploys a core installation of the English version of Office Professional Plus 2007, with Access, InfoPath, and Publisher set to Not Available. The company deploys additional language packs by region. The network installation point is not unified globally. Later on, the company wants to deploy Access and InfoPath to a group of users. They create a customization patch (MSP file) and roll it out globally; test automation did not indicate any failures.
Result: Access and InfoPath behave as expected—but only for the English version. While the other languages were installed, the required features for Access and InfoPath are still set to Not Available. Users experience issues ranging from a mixed-language user interface to inoperable applications.
Solution: There are two possible ways around this problem. One solution is to use a combined network installation point for the customization patches to ensure that they cover all possible languages. The second solution is to use a config.xml file instead of a customization patch.
Case Study #2
Description: A company creates a network installation point for Office Professional Plus 2007, with English, Japanese, and German. The default installation does not include Access. Their config.xml file contains the following lines to include English plus the local language:
<AddLanguage Id="en-us" ShellTransform="Yes" />
<AddLanguage Id="match" />
Later on, the company deploys Access to eligible users with a customization patch. Because this patch was created from the combined network installation point, everything works as expected.
Because of new needs, the company then adds French to the network installation point. The custom config.xml files are not changed.
Result: Users with the original core installation report no problems. Users who are trying to use the French version of Access report that the user interface is not in French, or the application fails to start. Admins are having a tough time diagnosing the problem.
Solution: Create a new customization patch to add Access from scratch with the updated network installation point.
Lessons Learned
If you change users' configurations after the initial deployment and include additional languages as part of your customizations, you must first copy all the Single Language Packs (SLPs) you want to deploy to the network installation point that contains the Office product files; for example, \servershareOffice12. A static list of the products contained in the installation source is built only during the initial creation of a customization patch. If you later add additional languages to the installation source, the existing patch is not updated to reflect this change. Therefore, you must also re-create the customization MSP file that you want to deploy to users after you update the installation source with additional languages. Failure to do this might result in unexpected behavior, because the changes to the customization MSP file will not apply to the added languages. If you do not re-create the MSP file, it is possible that your deployment will test properly in your lab, but users might not see the new language in their Office applications, or they might see only a subset of the language features. For more information, see Change users' configurations after installing the 2007 Office system.
- Andrea Weiss