I played around yesterday and didn't get anywhere with the current Gettext approach (which uses Mono.Posix) on Win7 64 bit.
The reason why this approach can't work, I believe, is that Mono.Posix, although it is a .NET assembly compiled for 'Any' architecture, relies on two non-.NET Win32 DLL's (MonoPosixWrapper.dll and Intl.dll), which simply can't be loaded into a .NET application that starts up as a 64 bit application.
In the wiki page sourceforge.net/apps/mediawiki/o ... rison_I18N Timo noted down that another approach with gettext exists, 'GNU Gettext for C#', which is independent of mono.
I had a look at that approach and it only involves a .NET DLL with no dependencies on anything else, and the .NET assembly is compiled for 'Any' architecture. I followed the short tutorial on mono-project.com/I18nGettext and got an 'Any' architecture application that works on Windows XP 32 Bit and Win7 64 Bit alike!!!
Note: Mono recommends their approach with Mono.Posix, but don't give a particular reason for it. That is not helpful in my eyes, and wonder if they recommend their approach only because it is integrated into mono.
'GNU Gettext for C#' seems to be very powerful, according to the website gnu.org/software/hello/manua ... _0023.html. It uses the same input, .PO files, than the approach that mono takes, but generates DLLs that contain classes with resource texts (not .resources!) rather than .mo files. The generated DLL files simply go into a sub-folder under the 'bin' folder that is named after the language, eg. 'bin\es' for Spanish, so there is one DLL for each language in a separate folder (there is no locale\xx\LC_MESSAGES\ folder as with the current approach). For use in the C# file, instead of 'using Mono.Posix;' a 'using GNU.Gettext;' is necessary and a global variable of Type 'GettextResourceManager' is needed instead of the static 'Catalog' object, which is used by the mono approach. Other than that, I think there is no difference. See the end of the 'GNU Gettext for C#' webpage for handy shortcuts that make it even easier to use!
Changing openPETRA to the non-mono Gettext approach would have at least three advantages:
- We don't need to ship Win32 Bit DLL's with an otherwise pure .NET, architecture agnostic product.
- We don't need to ship mono libraries with the WinForms client and PetraServer (when they PetraServer are installed on Windows).
- We don't need to compile openPETRA to 32 bit architecture, and it doesn't need to run on the WoW (Windows-on-Windows) emulation on 64 Bit windows systems. (I don't know what mono on other 64 bit OS's will do with a 32 bit compiled .NET assembly…)
I therefore propose to change openPETRA to use the non-mono Gettext approach at some point.
