title: Custom column in a list view web part for a multilingual site does not take on custom language labels. Stays in default language
body: <p>I have what so far appears to be a fairly unique problem.  We are running a multilingual SharePoint 2010 environment with English as the default language and French as the secondary.  We have setup the sites in a variance relationship, but the issue I am discussing happens outside of a variant as well.</p>
  
  <p>We have created a library outside the variant (but within the collection) that the two sites must share.  A list view web part was created via Designer to add to each site to provide a quick view into the list.  If we are in the libary and switch to French, then update the column label it will remember the setting (because of the resource file) and maintain it as the language is flipped back and forth.  Where it doesn't work is as a web part in a variant or where the language is different.</p>
  
  <p>If the language is different, the out of the box columns work find, but the custom columns (all site columns not library\list columns) remain as the english label.  It doesn't matter if within a variant or outside with the browser language changed.  It always reverts back to English.  It's like it isn't using the same resource file that was used in the list itself.</p>
  
  <p>I created a custom view and modified it with xslt as per <a href="https://sharepoint.stackexchange.com/questions/50004/how-to-change-column-title-for-a-view-but-not-modify-the-list">https://sharepoint.stackexchange.com/questions/50004/how-to-change-column-title-for-a-view-but-not-modify-the-list</a> but this only worked within the list and did not occur in the list view either.</p>
  
  <p>I can't be the first that has come across it, either I am not performing my searches properly, no one has ever documented a fix for this or this is something we just can't fix with OOTB tools.  That's the other thing, the solution has to be accomplished OOTB or with minor client side changes.  I can't fire up Visual Studio because they are piloting Office 365 and have put a "No custom code" mandate on for migration (which is real tough for me.  I like my code ;P).</p>
  
  <p>Thank you all in advance.</p>