Team Foundation Internationalization (Part 1)
In this blog, you will most often find posts on topics related to a particular technology, runtime or platform, but today and in some future related posts, I’d like to talk about the world-readiness aspects of one of our products – Team Foundation Server.
In the past 6 years (time flies when you are having fun!), I’ve had the privilege to closely work with the teams that built this fantastic (IMHO, but I may be biased 
) product, and it was not hard to convince them that such an Enterprise-level product would need to be World-Ready. In fact, as Brian Harry says, TFS is more than just a product - it is an Open Platform. This makes it even more compelling for it to be well globalized, although it’s not easy given that TFS itself can be a highly distributed application and relies on (and integrates with) a number of external components, like MS SQL Server, MS Sharepoint, MS Office, MS Project and others.
So what are the main areas we had to deal with to make it a world-ready product? As expected, we were not immune to any type of globalization issue, regardless if it was related to Data Presentation or Language Enablement, but Locale sensitiveness, Time zone management, Sorting/Collation, Encodings and handling the Language of the User Interface come to mind as the top issues.
I am planning to describe how these issues affected TFS over the course of the next posts and how we approached/fixed them and I’d start with the UI Language issue, mostly because it’s very visible.
The “Server UI Language”
Because of performance considerations, TFS was originally designed to be mono-lingual as for User Interface (UI), meaning that one could have the Process Template (which defines the UI of the Work Item Types), the Project Guidance and some other artifacts only in a single language – let’s call it the “Server UI language”.
Extra care and countless hours of testing were spent to make sure that customers could type data in any human language into TFS (all text-related columns in its DBs are Unicode) and that there would be a decent level of confidence when installing components in different languages (e.g. installing an English TFS atop a Japanese version of Windows and/or SQL). And, also, that the language of the UI on the Team Foundation Client (TFC) would not be an obstacle when connecting to a (TF) Server with a different UI language.
Still, if anyone tried to connect to e.g. a Simplified Chinese TFS from an English TFC they would see something like this.
The Team Explorer (notice the folder and query names)
If you then right-clicked on the Work Items node and wanted to create a new Work Item, you would get
And if you created a New Bug WI, you would see this
The language mix you see is mostly due to the fact that the Process Template that was used to create the Team Project was a Simplified Chinese one, while the client (VS/TFC) is in English. That is actually a good way to tell which strings are stored on the server-side vs. those that are on the client, if you are curious about it.
The Process Templates contain Work Item Types’ definitions, some Word/Excel document templates/samples, Build Templates, Web Reports, Classification/Groups/Permissions’ info, etc. so you should expect those items to show up in the “Server UI Language” regardless of what the UI Language of the client is.
“So what’s the big issue?”
1. Well, for one, if you work in a multilingual team or if you have a customer or a vendor with whom you need to work on the same Team Project and not everyone speaks the same language, someone may not be able to correctly interact with the system.
2. Secondly, if you are building an extension to TFS or a custom tool, you may want to consider the fact that e.g. a “Task” Work Item may not exist on the server as it may actually be called “任务” (as you have seen above, but the same would be true even if it had been renamed to “Assignment”).
“Any solution?”
1. In the first scenario, most likely you would need to have a common language to communicate with the other teams anyway, so the same common language could be used as “the” language of your TFS/Project.
The bad news is that once you have selected the language of TFS (or I should say of a Team Project), that’s it – you cannot change it. Back in 2006 we created a TFS Language Change tool to change the language of an instance of TFS 2005 altogether, but it was a pain for customers to use (a lot of manual steps), the transformation didn’t apply to all items anyway and overall it was quite error prone. So, we ran a survey in 2008 and figured that very few customers would use it and that it was not worth the effort – so we did not release a new version of that.
A possible workaround, could be to customize your Work Items so that you would display, for each Field, a label in 2 languages. If you were working on a new Team Project, you could consider doing that also for Field Values, but I would not recommend changing those if you were working on an existing Team Project, as it would be harder to retrieve older data. And if you customize Values, you may need to change a few of the default queries and reports.
We could also consider updating the abovementioned “TFS Language Change” tool, but only if highly needed, so please feel free to leave your scenario/comment/request below.
2. In the second scenario, if you are extending/customizing TFS, you should use RefName attribute when referring to Fields (e.g. “System.Id”) and, new in TFS 2010, you can now use the WIT Categories (see a generic description here and some more detail here) to create e.g. a new Bug without actually using its name, but by using the RefName attribute of the “Bug Category” (e.g. “Microsoft.BugCategory”). Instead, there is still no good solution to set values in a language independent way, other than having a sort of “translation dictionary”
More on UI language of TFS in future posts (as I'm sure I have left something behind), but please feel free to let me know about any issues you are facing today, your very own workarounds, your needs and/or your level of interest in the details
Thanks! Aldo