So we have seen in my previous post what server language packs do for Project Web Access, so now what happens on the client? The language packs and language settings work for all of Office, but I will be concentrating on Project. To change the settings once a language pack has been added you go to Microsoft Office Language Settings 2007, which is under the Microsoft Office, Microsoft Office Tools start menu. If you have not added any client language packs then you will see just two tabs - the right hand two in this first screen shot. Once you have another language available then you will also see the Display Options tab.
In this example I have a US English initial installation and have added Korean, Japanese and French language packs. So I can choose my display language and help language to be any from the set. It is possible to have some languages appear in the list that have not been loaded for all products - hence the option for preferences. SO if I have French as my preference but have only loaded it for Project then I will see the next available language when I use Excel or any other Office product.
So if I select Office menus as French and Help as Japanese I see the following when opening Project and viewing Help. The dual language can be helpful when a corporation has a common language they wish to work in - but individuals may find help in their native language to be more useful.
To show the full support for extended characters I can open a project saved from a Greek language version of Project, which also has some Japanese and Korean characters in the task names. The date format follows your Windows settings - so if you want a format such as Day/Month/Year you will need to set this as well as the language for Office.
So for both client and server the language support for Project goes beyond what was offered for 2003 - no more issues with codepages!
Technorati Tags: Project Server 2007
I've had a few comments on the configuration of Forms Authentication using LDAP and thought it worth raising some of these points in a new posting.
1. LDAP forms authentication is only supported by Office Servers and not WSS
The architecture for forms authentication is based on WSS 3.0 but the specific implementation described in mine (and others) posting for use of Active Directory Application Mode (ADAM) and LDAP authentication is based on the Microsoft.Office.Server.Security.LDAPMembershipProvider and so is a component that shipped with Office Servers (Microsoft Office SharePoint Server, Microsoft Office Project Server, Microsoft Office Forms Server...). So if you just have WSS 3.0 then you will not find this component. One possible option might be to use the ASPNET Active Directory Provider and configure this for the LDAP port ADAM is running on (see http://blogs.msdn.com/harsh/archive/2007/01/10/forms-based-authentication-in-moss.aspx for some guidance) . Or you could write your own authentication provider for LDAP... On-demand webcast here - http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032346257&CountryCode=US
2. New ADAM users are disabled by default
If you are using ADAM hopefully you have already discovered that by default any new user is disabled. To enable you need to set the msDS-UserAccountDisabled attribute of the user to false.
3. Need to give ANONYMOUS LOGON read access to directory
I haven't needed to do this and certainly would not recommend it in a production environment. I am guessing it relates to the account used for some application pool is set such that it appears to the directory as ANONYMOUS. Much better to have an explicit user and give an explicit permission.
With this posting I am trying out some of the features of Windows Live Writer that I haven't used yet - so we have pictures!
You can install language packs on Microsoft Office Project Server 2007 which will allow users to view the PWA pages, and also create Project Workspaces in selected languages. This is similar to the Multi-Lingual User Interface in Project Server 2003 but because we are now using Unicode there are not the limitations with different code pages that we faced in the previous version. As an example I have the following PWA site provisioned in English. An you can see in the list of workspaces I have a workspace with a name in Japanese (in fact the Japanese word for "Japanese").
A Japanese user could modify their IE settings (Internet Options, then the Languages button on the front page) to make Japanese the preferred language.
Refreshing the page above would then give the following page, with the majority of the text in Japanese. Certain elements stay in the language it was provisioned in - such as the tab title of Home, the web part names and the links to Shared Documents. Also in this example I have a modified link to Timesheets which reads Timecard - so does not have a translation.
Once a language pack has been installed then a new PWA instance can be provisioned in the language of that pack - and the choice of languages is made on the Create PWA page.
Likewise you can select the language for any Project Workspaces by updating the language on the Project Server Workspace Provisioning page. The following is set for Arabic, but viewed in French.
Once a Project Workspace is provisioned it is only available in the language it is provisioned in - so for example the following is the Japanese workspace seen in the list on the first image.
So as a final taster of the support for right to left languages here is a PWA site provisioned and viewed with the IE setting for Hebrew.
For part 2 of this series I will take a look at the client language packs for Microsoft Office Project Professional 2007.
The download page for language packs at http://www.microsoft.com/downloads/details.aspx?FamilyID=2447426b-8689-4768-bff0-cbb511599a45&DisplayLang=en allows you to load language packs for many languages on top of your native installed language. For SharePoint this allows you to create sites in different languages. In Project these language packs do what the Multi-Language User Interface (MUI) did for 2003 and before - so two users can see the same PWA site in different languages, based on their IE language preference.
The download page however does not distinguish which languages will and will not work for Project Server 2007 - as only a sub-set of the Office ones are supported. The download page also just has a link for the SharePoint deployment page and not the Project Server one which can be found at http://technet2.microsoft.com/Office/en-us/library/7ac79302-38b1-4187-bbd5-ef9f53c6f9031033.mspx?mfr=true. The main difference is that for Project you need to install the language pack on your application servers as well as the web front ends. Load and run the configuration wizard on each server in your farm.
The languages supported by Project Server 2007 are listed on the page linked to above - but more importantly the ones SharePoint supports but Project Server 2007 DOES NOT support are:-
Bulgarian, Catalan, Croatian, Estonian, Hindi, Latvian, Lithuanian, Portuguese – Portugal, (Portuguese – Brazil is supported), Romanian, Serbian, Slovak, Slovenian, Thai, Ukrainian.
If you install these then the propagation of other MUI languages may be affected and you may not be able to see languages you expect to, and you will get many errors in your application event log referring to a file - notifications.sql - which cannot be found for these languages.
I will do another post soon (vacation next week!) on the use of language packs both on the client and the server, but just as a taster 2007 handles this much better than 2003. This week I worked on a project on a Korean version of Project Professional 2007 (US English plus Korean language pack for the project client) and created tasks in English, Korean, Japanese and with various European accents, then saved to my US version of server which had many of the language packs installed. I then changed my client language to Greek, re-opened the project and could see everything I had saved. After publishing I could even view my PWA site in Danish and view my project along with the tasks in the different languages. What? Next you want us to translate the tasks? One day...
If you have the right database permissions it is perfectly possible to point Project Professional 2003 at a Project Server 2007 database using the save-as option and specifying an ODBC connection. Please do not do this! Reason 1 is that it will not work and will give an error message, but reason 2 is that it could come back and haunt you later. In failing it does try to make the database look like a 2003 version, and it adds some data, and even adds some columns to tables where it thinks they are missing (I said you need the right permissions so only someone with a high level of SQL Server access would get this far).
The time you find the failure is if you ever try to recover your system on another server (or even the same server after a re-build). These extra columns then cause a failure of the PWA provisioning process against the set of databases. During the creating databases stage it will fail with a "Failed - See the Event Log" error. In the event log will be Exception: Insert Error: Column name or number of supplied values does not match table definition. You will now have an MSP_TASKS table with 130 columns compared to the expected 128 - so when it tries to create a stored procedure that will later be used to copy data from MSP_TASKS to MSP_TASKS_SAVED the columns no longer match. The extra columns are:-
Other evidence of the issue is:-
Recovery is reasonably painless, the extra columns can be deleted, and then provisioning will work.