Develop Reference

Can you add a language without forcing a rebuild?

My app has been designed to be able to run on two different languages, english and czech. In order to accomplish this, I've created 2 resource files:
If an end-user would like to add another language, for example GlobalStrings.fr-FR.resx, is it possible to allow for this functionality without rebuilding the application?
If we look at the properties of these resource files:
I'm not understanding what embedded resource means. Does this mean that in order for the app to consume this file, the application must be rebuilt?
How do we create a resource file, that is open to be extended/changed by the end user, without having to rebuild the entire application
?

Regular .Net resources are compiled into assembly with particular name and loaded by matching that name. So if "end-user" is ok to translate strings in resx file and compile resources into assembly with particular name (like "MyResources.cs-cz.dll") you can do that with default .Net behavior without recompiling main code. See MSDN:Packing and Deploying resources and related links for more information.
Note that you don't need Visual Studio for it and can use csc command line compiler to embed resources on user's machine - so if your really want you can provide simple script that compiles corresponding resx locally. Note that editing XML (resx) as text is generally not possible by regular person due to required encoding of some characters - consider technical level of your "end-users" before going that route. Plain text version of source for resource may work in more cases.
Usually this is not the case - if end-user localization is requirement you would create some sort of custom resource string management by loading strings from plain text files or database that users can update locally.

custom client localization form Win Forms

I have big WinForms project,and now i need to create module,where client can create/update/delete its own localization to a project (dataGrid Name-Value,like resx files).Also we need a default localization.But in WinForms every form has own resx file=( What the best way to realize this feature?Xml file or it could be done by resx files.
In previous version of the project (unfortunately no source code) it was jsut text Key-Value file.

There are diffrent way to approch that topic. On top of my head i have 2 solutions for that problem.
First solution
Since *.resx files are compiled into executable you cannot really modify them, but since you are using them already easiest approach would be to change reference from original build in *.resx file to one you have made and put in your folder hierarchy. That way you could use your build in files as default and search for other languages if they exists replace them.
This might help you Modifying .resx file in c#
Downside of this approach is that resx files are c# classes and could be realy hard to edit outside of Visual Studio editor.
Second solution
If you have time to move all of your default texts to *.xml files you could do that and use similar approach like in *.resx file. Since i found it easier to create and edit xml files this could save your day. Downside of that approach is time required to connect every string to your windows forms app.

Using Resources (resx) Inside a ClassLibrary, that can be changed without recompiling

I need to make a ClassLibrary, to contain different Resource Files (resx). This needs to be done, so I can reuse these resources on multiple projects.
After reading for quite a while on how to achieve this, I'm still nowhere near close to an answer.
Note that i need to achieve this in a way that I don't have to recompile the proyect if I want to change a value
Is there a simple way to achieve this that I'm missing?

Hate to be the bearer of bad news, but I'm afraid you're trying to use RESX files for something other than what they're designed to do. RESX files are compiled into .resources files, which are then embedded into the assembly during the build. In other words, if you don't recompile, you won't see any changes that are made to the resx file reflected in the module.

The benefits of RESX files extends far beyond providing compiled cultural/language text tightly coupled to a deployed solution. They have the potential to provide a simple and flexible set of content managed outside the software development process. Some views here:
What are the benefits of resource(.resx) files?
Yes you can work with your RESX files without having to compile them. See here:
Edit ASP.NET MVC 3 resx files in deployment server without recompiling
Yes you can share RESX files between different projects and even roll your own resource manager. You can maintain alternate sets of resources, serving up alternate content depending on for example the user context. I have been involved in a project where we implemented something along these lines to great affect, in my case the solution was used to provide white labeling. Some detail to get you started here:
http://msdn.microsoft.com/en-us/library/aa905797.aspx

C#: Resource file refactoring

Does anyone know of a good tool for refactoring resources in a visual studio 2008 solution?
We have a number of resource files with translated text in an assembly used for localizing our application. But they have gotten a bit messy... I would like to rename some of the keys, and move some of them into other resource files. And I would like those changes be done in my code, and the translated versions of the resource files as well. Maybe a some analysis on what strings are missing in the translated versions, and what strings have been removed from the original as well...
Does anyone know of a good visual studio extension or ReSharper plugin that can help me with this? Right now it is kind of a pain, because I have to first rename the key in the base resource file, then in the localized versions. And then compile to get all the compile errors resulting from the key which now have a different name, and then go through and fix them all... very annoying =/

I just stumbled across this question which prompted me to blog about what I use for this problem here Moving and renaming resource keys in a .resx file.
I have two PowerShell scripts, one which renames a resource key and one which moves a resource key from one resource file to another.
Using these scripts I am able to rename a resource key:
.\RenameResource.ps1 oldKey newKey
And I can move a resource with key “keyName” from a file named “ResourceFile1.resx” to “ResourceFile2.resx”:
.\MoveResource.ps1 ResourceFile1 ResourceFile2 keyName

RGreatEx is suitable when you need to move a lot of strings in code to resources. But in this case it can't help.
There are no such plugin (*this means that I have never seen such and didn't found in google, but there are some localizators which can help to translate to new language - http://www.peoplewords.com/download/ResxEditor.aspx and http://sourceforge.net/projects/resx/ and http://www.resx-localization-studio.net/ and http://madskristensen.net/post/A-NET-resource-editor-application-for-resx-files.aspx). But you easily (may be) can do this without it.
All you need is to write some small tool which will generate common dictionary of strings for a selected language for several selected resx files and store it somewhere. Another tool you need to create is a tool which will generate new resx files (after your changes) using changed resxs as templates and using the dictionary generated by previous tool.
Of course all new and changed strings will be missing but this can be fixed manually. This will take not so much time (especially when you'll add functionality to write a log of missing strings during generation new resx) .

Were looking into Sisulizer to localize our software, and I think it accomplishes what you're asking for (a bit overkill perhaps?)

Seems to be some new features in ReSharper 5 that helps with this
Localizing your Applications with ReSharper 5
This demo shows how ReSharper 5 helps you make strings in your code localizable quickly, without breaking your regular workflow. Working with resource files is no more a developer's nightmare with ReSharper 5.

Why Aren't All My WinForm Controls and Forms Localizing?

Greetings all,
I'm trying to localize a .NET/C# project. I'm using string resource files and setting the "Localizable" property on all my forms to 'True'. The assembly culture is empty. The resx/resource files are successfully passed through Lingobit, resgen, and al.
When running the localized executables, some of my forms are not localized (ones in which I know the Localizable flag is set) while others are. There are even a few forms which are localized but a button or two isn't. I cannot tell any difference between the non-localized forms/controls with the localized ones.
Anyone have an idea what I might be missing? Thanks!

When you open the form in Visual Studio, if you change the Language property of the Form to the language you are localizing to, does the same problem exist there? Could it be possible that the non-localized forms/buttons still have the English text set even in the localized resources?

Yeah, I'd go with Andy on this and be suspicious of the contents of the resource files. We dabbled with localisation for a time, and encountered a number of issues, but this certainly wasn't one of them.
If that isn't it, then how are you testing your app? If you haven't tried this already I'd suggest firing up a set of VMs with foreign language versions of Windows installed (rather than just changing the language settings on your machine) and seeing if that makes any difference.

Okay, I figured it out. You guys were correct. We were not generating the translated resx files correctly from Lingobit. Some of the files would get translated while others had the English text still in the resx.
Thanks for your help!
EDIT: Just to expand upon this, we specifically were messing up the al.exe command which takes the binary .resources file and creates a satellite assembly adding it to the executable's manifest. In the /embed command, you have to bind the resources file to a namespace. Our top-level name spaces were mapped correctly, but we weren't binding to sub-level namespaces on all of the resource files.