Greece and Microsoft – Language and SharePoint

Boat Picture

“Outside Athens, Greece is still, Greece.”

Well I got you with the title; it’s not what you think. I’ve just had a wonderful holiday in Greece, sailing round the Islands and thinking about SharePoint. In my thoughts I wasn’t quite at the stage of firebombing Microsoft  but I can appreciate that certain customers, perplexed by some of the ‘features’ of SharePoint, may be driven to such desperate acts.

Before I went away, I was battling with SharePoint experts, trying to find solutions to a number of problems, including language.

All I want is enterprise language support, nothing too clever, just a few minor things:

  • True multi-lingual support for the content (I only want to use 25 or so languages at the moment but will increase)
  • A real language concept, which recognises that a base language principle works on a site but not for an enterprise. There’s no way an organisation can deliver on a base language promise in the real world. Especially if that organisation has no base language (welcome to Switzerland)
  • The ability to change attributes and elements on variations easily. Variations are a good idea in principle but it’s the same principle that says the human cannonball is a valuable mass transit solution.  If you try it in the real world you are going to hit a wall one day, the result will be nasty.
  • The ability to detect language at link-to not just on the landing page (and process the relevant fall back rules).
  • Oh and not to create a million pages of dross (ROT) just by having other languages used from time to time.

Sure you can program your way round them, build custom interfaces that break the next time a major patch comes out. However, even in SP2010 the language handling is still ‘My-First- Collaboration-Platform’ and not a true enterprise tool.

I guess this post has been a bit of a whine; I like to bring solutions not problems.

The solution appears to be to step outside SharePoint to do the things we want it to do. That’s not ideal. SharePoint does some things really well and if an organisation is SharePoint-centric then you often don’t have the choice of using different tools to solve the problem, nor do you want to custom develop a tool up to or beyond the bleeding edge.

My key messages are therefore:

  • If you want to use SharePoint at an enterprise level (and you haven’t bought it yet), think about your language requirements at the time you consider your architecture.
  • If you need multi-base-language support then, if you can subdivide into sites you may be fine. If you can’t (perhaps because your strategy drives you to harmony and integration) then be prepared to develop or use a thin layer above SharePoint in your architecture.
  • SharePoint is getting better, from the disastrous language support in 2007, it’s moved forward in leaps and bounds. Unfortunately it’s leapt over some of the fundamentals that would make it a truly usable solution. In some cases it’s as though gravy were spilled over the napkin of inspiration, a huge hole exists in a really damn fine idea. So please don’t fire-bomb Microsoft anymore, at least until they’ve had a chance to get this right in the next release… if they don’t then I suggest a small thermonuclear device may be a more appropriate response.