Graphs and partitions

First of all, graphs. Formally, a graph is defined as two sets: a set of nodes which compose the graph, and a set of edges between pairs of nodes. For example, the definition for the so-called diamond graph is the following:

And a representation for it could be the following:

While this is the simplest form of a graph, several additions can be made: weights or attributes can be assigned to either nodes or edges; edges can be directed; multiple edges can be allowed between pairs of nodes; etc. The modification we will be dealing with in this scenario is partitioning the graph’s nodes. As such, the graph is now defined as three sets: besides the nodes and edges, the set of partitions, where each partition is a non-empty set of nodes such that every node belongs to exactly one partition.

A possible partitioning of the diamond graph previously presented could be the following:

Coloring

Having defined the kind of graphs we will be working with, it’s time to define the problem itself. The graph coloring problem consists in defining a function that assigns a label (a “color”) to each node in the graph, with the restriction that every pair of adjacent nodes must have different colors.

For example, a valid coloring for the diamond graph presented earlier would be the following:

The goal here is to find a valid coloring that uses the minimum possible number of different colors. This value is called the chromatic number of a graph.

Determining if there is a valid k-coloring (coloring that uses exactly k colors) for a particular graph is usually difficult to determine, where difficult implies that it requires a huge computational effort; for those of you with background on CS, this problem is known to be NP-complete.

For .NET fans, it is worth checking the posts that Eric Lippert has been uploading recently on making a backtracking algorithm for the coloring problem using C#.

Partitioned Coloring

The coloring problem has several variants. For example, it might be of interest to minimize the not only the number of different colors used, but also the difference between how many nodes are painted with each color. Or allow that adjacent nodes have the same color, incurring in a penalty in an objective function, if it allows the usage of fewer colors.

In this case, the partitioned graph coloring consists in coloring one node per partition, with the restriction that two adjacent nodes may not have the same color. The difference with the standard coloring is that not all nodes must be colored, only one in each partition.

Going back to our diamond example, by cleverly picking which nodes to color in each partition, we can partition-color the whole graph using a single color:

Even though not all nodes are to be colored, this variant of the problem is still computationally difficult (NP-complete) to solve. Most approaches to it are heuristic, this is, they do not find the optimal solution, but offer a reasonable one in a reasonable time, as all algorithms that guarantee finding the best solution take too long to execute for large graphs.

Our goal will be to use a technique called integer linear programming to solve this problem, obtaining the exact solution in a reasonable time, for medium-sized instances.

Linear Programming is best described as a technique, in which we want to maximize or minimize an objective function subject to a set of constraints. It is called linear because both the objective function and the constraints are linear inequalities on the variables.

And just to make sure that no one is left behind: a linear function on a set of variables is a function , where are numbers. For example, is a linear function, whereas isn’t.

Example: diet problem

A classical example for linear programming is the diet problem. We want to determine a diet that satisfies all of our nutritional requirements while keeping it as cheap as possible. We have a set of different foods that fulfill certain requirements by containing a certain amount of proteins, vitamins, etc; and each food has a certain price per kilogram. Needless to say, the values in the following table are completely fictional.

Suppose also that we need at least 60 units of each nutrient in our diet. Our objective will be to find a solution that specifies how much food of each type we should buy to cover all of our needs while keeping budget to a minimum.

In order to create a linear programming model, we must first define which variables we will be working with. We will define as how many kg of food we will be purchasing; therefore, our variables will be .

Now we must specify our restrictions. We want to consume at least 60 units of each nutrient, and each food provides a certain amount per kg of it. For instance, we may express that we need 60 units of carbs as:

Note that each unit of apples provides 2 units of carbs, therefore the total amount of carbs provided by apples will be the product ; same holds for all foods.

Similar expressions can be derived for vitamins:

And for proteins:

Needless to say, all amounts must be positive, as we are buying food, not selling it. Therefore, we add constraints:

The set of constraints we have built specify a set of valid or feasible solutions for us. For example, we will not accept a solution in which we purchase only 20kg of apples, since although that satisfies our vitamin intake, it does not satisfy carbs and proteins.

What we have to do now is, from every feasible solution, choose one that minimizes how much money we spend. So far, nothing prevents buying a whole supermarket of food from being a valid solution, albeit a very expensive one. In order to prevent that situation, we add an objective function to minimize, which is the cost of all the food we want to buy:

The purpose of the objective function is to measure how good or bad a particular solution is, whereas the constraints restrict what we consider a valid solution for us. Putting all of them together, we have constructed a linear programming model for our diet problem.

Generalizing

A linear programming problem consists in the minimization of a linear objective function subject to a set of linear constraints, which can be expressed as , where is a matrix in which element represents how much each unit of variable contributes to satisfying demand for product .

Note that by using simple algebraic operations we can include all kind of non-strict linear constraints: , and . Therefore, there are different canonical ways to represent a linear programming problem, one of which is the one we have already seen:

We may also express it as a maximization of the objective function:

Or either of them subject to a set of equalities:

In all canonical forms variables are usually restricted to be positive or zero, which makes sense in most scenarios. In a future post I would like to revisit this subject, using one of the canonical forms to go a little deeper into the economical interpretation of each of the variables and constraints. But for now, we will go straight to the resolution.

Resolution

We have seen how to model an optimization problem using linear programming, but we still need to know how to solve it. Luckily, there are several algorithms that deal with these specific problems, one of the most widely known is simplex.

How simplex works deserves another blog post of its own, but for now lets just say that it solves most models incredibly fast. The problem of solving an LPP (linear programming problem) is known to be polynomial, which means that it can be solved within an acceptable timespan.

Needless to say, linear programming is an invaluable tool for modeling several real life scenarios, and has multiple applications within operations research. In future posts I would like to dwelve deeper into linear programming, which I will do if I have some spare time, but for now I will go on blogging within the scope of my thesis: integer linear programming.

This work gives Manas Research division a very different direction than the one Beta gave it. Whereas his work was in the field of lambda calculus, my thesis is in operations research, integer linear programming to be more specific, dealing with a generalization of the graph coloring problem.

During these weeks I will be blogging about linear programming in general and the scope of my thesis, but for now I will upload the presentation I gave during the first days of June in the last ALIO/INFORMS joint meeting that took place in Buenos Aires so you can get a preview of what has been done so far.

Although there is a standard way for deleting items, there is few information on how to deal with them on the model or the controllers without messing with the unprocessed parameters. I’ll try to go over some of the different ways for deleting (or rejecting) children.

Do not create at all

Before actually deleting, it is important to consider the case in which you do not want to create the child in the first place. Doing this is easy and handled completely on the model: there is a very useful reject_if option that allows you to specify conditions under which you do not want to process a specific child.

accepts_nested_attributes_for :children
  :reject_if => proc { |att| att['name'].blank? }

The procedure runs for every child, if it evaluates to true, that set of parameters is ignored. Note that this is not the same as a validation: the child will be ignored simply rejected, and will not raise a validation error (children validation and parental control will be left for another post).

Remember that here you must predicate on the raw attributes. The class is not constructed (unless you manually do it in the procedure) so you do not have access to any model fields or instance methods.

This method is useful when you display a text field for the user to complete, which represents the child. If the user does not want to fill that field (name in the example), the child will not be created.

Suppose you have 5 empty text fields for the user to fill his/her hobbies. Should a user have only 3 hobbies, then you want to create only 3 instances of the Hobby class that belong_to that user.

Check _delete

The recommended option for deleting an item is setting a _delete parameter to true in the attributes. This is, if you have a set of parameters like the following:

children_attributes =>
    1 => { id => 16, :name => Jack, :_delete => true }
    2 => { id => 18, :name => Mary }

Then Jack will be removed from the association to his parent. If the association has :dependent => :destroy set, Jack will be completely destroyed.

It is critical not to forget adding the allow_destroy option to the nested attributes method:

accepts_nested_attributes_for :children,
  :reject_if => proc { |att| att['name'].blank? },
  :allow_destroy => true

The rationale behind this feature is that if the user wants to delete an item, he/she must simply check a box named _delete and the controller will forward the parameter to the model, which will remove the child.

If you want to use a different method for deleting (in the hobbies example, delete when the user clears the textbox) you can use javascript to toggle a hidden checkbox whenever a textbox changes, for example. But this is clearly delegating model logic to the view, so a different approach is needed.

Let the controller do it

Since we are messing with the raw params representation of the object, the controller could simply iterate over each of the children_attributes and add a _delete parameter whenever needed, if a certain condition occurs.

However, if we had rejected the previous javascript-based solution for deleting a child since it implies keeping model logic in the view, why should we be happy by moving it to the controller? We have to move another step further.

Mark for destruction

No, we will not hack the attributes= method to manually walk the children_attributes params and add the deletion flag. Since we are in the model, we will use the objects themselves.

The AutosaveAssociation class has a handy method for marking objects for removal which allows you to flag certain objects that should be destroyed when the parent is saved.

Therefore, you can add a callback before the parent is saved that walks through the children and marks for removal those who match a certain condition. And this time, you have the actual children, not some raw-params representation:

before_save :mark_children_for_removal

def mark_children_for_removal
  children.each do |child|
    child.mark_for_destruction if child.name.blank?
  end
end

This allows you to keep all your model logic in your model, where it belongs, and avoid messing with nested parameters in the view or the controller.

Since version 2.3, Rails also provides a convenient way of dealing with multi-model forms, specifically parent-children relations. Ryan has an excellent blog post on the subject, I strongly recommend taking a look at it before going on reading if you have never used accepts_nested_attributes_for or fields_for.

To make a long story short, the accepts_nested_attributes_for method applied to a model allows you to assign values directly to the children, using the same hash format as for standard attributes.

An example

For example, having a Parent class which has_many children of class Child, a typical POST with data for both classes would look like the following:

params =>
    action => update
    id => 1
    controller => parents
    parent =>
        first_name => John
        last_name => Doe
        age => 40
        children_attributes =>
            1 => { id => 16, :name => Jack }
            2 => { id => 18, :name => Mary }

(I removed several symbols from the hash to improve readability)

Note the children_attributes element among the parent’s attributes. The fields_for command produces the necessary syntax to produce POST data that will be converted to a hash in the convenient way for accepts_nested_attributes_for to interpret.

The children_attributes is not an array but a hash, and its keys are a simple indexer, not the IDs of the model, which is used to group attributes from a single child entity toghether.

The reason for not using IDs is simple once you think about it: the model being edited might not be saved by the time it is sent to the client (therefore its id is nil), so it is a good practice to keep a hidden field with the id for each of the children being displayed.

On the view

Taking a look at the page source generated, we can see the naming convention rails uses to generate a hash with the previous structure:

parent[children_attributes][0][name]

This naming is automatically generated by opening a new context using the fields_for instruction in the view.

On the model

The change in the model is really simple, as it involves simply telling Rails which classes might be updated directly from the parent:

accepts_nested_attributes_for :children

We will look into additional options (rejecting and deleting) later.

On the controller

Note that all these changes only involve the view (clearly) and a single line in the model to specify which classes may be modified through the attributes accessor. The controller remains as dumb as before:

def update
    if @parent.update_attributes params[:parent]
        redirect_to :action => 'success_page'
    else
        render :action => 'edit'
    end
end

Not even a single mention to the children, the method is untouched.

After that…

Once you start dealing with certain validations and callbacks, keeping in mind when are these children validated created, updated and deleted is extemely important. Deleting items is specially delicate here, and will make a good subject for the next post!

However, since I’ve been working with Ruby on Rails during the last months, I would like to start going in that direction.

And the first post on the subject will not be eternally delayed as the other ones.

Although javascript code in ASP.NET pages can be internationalized using the <%= %> syntax, pure js files are not processed, and therefore a different mechanism for dealing with javascript is needed.

A quick google search will return multiple results. BerliOS javascript gettext implementation provides an interface with the same methods as the ones provided by any other port. It requires that the content of the translation files is available as a dictionary visible to the script.

Note that it is not necessary to have a full implementation of gettext client side. Having a simple function for translation, checking a simple dictionary will do:

Resources.T = function(str) { return Resources[str] || str };"

The Resources dictionary can be easily passed to the client via JSON, by retrieving the full dictionary on the server and encoding it.

An efficient approach for including this data is having a server endpoint returning this dictionary as json and including it as a referenced script in all master pages. This will cause the browser to download the full set of resources the first time and then used it cached version; therefore it is not necessary to send the full load of strings on every request. Make sure to add the culture of the requested resource to the URL, so when a user changes his/her language the new resource set is loaded.

As for .po generation, xgettext seems to crawl javascript code without too many issues, so this point should not pose any problems.

On the other hand, the gettext-js library provides client side methods for parsing .po files. Therefore, it is not necessary to add a server endpoint with the intelligence to convert the po file into its json representation: the library will take care of this by itself, just point itself to an URL containing the file to parse and voila!

Note, however, that since the po file may have some metadata which is used only during translation time (such as in which files is the string referenced, the format, etc), its size may actually double or triple its json representation, making it more expensive to be sent to the client.

Also, conversion of the .po files into json can be done a single time in the server and sent to every client, instead of having each of them spend extra browser processing time parsing and processing.

Either approach you take, gettext remains an excellent tool for internationalizing your web application.

The scenario

Suppose we want to test the behaviour of a class in charge of setting a user’s position based on supplied lat/long values.

interface IUserLocator
{
    bool Place(User user, double latitude, double longitude);
}

Doing it the wrong way

A typical fixture covering some invalid scenarios, developed by a copy paste fan, would look like the following:

[Test]
public void ShouldFailLatitudeLessThanNeg90()
{
    bool result = locator.Place(user, -100, 20);
    Assert.False(result);
    Assert.AreEqual(previousLatitude, user.Lat);
    Assert.AreEqual(previousLongitude, user.Long);
}

[Test]
public void ShouldFailLatitudeMoreThan90()
{
    bool result = locator.Place(user, 100, 20);
    Assert.False(result);
    Assert.AreEqual(previousLatitude, user.Lat);
    Assert.AreEqual(previousLongitude, user.Long);
}

[Test]
public void ShouldFailLongitudeLessThanNeg180()
{
    bool result = locator.Place(user, 20, -190);
    Assert.False(result);
    Assert.AreEqual(previousLatitude, user.Lat);
    Assert.AreEqual(previousLongitude, user.Long);
}

Refactoring

After the 3rd copy-pasted method, it should be pretty obvious that our code is demanding to extract the common code into a separate method which executes the body of the test. After this refactor we would have:

private void ShouldFailInvalidLatLong(double lat, double lng)
{
    bool result = locator.Place(user, lat, lng);
    Assert.False(result);
    Assert.AreEqual(previousLatitude, user.Latitude);
    Assert.AreEqual(previousLongitude, user.Longitude);
}

[Test]
public void ShouldFailLatitudeLessThanNeg90()
{
    ShouldFailInvalidLatLong(-100, 20);
}

[Test]
public void ShouldFailLatitudeMoreThan90()
{
    ShouldFailInvalidLatLong(100, 20);
}

[Test]
public void ShouldFailLongitudeLessThanNeg180()
{
    ShouldFailInvalidLatLong(20, 190);
}

Which is a lot better than before. However, we are forced to keep a different method for each of the different parameter combinations we are injecting into the auxiliary testing function.

We could keep all of them in a single method and loop through a list of parameters configurations, but in this case NUnit would not be able to distinguish them as different tests and fail the whole set if a single one does. And even worse, we don’t get a SetUp method for every case unless we call it explicitly, which is a huge drawback.

Injecting parameter values

Luckily, NUnit included native support for handling lists of parameters in version 2.5. Now we can simply write:

[Test]
[Sequential]
public void ShouldFailInvalidLatLng(
    [Values(-100, 100, 20)] double lat,
    [Values(20, 20, 190)] double lng)
{
    bool result = locator.Place(user, lat, lng);
    Assert.False(result);
    Assert.AreEqual(previousLatitude, user.Latitude);
    Assert.AreEqual(previousLongitude, user.Longitude);
}

The Values attribute applied to a parameter lets us define which set of values we want to inject into that parameter for testing. NUnit will simply iterate through all the values, generating a different test for each of them.

Note the Sequential attribute applied to the test. By default, NUnit will generate all possible combinations of the parameters’ values; in this case, we want a sequential approach to only generate 3 tests: one with the first set of values (-100, 20), another one with (100, 20) and the last one with (20, 190). Another option is to use the Pairwise attribute, which is a restricted variation of the combinatorial, that guarantees that every pair of different parameters will be executed, which is useful to control the amount of tests generated when handling multiple input parameters; however, it is not what we want in this case.

Now, this is how it looks like when ran in the console:

It is even clearer than its verbose counterpart when you look at them together, as its groups all the instances of the same method under the same treenode.

Generating parameter values

Besides handling parameter combinations, NUnit also offers multiple options for injecting parameter values, such as the Range and the Random attribute, which generate values inside a specified range with a certain step (in the former) or in a completely random fashion (in the latter).

The following example will generate four different values for latitude, and three different random values for longitude, all of them in a valid range.

[Test]
[Combinatorial]
public void ShouldSetLatLng(
    [Range(-90, 90, 60)] double lat,
    [Random(-180, 180, 3)] double lng)
{
    bool result = locator.Place(user, lat, lng);
    Assert.That(result);
    Assert.AreEqual(lat, user.Latitude);
    Assert.AreEqual(lng, user.Longitude);
}

Whenever we reload the test suite, NUnit will generate new fresh values for the randomized parameter. Losing determinism in your test suite is not something to overlook, so you should actually think twice before adding a random attribute to a parameter.

On the right is the tests generated as output of the test case above. Note that with very little effort the values generators, paired with the combinatorial attribute, produce a considerable number of test cases.

Extracting common data

Yet another way to supply values is, if you don’t the noise generated by the values attribute applied on every parameter, or if you want to reuse a set of data, is the ValueSource attribute, which lets you pull data from another source, in the following fashion:

public class LocatorPoints
{
    double[] latitudes = { -90, -60, -30, 0, 30, 60, 90 };
    double[] longitudes = { -180, -90, 0, 90, 180 };
}

[Test, Sequential]
public void ShouldSetLatLng(
    [ValueSource(typeof(LocatorPoints), "latitudes")] double lat,
    [ValueSource(typeof(LocatorPoints), "longitudes")] double lng)
{
    bool result = locator.Place(user, lat, lng);
    Assert.That(result);
    Assert.AreEqual(lat, user.Latitude);
    Assert.AreEqual(lng, user.Longitude);
}

This allows you to define the data sets and the tests applied separately, and reuse sets of data whenever necessary. With this feature we are not only extracting common code, but also extracting common datasets, and generating all combinations between them with ease.

The TestCaseSource attribute

You may choose to have even more control on the data supplied (and even on the values returned by the test!) with the TestCaseSource attribute.

One way of using it is simply as a collection of value sources, specifying together all the input parameter combinations you are interested in:

public class LocatorPoints
{
    object[] valid =
    {
        new[] { -90, -180 },
        new double[] {  90,  180 },
        new TestCaseData(30, 180)
    };
}

[Test]
[TestCaseSource(typeof(LocatorPoints), "valid")]
public void ShouldSetLatLng(double lat, double lng)
{
    bool result = locator.Place(user, lat, lng);
    Assert.That(result);
    Assert.AreEqual(lat, user.Latitude);
    Assert.AreEqual(lng, user.Longitude);
}

The source of points may be a method instead of a field, which allows you to dynamically generate the parameter values you may want.

Note the way the combination (30, 180) is injected: it uses the TestCaseData class. This class grants much more control over the parameterization than only specifying the input parameters. It provides a fluent interface to set the return value, expected exception, description, name, category, etc.

Let’s see how a complete fixture, for both valid and invalid tests, would look like when written using this interface:

public IEnumerable<TestCaseData> Values()
{
    yield return new TestCaseData(0, 0).Returns(true)
        .SetName("ShouldSetLatLongOrigin").SetCategory("valid");

    yield return new TestCaseData(90, 180).Returns(true)
        .SetName("ShouldSetLatLongMaxValues").SetCategory("valid");

    yield return new TestCaseData(100, 30).Returns(false)
        .SetName("ShouldNotSetInvalidLat").SetCategory("wronglat");

    yield return new TestCaseData(20, 190).Returns(false)
        .SetName("ShouldNotSetInvalidLng").SetCategory("wronglng");
}

[Test]
[TestCaseSource("Values")]
public bool SetLatLng(double lat, double lng)
{
    bool result = locator.Place(user, lat, lng);

    Assert.AreEqual(result ? lat : previousLatitude, user.Latitude);
    Assert.AreEqual(result ? lng : previousLongitude, user.Longitude);

    return result;
}

By using a simple method that yields different configurations for our parameterized  test we can set the input values, the expected return value, a specific name, category, etc. Basically we can write nearly a whole fixture using a single test and adequate parameters.

Whether this is too much injection over the tests or not is another discussion, finding a right balance is no easy task. In the very end, it is just another way of writing tests.

Adding a simple control which we will name just “t” (and place it in namespace “t” as well) that handles translation of strings contained within can prevent the need of the code syntax in an ASP.NET. Therefore, we can write

<h1><t:t runat=”server”>My Title</t:t></h1>

instead of having to fall back to

<h1><%= Messages.T("My Title") %></h1>

The angle bracket syntax feels more consistent with the rest of the HTML, and is much more comfortable to write. The only drawback is the need of the run at server attribute which is unavoidable.

The code for this control is fairly straightforward:

[ParseChildren(false)]
public class t : Control
{
    string content;

    protected override void AddParsedSubObject(object obj)
    {
        if (obj is LiteralControl)
        {
            content = Strings.T(((LiteralControl)obj).Text);
        }
    }

    protected override void Render(HtmlTextWriter writer)
    {
        writer.Write(content);
    }
}

Extracting the content

The problem with this approach is that the xgettext tool only supports function calls, not tags. Therefore it is necessary to write a custom code crawler that extracts them. The easiest way to do this is having a tool run right before the invocation to xgettext and generate additional files that contain only the invocations to the Messages.T function, so they are actually recognised by xgettext.

The incredible simple regex for doing this is:

@"<\s*{0}\s*[^>]*>(?<text>.+?)</\s*{0}\s*>"

Well, maybe not that simple, but it does work. It must be formatted with the name of the tag (in our case, “t:t”) and it will extract whatever content it can find between this tags in the “text” capturing group.

We can then write a new file containing all of this captures, each of them enclosed in an invocation of Messages.T(), and this file will be easily handled by xgettext.

Handling standard C# calls

But this is not all. If you do use the <%= syntax in ASP.NET code and want xgettext to find calls to Messages.T() within them, you will find out that it throws a lot of errors. Evidently, xgettext was thought to parse standard C# code and not the one embedded within an ASP.NET page.

The best practice here is to also extract those strings into a separate well formed files. A nice regex to capture them is:

@"(?<!\w){0}\(""(?<text>[^""\\]*(?:\\.[^""\\]*)*)"""

Remember to format this regex with the function name (Messages.T in this case), otherwise looking for a function named {0} will not return any matches whatsoever.

If you are interested in this processing, you may want to take a look at the tool we developed here.

A resx file is actually just an XML, but there are not many open source tools oriented for translators to easily handle them. Therefore we decided to try GNU gettext.

Gettext uses .po file format which basically consists of pairs of key/values. The interesting thing here is that keys in Gettext are the original untranslated text, so there is no need to keep the extra file containing untranslated strings. These files also keep tags, occurrences of the string in the code, and any other annotation inside comments, and there are plenty of helpful tools to handle them, specially designed to be used by translators, such as PoEdit, or the Pootle server which provides an online store for uploading, translating and merging .po files.

(just as a side note, NET resource files can be converted to a plain key=value text format using the ResGen utility; however, this format lacks all the added value provided by po files.)

GNU Gettext for windows can be downloaded from here, or you may want to directly use the tools included in the CygWin environment.

Handling messages

As gettext does not require an extra untranslated resource file, with the default key=value mappings for each message, it provides an utility (xgettext) to extract all calls to any specified "translator" function in code.

For example, suppose we have the traditional example:

Console.WriteLine("Hello {0}!", name);

Using traditional .NET resource files, we should create a Resources file, add an entry with the text, and reference it:

Console.WriteLine(Resources.Hello, name);

However, using gettext, we define a function (one of the defaults is GetString, although we may change it to a much shorter one) that marks and translates strings and enclose the string within it:

Console.WriteLine(Resources.GetString("Hello {0}!"), name);

Using a shorter version with format string included:

Console.WriteLine(Messages.T("Hello {0}!", name));

This ends up being a much faster way of manipulating strings, without requiring the need of editing a separate file.

Behind GetString

Although GNU gettext tools already provide a default implementation of a Resources Manager, I prefer writing a custom version with more control over strings manipulation, and using the default .NET logic for satellite culture assemblies lookup (as the default implementation does it manually).

A resources manager, which we shall name Messages , can be implemented by using a very similar structure to the Resource class generated by .NET when we add a resx file. That code loads the resource dictionary, and if you take a closer look, every method for accessing the externalized strings is just wrapping the key string:

/// <summary>
/// Looks up a localized string similar to This is a test.
/// </summary>
internal static string TestString {
    get {
        return ResourceManager.GetString("E_NoScriptManager", resourceCulture);
    }
}

Therefore, we can bypass those strongly typed methods and provide direct access to the dictionary itself. Since the keys are the untranslated version of the strings, we can simply write:

/// <summary>
/// Looks up a localized string.
/// </summary>
/// <param name="t">The untranslated string.</param>
/// <returns>Translated string according to the resource culture.</returns>
public static string T(string t)
{
    return ResourceManager.GetString(t, resourceCulture);
}

Here is the full version we are currently using with multiple overloads to handle string formatting and specifying a certain culture, in case you want to use it.

Note that the ResourceManager NET’s class automatically looks up the string based on the invoker thread’s current UI culture property, unless you specify a different one.

Creating the PO files

If we want to get our strings localized, we must generate the po files to be distributed to the translators and then reincluded in the project. Creating these files is extremely easy using the xgettext tool as we had previously said.

The first step is to create a files list to be crawled by this tool. The simplest way is using a DOS dir command to retrieve all csharp files and store them into a list. This can be done by using:

dir .\Source\*.cs /S /B > Strings.filelist

The /S option forces to check on subdirs (a behaviour that xgettext cannot be instructed to have) and the /B prints a plain list with only filenames.

Then we run xgettext feeding it with the filelist we have just generated, and instructing it to process strings included in calls to Messages.T:

xgettext.exe -k -kMessages.T
    --from-code=UTF-8 -LC# --omit-header
    -oMessages.po -fStrings.filelist

The –k parameter specifies the function we want to extract strings from, –f is the filelist we use and –o the output po file, which will look like this:

#: D:\Test\Source\Hello.cs:10
#, csharp-format
msgid "Hello {0}!"
msgstr ""

This file can be interpreted by any of the tools discussed before (like PoEdit). One for each different language is generated and distributed to translators.

Creating the resources files

We have marked the strings for translation, extracted them and are translating them at runtime using the T function. What we are missing is actually creating the resources files to be retrieved by NET’s ResourceManager, using the translated po files.

These files must conform to a specific resource format understood by the resource manager. Luckily, .NET provides a both a ResGen tool for creating them from other simpler formats, such as a plain text name=value file, as well as a ResourceWriter class.

What we did is develop a simple tool using this class which parses po files and outputs them as a NET resources file; you can find the code here. So all you have to do is invoke it with the input po file:

Msgfmt.exe -iMessages.es.po -oMessages.es.resources

By including this resources file in the Visual Studio project, a satellite assembly for the specific culture will be automatically generated. Note that if you add it in a folder Resources, for example, the path to access it when creating the resources manager will be ProjectName.Resources.Strings.

In the case of ASP.NET projects, you should deploy the resources file to the App_GlobalResources folder, and access it via Resources.Strings:

Getting the user’s culture

After all this work, we still have to enable some mechanism for getting the user’s preferred culture and use it in the current thread, so our application will be effectively displayed in the chosen language.

I will not be going deep into this subject, as setting the culture for desktop applications is mostly automatic, and Sergio has an excellent post about how to deal with i18n of ASP NET MVC websites via configuration, cookies and HttpModules.

More to come…

There are some non typical scenarios which you may run into when dealing with this solutions. Some of the most interesting we ran into are how to deal with internationalization of message sending, when the recipient’s culture may differ from the sender’s, or how to make an easy translation function for the ASP NET views.

I hope to be publishing more on this subjects soon.