I have just realized that Mono supports a reduced set of locales compared to Unix systems.
Mono uses a set of hardcoded locales in the runtime to provide the .Net framework locale support. Mono reads the user's locale and sets the default framework locale to the corresponding internal Mono locale. The problem is that the locales supported officially by .Net and by the Mono runtime and are smaller set compared to the ones that Unix systems support (actually Mono supports less locales that Microsoft .Net runtime).
For example, languages like Occitan, Bosnian or Breton have no locale in Mono. Neither combinations of supported languages in other regions, for example Catalan language in Andorra (ca_AD), that is actually the official language there. The list of non-supported locales is long compared to any standard Unix system.
In Unix machines, Mono applications run under these not supported locales are not respectfully with the user's locale. I noticed this because some users were complaining that gbrainy did not show the numbers properly formatted for their locales. The issue affects actually all Mono applications.
For example, if you run Banshee, F-Spot or Tomboy under a non supported locale they always show the dates and numbers formated for the invariant locale instead of using the user locale. As example, Occitan (French) and Catalan (Andorra) locales use European date formatting but you get the American date formatting. Same for number formatting. This really breaks the locale support at application level for many users.
I have filled up bug report (#420468) in the Mono's project bug tracking system. Meanwhile, I have put together a patch for gbrainy that reads the user's locale information and sets it in the default locale when user's locale has not been identified by Mono. As result, the number formatting is now shown properly. If you can think of a more elegant fix, please let me know.