Additional options

[smhg]

It seems like a good idea to have this discussion here as it can be useful to others.

@eldarc wrote:

I also wanted to ask you about some feature additions for xgettext-template. I would love to have the cleanup of strings that are not anymore in the source files. If I were to code this as a new parameter (for example --cleanup) would it have a chance to be merged?

I would love this feature because I'm using this with Gulp. I have it setup for live watching. Every time there is a change in the template files, gulp will automatically call xgettext-template and extract strings. It would be great for the developer not to worry about temporary strings in the .po files. When the extraction is done, a new gulp task will use all those strings and translations to render static pages for every language.

Also, is it possible to add a parameter --write-sync to make sure files are written synchronously? It's a bit of a problem to control it in gulp. It moves on to the next task, and that task could require files which should be written in the previous task.

Also, it would be great to make an export to be used with gulp (or any other node app). For example, a function which will take an object with options and run xgettext-template. This could be also explained in the README.

[smhg]

The general idea is that xgettext-template is a drop-in replacement for xgettext. Therefore it sounds good to support the same options. Or a subset, as is the case now, and extend them as the need arises. But let's not create new ones ourselves. At least not on the command line.

While I think xgettext-template should stay true to that idea, there might be room to move things out of this project and into another one or into the parsers.

Thinking out loud here: If we assume xgettext-template takes care of parsing command line options. Then parsers need to accept a subset of those, but they can accept more. In-between those are things like I/O and a general API. Currently xgettext-template takes care of those, but this could move to an in-between library. Although maybe this could still be kept together. Where additional options are only available through the API.

There is also the parser integration. Currently these are dependencies, but maintenance of those is ugly. Would be great if we could solve both.

[eldarc]

Regarding using xgettext inside a script instead as a CLI tool: It can be solved by adding an explanation to the README.

var xgettext = require("xgettext-template");
var upath = require('upath');

var gettextDirectories = ["src/templates", "src/pages"];

// Load all files that contain gettext strings into an array.
function gettextSources() {
    var sources = [];

    for(var i in gettextDirectories) {
        const directory = gettextDirectories[i];

        var files;
        try {
            files = recursiveReadSync(directory);
        } catch(err) {
            throw err;
        }

        for(var j in files) {
            const file = files[j];

            if(/^.*\.(htm|html)$/.test(file)) {
                sources.push(upath.normalize(file).replace("src/", ""));
            }
        }
    }

    return sources;    
}

var xgettextOptions = {
    directory: "./src",
    output: './locales/' + language + '.po',
    language: "Nunjucks",
    'from-code': 'utf8',
    keyword: ["gettext", "_","dgettext:2", "_d:2", "ngettext:1,2", "_n:1,2", "dngettext:2,3", "_dn:2,3",
            "pgettext:1c,2", "_p:1c,2", "dpgettext:2c,3", "_dp:2c,3", "npgettext:2c,3,4",
            "_np:2c,3,4", "dnpgettext:2c,3,4", "_dnp:2c,3,4"],
    'join-existing': true,
    'force-po': true
};        

xgettext(gettextSources(), xgettextOptions, function (po) {
    if (po && (xgettextOptions.output === '-' || xgettextOptions.output === '/dev/stdout')) {
        process.stdout.write(po);
    }
}

Regarding additional functionality. We could allow non-standard parameters only to be used when using the procedure above (through passing a xgettextOptions object).

However, the two additional features I asked about can be implemented separately. But I do believe that integrating it with xgettext-template will result in better performance.

I don't know much easier it will be to maintain parsers if they are not implemented as dependencies. Maybe writing a specification document on how parsers should format the parsed strings and what should they prepare can ease the maintenance a bit (and development of new parsers).

Just throwing ideas here.