gettext-parser

Parse and compile gettext po and mo files with node.js, nothing more, nothing less.

The module should already work as expected but I'm currently short on tests (there is none) and docs (there's only this short README but no code comments etc.).

This module is slightly based on my other gettext related module node-gettext. The plan is to move all parsing and compiling logic from node-gettext to here and leave only translation related functions (domains, plural handling, lookups etc.).

If you get a bunchload of warnings or (non fatal) errors when installing, it is ok. These are most probably generated by the optional iconv dependency.

Usage

Include the library:

var gettextParser = require("gettext-parser");

Available methods:

• gettextParser.po.parse(buf) where buf is a po file as a Buffer or an unicode string. Returns gettext-parser specific translation object (see below)
• gettextParser.po.compile(obj) where obj is a translation object, returns a po file as a Buffer
• gettextParser.mo.parse(buf) where buf is a mo file as a Buffer (mo is binary format, so do not use strings). Returns translation object
• gettextParser.mo.compile(obj) where obj is a translation object, returns a mo file as a Buffer

NB if you are compiling a previously parsed translation object, you can override the output charset with the charset property (applies both for compiling mo and po files).

var obj = gettextParser.po.parse(inputBuf);
obj.charset = "windows-1257";
outputBuf = gettextParser.po.compile(obj);

Headers for the output are modified to match the updated charset.

Data structure of parsed mo/po files

Character set

The data is always in unicode but the original charset of the file can be found from the charset property.

Headers

Headers can be found from the headers object, all keys are lowercase and the value for a key is a string.

Translations

Translations can be found from the translations object which in turn holds context objects for msgctx. Default context can be found from translations[""].

Context objects include all the translations, where msgid value is the key. The value is an object with the following possible properties:

• msgctx context for this translation, if not present the default context applies
• msgid string to be translated
• msgid_plural the plural form of the original string (might not be present)
• msgstr an array of translations
• comments an object with the following properties: translator, reference, extracted, flag, previous.

Example

{
    "charset": "iso-8859-1",

    "headers": {
        "content-type": "text/plain; charset=iso-8859-1",
        "plural-forms": "nplurals=2; plural=(n!=1);"
    },

    "translations":{
        "": {
            "": {
                "msgid": "",
                "msgstr": ["Content-Type: text/plain; charset=iso-8859-1\n..."]
            }
        },

        "another context":{
            "example":{
                "msgctx": "another context",
                "msgid": "%s example",
                "msgid_plural": "%s examples", 
                "msgstr": ["% näide", "%s näidet"],
                "comments": {
                    "translator": "This is regular comment",
                    "reference": "/path/to/file:123"
                }
            }
        }
    }
}

Notice that the structure has both a headers object and a "" translation with the header string. When compiling the structure to a mo or a po file, the headers object is used to define the header. Header string in the "" translation is just for reference (includes the original unmodified data) but will not be used when compiling. So if you need to add or alter header values, use only the headers object.

License

MIT