Load translations from *.po files directly

[bugproof]

Related issue: https://github.com/neris/NGettext/issues/20

Many programs parse *.po files directly, what's the advantage of *.mo files over *.po files? There's an additional step in maintenance - compilation.

[VitaliiTsilnyk]

MO files designed to be easily readable at the runtime. They don't have any problems with encoding, they're easy and really quick to parse. PO files were designed to be editable by humans. Those are just plain text files, they can be stored in any encoding without any metadata, it's hart to detect it sometimes. The format is pretty complicated to parse and it would be definitely much slower than just reading binary MO file byte-by-byte.

I'm not saying it's impossible. It's pretty much possible, but it's not implemented at the moment since it's not an optimal way and it requires some effort to implement.

Contributions welcome :)

[bugproof]

@neris but if I'm not wrong translation file is loaded only once (e.g. on startup) and translations are then stored in memory during the application's lifetime (cached) so does it make a significant difference? (is this really a concern?) Performance of parsing MO file would only matter if that would be something that happens frequently.

As for encoding, I think StreamReader.CurrentEncoding works fine.

[ljani]

I'm interested in this functionality as well.

One solution could be to compile .po files to .mo files during build using a custom MSBuild task. Then compilation would not need manual steps and the runtime would have .mo files, which it expects.

For example in the JavaScript world, lingui does this nicely with their webpack loader:

It’s a good practice to use compiled message catalogs during development. However, running compile everytime messages are changed soon becomes tedious.

@lingui/loader is a webpack loader, which compiles messages on the fly:

[VitaliiTsilnyk]

You can create a custom MSBuild pre-build task that would call xgettext, msgfmt and so on, to extract strings and compile .mo files. It should be about two lines of code.

I want to implement a loader for .po files in NGettext, it's not that hard and it's nice to have, but I can say for sure that I will not have time for that in the nearest future. So contributions are very welcome.

[ljani]

You can create a custom MSBuild pre-build task that would call xgettext, msgfmt and so on, to extract strings and compile .mo files. It should be about two lines of code.

The thing is I don't want to have manual steps to install xgettext, etc to be able to compile the solution. All the required functionality should be downloaded as a project dependency. git clone && dotnet build should be enough in my opinion.

Sure you could download them, but eh, it gets complex. A proper task would be much cleaner and nicer.

I want to implement a loader for .po files in NGettext, it's not that hard and it's nice to have, but I can say for sure that I will not have time for that in the nearest future. So contributions are very welcome.

Interesting! Many thanks for everything you've already done with NGettext!

[c4tachan]

The thing is I don't want to have manual steps to install xgettext, etc to be able to compile the solution. All the required functionality should be downloaded as a project dependency. git clone && dotnet build should be enough in my opinion.

It is good practice to include your *.pot and .po files in your repository. *.mo files should not be included, and should be compiled at build time.

Thankfully, if you configure pre-build steps in your projects, those steps will be included in the repository. This means that git clone && dotnet build will automatically execute the pre-build steps. This stackoverflow question has some answers that will help you