I was recently working with a customer with some localization behavior in SharePoint. What I didn’t realize at the time was the way that GetLocalizedString() works. The fallback behavior of .NET looks first for the specific language-locale (en-US, de-DE, etc.) from the UICulture. If that isn’t found it tries to locate a language neutral culture (en, de, etc. ). Should that probing fail a default or ultimate fallback is returned. For more information related to the fallback process in .NET look here.
GetLocalizedString() looks only for the specific language code matching the lcid you pass into the method. If it isn’t found it defaults to the default language for the site found using SPWeb.Language. After some thought this seems to make sense because the language packs issued with SharePoint are language code (locale) specific, so the product wouldn’t need a fallback type of scenario.
For those ISVs that still want to support the fallback behavior in your application the GetGlobal(Local)ResourceObject can be used from the HttpContext object to locate a resource and find the particular value. This method supports the .NET localization fallback behavior and will give you a consistent experience across your applications.