LINQ to SharePoint and localized list names

Question

I'm trying to use Linq to SharePoint to save a new record in my list. I provided my own List definition for which I have 2 resource files that are giving the good list names (French and English).

When I browse my site in the English UI for my list "Videos", everything works fine, I can insert my new item in my list, my DataContext finds the correct list.

When I browse my site in the French UI, when the DataContext is trying to create the new record, an exception is thrown because it says it cannot find the "Vidéos" list.

The weird part, is that it works for other lists (only need to read data from those lists...).

Do I need a special DataContext?

Here's the failing code :

Video video = new Video()
{
    Title = inputFile.PostedFile.FileName,
    VideoUniqueIdentifier = newFileGuid.ToString("B")
};

// dc.GetList<Video>("Vidéos").InsertOnSubmit(video); // Fails
dc.Videos.InsertOnSubmit(video); // Passes, using the SPMetal provided value "Videos"
dc.SubmitChanges(); // Fails in french, passes in english

Answer 1

As requested the code to my helper class:

using System;
using Microsoft.SharePoint.Utilities;
using System.Globalization;
using System.Threading;

namespace DCubed.Core.Library.Helper
{
public static class ResourceHelper
{
    public static string GetValue(string key, int localeId)
    {
        // get localized string defined by 'key' from default resourcefile
        return GetValue(key, "DCubed", localeId);
    }

    public static string GetValue(string key)
    {
        // get localized string defined by 'key' from default resourcefile using (UI) culture currently used by thread
        return GetValue(key, Thread.CurrentThread.CurrentUICulture.LCID);
    }

    public static string GetValue(string key, string file)
    {
        // get localized string defined by 'key' from resourcefile 'file' using (UI) culture currently used by thread
        var retVal = SPUtility.GetLocalizedString(String.Format(CultureInfo.InvariantCulture, "$Resources:{0}", key), file, (uint)Thread.CurrentThread.CurrentUICulture.LCID);
        return retVal;
    }

    public static string GetValue(string key, string file, int localeId)
    {
        // CodeAnalysis requires string.Format to be called with a FormatProvider
        // CultureInfo.InvariantCulture can be used for this because 'key' will always be ASCII english alphabetical chars only,
        var retVal = SPUtility.GetLocalizedString(String.Format(CultureInfo.InvariantCulture, "$Resources:{0}", key), file, (uint)localeId);
        return retVal;
    }
}
}

to get for instance the url of the OOTB publishing site's pages list, you would call:

var pagesUrl = ResourceHelper.GetValue("List_Pages_UrlName", "osrvcore", web.Locale.LCID);

This will return the localized url (Pages for en, Paginas for Dutch, etc.) of a publishing site's pages list.

P.S. web in web.Locale.LCID in the method call of course refers to the SPWeb object the Pages Library is a part of.

Answer 2

When you use SPMetal to generate entity classes it creates your entities as (I am using OOTB Pages library as example):

[Microsoft.SharePoint.Linq.ListAttribute(Name="Pages")]
public Microsoft.SharePoint.Linq.EntityList<Page> Pages {
    get {
      return this.GetList<Page>("Pages");
    }
}

Problem is that Pages is Display Name of your default Pages library (take a look at DataContext.GetList(Of T) Method). If you apply different language pack library Pages will change its name accordingly. Strange but content types are culture invariant so Page (in .GetList<Page>) will remain the same.

In on English UI

dc.Pages.InsertOnSubmit(new Page(){.....} ); 
dc.SubmitChanges();

will work but it will fail on any other language because since Display Name is different and GetList cannot find list with Display Name of 'Pages'.

On other hand

dc.GetList<Page>("[Localized Page Library name]").InsertOnSubmit(new Page(){.....});
dc.SubmitChanges();

will work only for specified language.

I guess this issue could be handled if you re-write entity classes to be language aware (never done it). However then you loose option to regenerate your entity classes by using SPMetal.

There is one available workaround but personally I don't like it: SharePoint: SharePoint to Linq pitfall

Other option is to go back on using CAML and 'old ways' of inserting data and wait for next release of SharePoint. Maybe then LINQ to SharePoint will be less confusing.