 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Internationalization / February 2005Best Practies question
Hi everyone, and thank you in advance for sharing your insights on my questions. I have an application with many assemblies that contain strings that need to be localizable. My question is: where do I put the resources containing the strings? When I was a youngster back in the olden days ;), (i.e. pre DotNet), I would have a single large resource file, indexed by numeric string IDs. All the string IDs would be globally available and all code would call into some module to get the strings. This had the advantage that a localizer would only need to go to one place to translate. In DotNet, things seem to be different. For example, when I set my forms to localizable, all relevant string and layout information is put into a resource file that is local to the project (of course, there isn't probably a reasonable alternative for the forms package). It seems that my choices are: (1) Put strings for an assembly into a resource for that exists in that assembly. Advantages: a. Developers can add, modify and delete strings locally without having to have access to a file shared across projects. b. Names need not be unique in the entire application namespace. c. This matches the way the .NET Forms package works when Localizable is set to true. Disadvantages: a. When we re-factor our solution, changing which methods, and source files are in each project, we will have to specifically identify each string that needs to be moved to the new assembly. This seems like a disaster in the making. b. Localizers have to localize many different assemblies. (2) Put all strings into a separate assembly that all other assemblies reference using a static accessor class and string IDs that are unique across the projects. Advantages: a. Resource access becomes a non-issue when refactoring. b. Localizers have a single resource (well, except for the .NET Forms resources) to work against. Disadvantages: a. Developers have to access a shared file accross projects to work with any strings. This seems like it could be bottleneck in the development environment. b. Localizers have many resources to access for localization. c. String IDs must be globally unique. (3) Put strings into local resources (for the assembly) but if the string cannot be found there, try finding the strings in the separate, globally accessible Resources project. Advantages: a. Developers could work locally to their project, then, at their leisure, move the string resources into the globally accessible Resources project. I really don't know what the best approach is here. Any advice you could impart will be warmly appreciated. Tom Clement Apptero.Inc Hi Tom, As you probably have noticed, the VS design experiences is mainly focused on an approach such as number 1. And most of the localization projects I work on use the approach number 1, mainly I think because it's easier for development. In VS 2005, the resource editor will help identify duplicate resource ids - although this won't be available for a while. I like the approach for number 2 because it should help reduce translation be reducing the number of duplicate resources. I think it really depends on how big your project is and cost the trade off between ease of development and ease of localization. Either way, I think you can mitigate the drawbacks of both solutions by using a good localization tool which has a translation memory. Option 3 sounds a little complicated, and if you plan to programmatically add resource fallback between assemblies, it could get costly performance wise. Hope this helps, Marin > Hi everyone, and thank you in advance for sharing your insights on my > questions. [quoted text clipped - 57 lines] > Tom Clement > Apptero.Inc Thank you so much for your responses Marin. They are very helpful, and give me the confidence to move forward that I was looking for. Tom Clement Apptero, Inc. > Hi Tom, As you probably have noticed, the VS design experiences is mainly > focused on an approach such as number 1. And most of the localization [quoted text clipped - 89 lines] >> Tom Clement >> Apptero.Inc Tom/ Marin, First, I'd like to thank you for the discussion posted here. This is exactly in line with the questions I had. I still have a couple of more queries. Please help to answer these: Background: I would like to divide my applications' resources into two categories: 1. Static resources - all the images - bmps/ jpegs etc. (As far as my application needs go, they don't have to change). Technically, I would like this to be a dll. 2. Dynamic resources - includes strings and more importantly, forms - 'cause the layout has to be changed depending on the string sizes of the controls etc... Again, technically, I would like it to be another dll. The reason why I want to do this: My application has several exes (UIs) and dlls (that the exes use). I would want to centralize all the resources that these exes use. If I were to achieve this, I will have to figure out: 1. How to segregate the forms and their code behinds?? How to link a particular .cs file as a codebehind file for a particular form?? If I could achieve this, I would end up having a resource dll that contains the forms and the strings too. 2. How to write my exes (the resoucemanager sections) to load this dll and use the appropriate forms and strings, based on the locale?? Any help regarding this will be highly appreciated. Thanks, Radha > Thank you so much for your responses Marin. They are very helpful, and give > me the confidence to move forward that I was looking for. [quoted text clipped - 95 lines] > >> Tom Clement > >> Apptero.Inc Hi Radha, The answer depends a little bit on whether it's a web or windows application. It sounds like you're writing a Windows application, so I will answer for that. Windows Forms have a localizable property which can be set in the properties window. Setting that property will automatically separate your resources from your code file for the form. For resources which aren't based on the form (like error messages, etc), you'll need to code these manually, by creating a ResourceManager which loads the strings from a manually created .resx file. You can organize your project so that all your localizable forms and strings are contained in a single assembly. Your .exe will load the .dll and the ResourceManager will do the work to load the resources from the dependent assembly and its satellite assemblies. You can find several examples of how to create localized applications using the ResourceManager in the msdn library (msdn.microsoft.com) by searching on "ResourceManager" or "Localization". As for images, you can use the same form based mechanism described above if you add your image to a picturebox or image control. The image will be serialized out in a base 64 encoding to the .resx file, and can then be loaded with the form based resourcemanager. If your images are associated with multiple forms, you can use two methods. One is to link them into a .resx file using the ResxFileRef class (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html /frlrfsystemresourcesresxfilerefclasstopic.asp ), and then load them using the ResourceManager, like you would load any other resource. The other way would be to embed them as an unmanaged resource in your assembly then read the image in using GetManifestResourceStream (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/h tml/vbtskCodeExampleRetrievingImageThatIsEmbeddedResource.asp ). The drawback to this method is you are not using the ResourceManager and so you don't be culture dependent resource loading. You would have to write this functionality youreself, which could get quite complicated depending on the number of languages you have and or might add later on. If you want culture dependent resource loading, I recommend using the ResxFileRef method or the form based localization method. I hope this answers your question, but if not, please post your additional questions. Marin Millar [MSFT]
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.