I'm currently using reflection to do this, is there a better way?

Question

o will always come from an entiryRef/TEntity (from linq 2 sql)

I'm ok with a c# or vb.net solution (I will convert it into vb.net if you can't)

Public Function desc(Of t)(ByRef o As t, Optional ByVal PropPrefix As String = "desc") As String
    If o Is Nothing Then
        Return ""
    Else
        Dim bind = Reflection.BindingFlags.Public Or Reflection.BindingFlags.IgnoreCase Or Reflection.BindingFlags.Instance
        Dim _desc = PropPrefix & If(var.Sess.lang = Sess.elang.en, PropPrefix & "en", "fr")
        Dim pinfo As Reflection.PropertyInfo = o.GetType.GetProperty(_desc, bind)

        Return pinfo.GetValue(o, Nothing).ToString
    End If
End Function

little background

I have a database like this

tableUser
-----------------
id
name
countryid

tableCountry
--------
countryid
descEn
descFr

when I'm showing the information about a user, I want to easily show the good language selected in the application

that one example, I have lots more table and lot more lookup table

with linq 2 sql if the field in the database is null, the object will be "nothing"(null) and I'm catching that with the first if then I'm getting the corresponding language field

Answer 1

Unfortunately, runtime reflection will be required unless you can integrate a desc method into each object, perhaps through some sort of entity base class or code generation and partial classes.

The code generation approach: For each entity class, if it contains one or more descFoo properties, generate a desc property that pulls the correct one. If you cannot modify the CodeDom before it is written, you can also compile the entity classes, reflect/introspect the results, generate partial classes, and recompile with the added code.

Since these are entity classes, though, it appears to me as though a schema change might be preferable. Rather than using multiple descFoo columns, add a table consisting of {entity PK, language, text}.

Answer 2

You cannot do it (much) better with your current design. Instead you should think about a major redesign and obtain the localized values from a dedicated table instead of having columns for all languages.

Your description field could just hold an DescriptionId, and you can look this id up in the Descriptions table by additionally supplying a language identifier.

DescriptionId | Language | Description
--------------------------------------
            1 | fr       | French Foo
            1 | en       | English Foo
            2 | fr       | French Bar
            2 | fr       | English Bar

This easily allows adding other languages later. If you don't expect other languages, you can use the following.

DescriptionId | English     | French
----------------------------------------
            1 | English Foo | French Foo
            2 | English Bar | French Bar

Just to clarify - I don't suggest to introduce one localization table per entity or column, but one for all entities and columns. So all columns containing localizable information would become foreign keys to the same table. In consequence it would become possible to centralize the code obtaining the localized string instead of recreating it for every entity.

I had the same idea as papper1337, but did not present it, because I believe redesigning the database is the way to go. I would have suggest the following.

Create an interface ILocalizedEntity.

public interface ILocalizedEntity
{
    String descEn { get; }
    String descFr { get; }
}

Add this interface to all localized entities. This can be easily done because LINQ to SQL creates partial classes. In C# I would for example create a new file Country.cs and add the following code.

public partial class Country : ILocalizedEntity
{
}

The interface is implemented by the LINQ to SQL generated code.

Now you create a method like the following.

public static GetLocalizedDescription(this ILocalizedEntity entity)
{
    if (entity == null)
    {
        return String.Empty;
    }
    else
    {
        switch (Session.Language)
        {
            case Language.English:
                return entity.descrEn;
                break;

            case Language.French:
                return entity.descrFr;
                break;

            default:
                throw new InvalidOperationException();
        }
    }
}

This is a C# extension method and you can use it as follows.

someEntity.GetLocalizedDescription();

Answer 3

I agree with Daniel Brückner.

That being said, an alternative implementation would be to use interfaces like so:

public interface IEnglish
{
 public string DescriptionEN { get; }
}

public interface IFrench
{
 public string DescriptionFR { get; }
}

public interface IMultilingual : IEnglish, IFrench { }

public void desc<T>(ref T o, string propPrefix) where T : IMultilingual
{
 return Sess.lang = Sess.elang.en ? o.DescriptionEN : o.DescriptionFR
}

Then whatever class contained the english / french properties would implement IMultilingual and live happily ever after.