Develop Reference

Alternative localization with extension methods

I am about to start a localization project for my employer. It concerns a pre-existing project with many windows forms and an established code base, programmed in C# and ASP.NET. I have done research into how to localize an application in visual studio and found resources.
While these are an adequate solution to the problem, I am not entirely happy with the down sides of using resources. This is to say, it has a rather large footprint, requiring changes in each of the form files. Furthermore, the resource files are only editable from within Visual Studio. I would prefer enabling external translators without programming knowledge to do the translation.
So I came up with an alternative solution:
Build a static localization utility class with an extension method on String:
public static String Localize(this String s)
The utility class loads localization strings from file on startup. When the program needs a string somewhere, it is called as
"foo".Localize();
And the program would use the string itself as the key in the table to find the translation.
It seems a safe and effective solution, and I'm happy with the small footprint that it leaves on the existing codebase.
Basically I want to ask:
Are there downsides to my solution that I've missed?
Which file formats for the localization data should I look into (I've already encountered the .po file format)?
Is it a good enough reason to deviate from the resource files solution?
Any advice and/or considerations you may have will be appreciated.

You are trying to reinvent the wheel that MS invented long ago. You can use plenty of tools available for resources or even write your own Resources provider.
Some tools available: What tools are available for adding Localization to an ASP.NET project?
If you want to use a database for translators: Data Driven Resource provider from Rick Strahl

Are there downsides to my solution that I've missed?
I can point out some, what about the texts in the aspx files. Are you going to make your extension method available to them as well? That would be tough I guess.
e.g. <asp:Label Text="Title"> - how are you going to translate that?
Further, some of your claims are not entirely true.
the resource files are only editable from within Visual Studio
They are xml files , so you can use any editor to edit them or write a custom utility to do that.

Are there downsides to my solution that I've missed?
The standard resource files go beyond changing the text.
You might need to resize certain elements to fit the new text (if you don't use the existing layout management mechanism). And for some languages you will need to change the fonts/fonts sizes (think Chinese, Japanese, Korean) or alignment (think right-to-left languages like Arabic and Hebrew).
Also, translating standard files means that using an editor that is aware of the format one can see the dialog "as is", so it gives more context than stand-alone strings, which results in better translation quality.

Recommended way of mixing .NET and file context menus

I have a C# WPF application. It is designed to work on any and all files. Right now, it accepts 'input' by means of commandline arguments as well as drag and drop to a control in its main window. However, ideally I want people to rightclick any file/multiple files and have them be able to simply click 'Awesomify this'. (That's not the real name. :P)
I've got some experience with context menus from years ago, so all in all, it isn't too current. As such, I am looking for advice on the best way to implement this feature. All examples following are based on what I see using W7.
Generally, I understand there's basically two ways: pure registry, and registry + COM object.
The former has a certain elegance to it, since I don't want anything special; however, from what I can tell by documentation, these menu items always clump up at the same place as the primary file actions (Open, Preview, Print). However, I'd like my item to appear lower on the totem pole. If I look at my personal contextmenu for a random file, I'd want it to be at the 'spot' UltraEdit and Malwarebytes Anti-Malware stick themselves. Sticking my entry under HKCR\*\shell\AwesomeTest gets me my item, but no matter what I pick for the Position, I get two different extremes I don't like: Top puts it above the default item, Bottom puts it right above Properties. I want it inbetween Share with and Restore previous versions, which where most general-purpose tools seem to find a home.
Some more registry digging seems to point out the apps I wish to mimic use the COM object route. And that would bring me (I believe) back to native code. Which would then bring with it all the hells of 32-bit and 64-bit development I am trying to avoid.
Is there anything I am missing? Likewise, other than the MSDN page regarding context menu handlers which I have looked through and found to be rather unhelpful (as it seems to skim a lot without diving into the more precise details regarding placement and such), are there any good sources regarding this problem?
Another thing I've not been able to figure out just yet is how I can properly add IDropTarget support to my .NET WPF application yet, so information on that would also be welcome.
If anyone has an instant answer, well that would be nice, but I am mainly trying to find the right path to take without wasting several days on the paths that are dead-ends. Which there seem to be a lot of. :(

IContextMenu::QueryContextMenu(). Shell extensions are in the domain of C++, very unpleasant in C#, .NET 4.0 required. A sample project that uses it is here.

Is there a C# auto formatter that I can use to define custom rules for formatting?

My group has a source analysis tool that enforces certain styles that we have to comply with. I can't change it, and some of the rules are just a pain. One example is that all properties have to come before methods, and all constructors must come before properties. It seems silly to me that I have to take time to do something to the program when to the compiler it is the same. I would like some thing that is a plugin to VS that will let me do things like this automatically. Also, it would be nice to have it automatically put using's inside the namespace block.

You have different possibilities, depending on what exactly you want to do:
Resharper: There is a auto-format function which formats the source code of a single file or all files in the project / solution depending on your selected rules. So you set the settings for braces, naming, whitespaces, operators, lamdas, ... For more information see here. Resharper also supports settings a source- code file for all solutions or a shared settings file which is the same for all persons in the team.
FxCop: I havn't ever used this at work, but it's also a great tool an you can also select the rules which you want to enforce.

Unless they bake it into VS2010, Resharper has the auto formatting capabilities you're probably looking for. CodeSmith probably has it too, I just haven't used it...

There are some formatting options built into VS.
Goto Tools-->Options-->Text Editor-->C#-->Formatting.
They don't include every scenario, but might get you close.

Resharper - what a fantastic tool. I don't think I could manage without it. It must be the ultimate productivity tool for Visual Studio. Re-factoring, code analysis, code formatting, code completion - it has the lot.

How to quickly organize functions in source code (c#) to order by alphabetical order?

I'm doing some class clean to organize the functions in cs file in alphabetical order. I'm using Visual Studio 2008.
When writing them, I just put them arbitrarily, but it now looks quite messy.
Is there some easy way to organize them automatically?
Better to have a tool because there're quite a lot files to clean up.

Why bother organizing in alpha order?
The IDE provides a drop down list in order for you to use if you wish to access them in that manner.
Instead the source file should contain them in a meaningful order (what is meaningful is rather subjective) either by the specifics of their tasks or by some sensible convention if nothing else exists (such as by visibility, or placing properties together).
Auto layout rules are a nightmare for source repositories since they put in needless mass movements that frustrate your ability to identify real change, as such they should be avoided unless the rules comply with one of the following:
They never change and you can apply it from the beginning of your project
They change very rarely and changing will affect at most a single line movement (like bracketing structure)
They change rarely and the effect is simply on white space within a line
If the answer is at all beyond 'rarely' you don't want to use it full stop, efficient browsing of historical changes is more useful.

Have you tried Regionerate?

In Regionerate:
Open the schemas from: C:\Program Files\Regionerate
Select cluster by name
Select remove regions
Your methods, fields, etc. code will be ordered alphabetically.

although my answer is pretty late, but have you given a thought about an awesome tool called as ReSharper. I bet once you get used to it, you will love it. Makes coding so much more easier and cleaner.

How do I best localize an entire app to many different languages?

I'm using Visual Studio (2005 and up). I am looking into trying out making an application where the user can change language for all menues, input formats and such. How would I go on doing this, as I suppose that there is some complete feature within .Net that can help me with this?
I need to take the following into account (and fill me in if I miss some obvious stuff)
Strings (menues, texts)
Input data (parsing floats, dates, etc..)
Should be easy to add support for another language

I'm not an expert with .NET by any means but Localization is never just as simple as "swapping out String values" or "changing date formats". There is much more to be taken into consideration such as layout, proper text placement.
Take Chinese for example. The way you read is top to bottom not left to right. If properly localized the app should take that into account.
http://msdn.microsoft.com/en-us/library/y99d1cd3(VS.80).aspx seems to be a good start though if you're dealing with Windows Forms.

The classic recipe is: design the app with no native language but a localization facility, and develop an initialization into one language (e.g., English). So you build the app and localize it into English every night; without the localization step it would not be usable. Do that well, and the resources for the initial sample localization can be replaced with those for any other language. Take into account non-roman scripts from the beginning. It's much cleaner to have a no-language app that always requires localization rather than a language-specific app that needs to have its native language subtracted and a replacement added.

For strings you should just separate your strings from your code (having an XML/DLL that will transform string IDs to real strings is one way to go). However you do need to make sure that you are supporting double byte characters for some languages (this is relevant if you use C/C++).
For input data what you want is to have different locale's. In Java this is relatively easy, and if you use C# it probably is quite easy also. In C/C++ I don't really know. The basic idea is that the input parsers should be different based on the locale selected at that time. So each field (textfield, textbox, etc.) must have an abstract parser that is then implemented by a different class depending on the locale (right to left, double byte, etc.).
Check the Java implementation for details on how they did it. It is quite functional.

You definitely need to be using the .NET ResourceManager and the resx file xml format, however there are a number of approaches to using this.
It really depends on what you are wanting to achieve. For me I wanted a single xml resource file (for each supported language) that could be modified by anyone. I created a helper class that loaded the global resource file into ResourceManager (once only) and I had a helper function that gives me the required resource for a given name. The only disadvantage in this approach was that I could not leverage dynamic binding of resources to properties.
I found this better and easier to manage than multiple or embedded resource files for every form. Additionally exactly the same approach can used in an ASP.NET application. I also found this approach means that outsourcing translation of resources and shipping language packs to customers much more manageable.

Microsoft's recommended approach is to use satellite assemblies, as described in Packaging and Deploying Resources. If you're using a ResourceManager to load resources, .NET will load the correct resources for the CurrentUICulture. This defaults to the user's current UI language setting in Windows.
It is possible to localize Windows Forms either through Visual Studio or an external tool, WinRes.exe. This article describes WinRes and how to use Visual Studio to localize the form.