-
Notifications
You must be signed in to change notification settings - Fork 12
Why GetText
While there are other GNU/Gettext implementations for C#, each has its own scope, i.e.
Mono.Unix.Catalog Mono's Catalog is merely a binding to three native functions (bindtextdomain, gettext, and ngettext). It does not support multiple domains/locales and contexts. It is not cross-patform, and may be challenging to use under Windows OS.
GNU.Gettext Gettext uses satellite assemblies for translation files and does not support multiple locales in one application instance. It's hard to build and maintain translation files and change locale inside an application. A .NET based implementation can be found here, but there is no active development.
NGettext GetText.NET is originally forked from NGettext. NGettext uses an extensive folder structure to lookup translation files including LC_MESSAGES subfolder for each translation. Also NGettext does not support C# string interpolation.
GetText.NET
- GetText.NET is fully cross-platform, no need for other native or managed 3rd-party libraries
- GetText.NET supports multiple localization domains. Translation files can be separated for each of an application's module or plugin
- GetText.NET supports multiple locales in one application instance and has a really simple API to choose the locale of an application
- GetText.NET loads translations directly from *.mo files in standard .NET localization folder structure. Furthermore, translations can be loaded from other specified file or stream
- GetText.NET supports message contexts
- GetText.NET uses a nice and simple API, compatible with any type of application (console, GUI, web...)
- GetText.NET.WindowsForms (separate package) allows localization of Windows Forms standard properties
- GetText.NET supports string interpolation and FormattableString
- GetText.NET.Extractor is a .Net Core tool allows extraction of strings from C# source code (similar to xgettext), but includes support for interpolated strings.