Is it possible to generate a list of all marked strings in c# at compile time/runtime?

Question

So, I've got a little translation system set up for my app, where we generate a list of all strings that are marked as translatable, dump that in a CSV as the translation template, and then a translator fills out the next column with the translations.

The problem I'm trying to solve is how to extract a bunch of marked strings from a codebase, to automate the translation template generation.

An example line of c# code looks something like:

textBoxName.Text = string.Format(Translate.tr("Create {0}"), NextAutoName());

And c++ would look like:

info_out << tr( L"Grip weights range from {0} to {1}" )(low_weight)(high_weight) << endl;

On the c++ side, building the list of strings for the template generation uses a c++ parser (see my previous question ), which runs as part of the external builds over all c++ code in the project. Basically, any string that's placed in a tr() call is automatically extracted.

Is there a better solution with c# than writing another parser? I would love a list of strings that gets produced at compile time, or one that I can access at runtime. A List<string> would be great.

I'd like to keep the same translation file format, because that makes coordinating the two sides much simpler. As you'd expect, we reuse a lot of strings.

Right now it's much more convenient in c++ to keep the translation template up to date - I just need to make sure that the strings I want translated are wrapped in tr(), and the parser handles the rest. In c#, I currently manually inspect all strings, and update a dummy function on the c++ side with new strings. I'm getting close to breaking down and just writing another parser. I was hoping that c#, with its high-level features, might be able to do a better job here.

Answer 1

I did something similar (I was just pulling out a list of string constants) and I used the same parser for both C# and C++. Though it was more lexical analyser than parser, which works because the two languages have a very similar lexical structure.

Once you've got the list of strings, you can write it to a C# source file and compile it into your program. Your code would generate a file something like this:

namespace MyProject
{
    class MyStrings
    {
        public string[] Strings = {
            "pony",
            "cob",
            "stallion"
        };
    }
}

Then you can include this file in your project to give your code access to a list of its strings.

If you run your tool as a pre-build event it will happen as part of the build.

However, as Hans says, you might do better to look at the built-in localization support.

Answer 2

I have a project that actually does the exact same thing. Only the translation parser is itself written in C# (it's name is c3po). In addition to parsing the project, c3po is also responsible for generating files to send to the translation vendor as well as generating the files that the .net project uses to store the translated strings. We found it has several advantages over the "traditional" .Net resource files:

1) because c3po maintains it's own internal database of localized strings we can keep track of our own translation memory and make sure to only send new strings to the translators every month. It also removes strings that are no longer needed. This has saved us literary thousands of dollars in translation costs.

2) Developers are free to write whatever string they want, wherever they want and they don't have to worry about resource files.

3) c3po services several different projects at once which streamlines our interactions with our translation vendor.

4) We can automate c3po through our CI server so every time a developer checks in, (or once a night or whatever) we can have it do all of it's tasks including sending files to the translators, pick up new phrases, etc.