Comparison

[gluck]

Hi,

There seem to be a lot of i18n gettext-inspired-c# libraries, though at first sight yours seems the cleanest (UTs, CI, interface-API, pure gettext).
Though some provide more features, e.g.:

• SecondLanguage provides PO as well
• Vernacular provides tools for extracting PO files from assemblies, gender support, and xaml bindings

Any thoughts around those other i18n libs and how ngettext fits ?

Thx

[netcharm]

if you using VisualStudio, visit https://github.com/netcharm/ngettextutils , it's a small, simple toolkit for NGettext, It's extracting text from from/xaml design file to PO file, and using xgettext extracting text from .cs source file.

[gluck]

Yet another one :)

Personally I'd prefer a purely managed approach/implementation, but I'll have a look anyway.

Thanks !

[netcharm]

you can modify/create new functions of the source for you like... :P

[c4tachan]

It's now 2021, and it looks like Vernacular and SecondLanguage haven't received any updates in quite a while.

Vernacular's last update was on Jun 17, 2016
SecondLanguage has a nuget package that was last updated on November 2, 2017

It's probably reasonable to declare both of these projects dead.

[c4tachan]

There seem to be a lot of i18n gettext-inspired-c# libraries, though at first sight yours seems the cleanest (UTs, CI, interface-API, pure gettext).
Any thoughts around those other i18n libs and how ngettext fits ?

If I can toss in my experience, I'd like to describe how NGettext fits into the ecosystem as being the most relied on and probably the most complete implementation of the Gettext standard available today (September 2021) for use in the .Net ecosystem. It is available as an easy to install nuget package as well as through the source code in this repository. The nuget package has been downloaded 468,371 times as of the time of writing this comment. The next most downloaded nuget package (that actually supports the use of po and mo files, rather than the generation of them) is SecondLanguage at 71,068 total downloads, less than a quarter of the downloads of NGettext. Unfortunately, SecondLanguage, which I mentioned in my previous comment, appears to have gone stale, since it's last update was in 2017.

As for features and functionality, NGettext provides (almost) identical l10n and i18n syntax in your .Net (framework/standard/core) source code to what is described for C/C++ and C# in the GNU gettext documentation.

This means that it is a relatively simple matter to use the GNU gettext tool chain to extract translations from your code and compile PO files into MO files.

Since NGettext already follows the rules described for C# in the gettext language documentation for C# (which is pretty cool if you ask me), all of the instructions provided in the gettext documentation for xgettext and the like apply directly to the source code you write using NGettext for localization. See these sections of the gettext documentation's index for links to the gettext utilities docs:

• GNU gettext utilities: Extracting Strings, Creating PO files, Updating PO files
• GNU gettext utilities: Manipulating PO Files
• GNU gettext utilities: Making MO files

This is a huge advantage to the NGettext project because it reduces the need to write massive amounts of specialized documentation regarding the usage of this library, and how to extract, manipulate, and compile your localized text.

The tools provided by GNU are useful if you want to add translation activities to your CI/CD pipelines.

Note that for xgettext you can use the same keywords list that @VitaliiTsilnyk describes in the NGettext README for use with POEdit. Please see the xgettext documentation for details on how to define a keywords list.

From what I can tell, this is where NGettext differs from the other options available today. Microsoft discusses po files here, where they describe using a library/nuget package named Orchard Core, however after reviewing the docs and details about Orchard Core, I feel that it is far inferior to NGettext, due to it's syntax being vastly different from the original GNU gettext specification. It is possible that I am missing some advantage of Orchard Core when it is used in the context of the *.cshtml pages you write while producing an ASP.Net application, but it seems to me that you should still be able to call functions using @MethodCall("string") where the method you are calling originates in the NGettext libraries.

Furthermore, while it's mostly a work in progress, I've been working on adding functionality to NGettext to give it almost the exact same _("string") syntax that is available via the C/C++ macro definitions.

If you're curious, I've created a Pull Request to bring my new syntactic sugar into the full NGettext repository that you can find here: #38

[jeancroy]

Orchard Core, I feel that it is far inferior to NGettext, due to it's syntax being vastly different from the original GNU gettext specification

What Orchad does well is implements IHtmlLocalizer and IStringLocalizer, so using GNU-GetText PO/MO files or Ressources Manager resx files become an implementation detail. It also manage "catalogs" for you, like which request uses which catalog. Reading them at application start and caching them.

But the actual implementation of GetText seems minimalist. And only PO file parsing.

Some IStringLocalizer wrapper + LocalizationManager from Orchad Core + GetText management from this library migth be the ideal setup in an asp.net situation.

[mwpowellhtx]

Comment, and questions in similar motivation around NGettext, actually.

• Seems like the decision to base the efforts around GNU-GetText inspired approach, including PO/MO files, is a solid one. I like the idea, do not need to reinvent that wheel. However, it is 2024 today, and the most recent update is some 3+ years ago that I can tell. It is because the project is mature today?
• Considering for a WPF project I am involved with at the moment, but does not seem like this is all that opinionated on the end goal, which is nice, with a bit of adaptation.
• I did see NGettext.Wpf, but this seems DOA, sadly, due to author no longer being among us. So leaves me wondering what I do next about that, and with what kind of support, for proper 1C bindings, annotations, etc.
• Given its basis on netstandard, do not need to worry about which targets, that's a nice thing, of course, as well.

Would be happy for the insights around any, some, or all of these concerns.

Cheers 🍻 and thanks!