In this post, i’d like to mention a recent issue i ran into in a client environment in terms of Localization of SharePoint. I’ll give a real life example why they needed localization and what I had to do to support it.
Once you browse the web there are many articles out there talking about what localization is and why you need it. I won’t talk about those here. Rather, i’ll try to explain when a company can face the question ‘When do I have to support localization in my SharePoint applications?‘.
Actually answer is pretty easy! The day you start deploying your SharePoint applications for geographical locations speaking a language other than English, you should start thinking of ‘localizing‘ your applications. Although you deploy your applications in English, sooner or later you’ll get the requests for your application to support different languages.
Fine. Solution is easy right. Ask infrastructure folks to install necessary language pack on servers and start creating sites in that language, that’s it!
Is it really so??? Not really..
Maybe more important than localizing your SharePoint application, is to code your SharePoint application language-proof. This is the first thing you need to focus on. Once this is properly done, you can start localizing your application for different languages.
But, what do I mean by saying ‘Code your SharePoint application language-proof‘? This is exactly where our Real Life Example kicks in..
Before I go head and show the specifics of the example, here is a good practice.
Search your source code for constant strings in English.
This is a good starting point. Now, let’s be careful here. I’m not saying your code should not have any constant strings at all. Based on your logic you might need them.
However, having some constants in code in English, usually gives you a hint on if that constant might be needed or not if you’d deploy your code in an environment other than English.
Here is an example of that. Following you can see a code snippet where content type names are initially defined in English.
Presumably this means that those constant strings will be used later in that class to refer to OOTB and some custom content types.
Now let’s assume your code needs to remove ootb document content type and add a custom content type to all document libraries.
Somewhere in the code you notice a line like that, which is trying to check if the list you are working on has ootb content type or not.
Obviously, above code won’t work on any SharePoint sites other than English.
Once again I want to emphasize here. We are not applying localization to our SharePoint application yet. We are just trying to make sure that our code can successfully execute on environments deployed other than English.
I found the issue. What do I do now?
If you know that you’ll be using a SharePoint related constant, it’s a best practice to get localized version of that constant from resource files shown as below.
Now, your code can execute without any errors or side effects.
Hope this example helps you to see how easy to determine a localization issue in your code and actually how easy to fix it before errors or any side effects are encountered.