Multiligual and End-User defined labels...?
-
Hello, I am in the process of writing a "shrink wrapped" software product and I would like: 1. the end user to be able to define all of the labels/menu captions/error messages at runtime. (eg. a customer may want to change the label 'Client' to 'Customer' etc. That way, 2 English speaking customers can have different captions to suit their own terminology. And 3 Portugese customers can do something similar and so on...) 2. the application to use locale-based dates/number formats. 3. the resource strings to be kept in xml files - not compiled into satellite dll's Has anyone seen an article/sample app on the web anywhere that explains how to do this? I basically want the end-user to be able to define their own terminolgy (if required) for any label or string that gets displayed to them but at the same be multi-culturally aware. Thank you, Daffrey
-
Hello, I am in the process of writing a "shrink wrapped" software product and I would like: 1. the end user to be able to define all of the labels/menu captions/error messages at runtime. (eg. a customer may want to change the label 'Client' to 'Customer' etc. That way, 2 English speaking customers can have different captions to suit their own terminology. And 3 Portugese customers can do something similar and so on...) 2. the application to use locale-based dates/number formats. 3. the resource strings to be kept in xml files - not compiled into satellite dll's Has anyone seen an article/sample app on the web anywhere that explains how to do this? I basically want the end-user to be able to define their own terminolgy (if required) for any label or string that gets displayed to them but at the same be multi-culturally aware. Thank you, Daffrey
Hi, I can't help you for all your points. But for point 2 about using the locale-based dates/number formats. You can use Globalization and Localization. The
System.Globalizationnamespace provides you with a number of classes that allow you to retrieve, make use and change the culture that your application code i susing to format dates, numbers and strings. The culture is set cia the Regional options. Localization means that you make use of these settings within your application. Every culture is defined by a 2 letter lowercase language code followed by an optional 2 letter uppercase Country code (f.e.nl-BErepresents the Belgium Dutch regional setting. You can ask the info using the globalization namespace. Then you can use the CultureInfo class.Me.Label1.Text = CultureInfo.CurrentCulture.Name Me.Label2.Text = CultureInfo.CurrentCulture.DisplayNameFor the other items, you should create an kind of admin screen, where your users can define their word. Save this to your XML file and read this XML file. I prefer to define by meyself the possibilities. Create languege textfile with everything translated. Use then resgen.exe to create your resourcefiles of each text file. You can also work with XML-based resource files. For this create your project, right click to add a new item and choose anAssembly Resource File. Add one for every language support. These files are XML files. Your job is to store the resources (name/value) in the data element. You can do this directly or using a dataset. Again use resgen. As you can see, all of them are using regen to compile theses resX files into binary resource files. Only the first option isn't doing this. Hopes this helps you a bit. -
Hello, I am in the process of writing a "shrink wrapped" software product and I would like: 1. the end user to be able to define all of the labels/menu captions/error messages at runtime. (eg. a customer may want to change the label 'Client' to 'Customer' etc. That way, 2 English speaking customers can have different captions to suit their own terminology. And 3 Portugese customers can do something similar and so on...) 2. the application to use locale-based dates/number formats. 3. the resource strings to be kept in xml files - not compiled into satellite dll's Has anyone seen an article/sample app on the web anywhere that explains how to do this? I basically want the end-user to be able to define their own terminolgy (if required) for any label or string that gets displayed to them but at the same be multi-culturally aware. Thank you, Daffrey
You should start by reading Developing World-Ready Applications[^] in the .NET Framework SDK. You should also understand the difference between globalization and localization, the former being how dates, times, and numbers are formatted, while the latter is how text is read according to the current language. Respectively, each is represented by
CultureInfo.CurrentCultureandCultureInfo.CurrentUICulture, which could easily be different. Developing a world-ready application using VS.NET is very easy. Develop your user interface, then use the PropertyGrid with the entireFormselected to set "Localizable" totrue, then select the language. The neutral language is in whatever language you've developed the application (like "en-US" for U.S. English), so do not use that language. The neutral text will be compiled into resource files and embedded into your primary assembly (the assembly with the IL module(s) that is your compiled code), while any other languages are compiled into satellite assemblies. To make look-ups faster, you should define for your assembly an assembly-level attribute namedNeutralResourcesLanguageAttributEusing the locale/language in which you developed your application originally, like so:[assembly: NeutralResourcesLanguage("en-US")]
This will save a separate look-up for satellite assemblies when that particular language is the current locale and language. This is especially important if you're deploying your managed code via touchless deployment over the web. I architected a solution using this concept, though I didn't use VS.NET because it's rather inefficient for enterprise applications. This will be greatly improved in Visual Studio 2005 using the
ComponentResourceManagerinstead of theResourceManagerat design-time. Both classes have been defined since .NET 1.0, but the designer - up until VS 2005 - has been using theResourceManagerwhich can bloat your codebase by localizing every property attributed with theLocalizableAttribute, which is quite a few. Even after compiling, either you or your clients can use the -
Hi, I can't help you for all your points. But for point 2 about using the locale-based dates/number formats. You can use Globalization and Localization. The
System.Globalizationnamespace provides you with a number of classes that allow you to retrieve, make use and change the culture that your application code i susing to format dates, numbers and strings. The culture is set cia the Regional options. Localization means that you make use of these settings within your application. Every culture is defined by a 2 letter lowercase language code followed by an optional 2 letter uppercase Country code (f.e.nl-BErepresents the Belgium Dutch regional setting. You can ask the info using the globalization namespace. Then you can use the CultureInfo class.Me.Label1.Text = CultureInfo.CurrentCulture.Name Me.Label2.Text = CultureInfo.CurrentCulture.DisplayNameFor the other items, you should create an kind of admin screen, where your users can define their word. Save this to your XML file and read this XML file. I prefer to define by meyself the possibilities. Create languege textfile with everything translated. Use then resgen.exe to create your resourcefiles of each text file. You can also work with XML-based resource files. For this create your project, right click to add a new item and choose anAssembly Resource File. Add one for every language support. These files are XML files. Your job is to store the resources (name/value) in the data element. You can do this directly or using a dataset. Again use resgen. As you can see, all of them are using regen to compile theses resX files into binary resource files. Only the first option isn't doing this. Hopes this helps you a bit.Thank you for your reply. I was originally thinking that I had to put every string into the "custom terminology" xml file, but I guess you are right. I probably only need to put in 30 or so words that end-users can configure based on their own terminology. Some people might call a job a task, some might call it an issue and others may call it a fix. I think I'll need to write template-based error messages. So an error message may look like: "You can't delete the <>. Permission Denied." And then I'll just grab the <> string from the "custom terminology" xml file... Do you have any thoughts on whether it is better to put cultural resource strings for each language into 1 xml file? I haven't written a multi-lingual app yet, but I would imagine it would be easier to send 1 xml file per language to a translater rather than 1 form resource file that .NET normally uses.... Thank you for your reply. Daffrey
-
You should start by reading Developing World-Ready Applications[^] in the .NET Framework SDK. You should also understand the difference between globalization and localization, the former being how dates, times, and numbers are formatted, while the latter is how text is read according to the current language. Respectively, each is represented by
CultureInfo.CurrentCultureandCultureInfo.CurrentUICulture, which could easily be different. Developing a world-ready application using VS.NET is very easy. Develop your user interface, then use the PropertyGrid with the entireFormselected to set "Localizable" totrue, then select the language. The neutral language is in whatever language you've developed the application (like "en-US" for U.S. English), so do not use that language. The neutral text will be compiled into resource files and embedded into your primary assembly (the assembly with the IL module(s) that is your compiled code), while any other languages are compiled into satellite assemblies. To make look-ups faster, you should define for your assembly an assembly-level attribute namedNeutralResourcesLanguageAttributEusing the locale/language in which you developed your application originally, like so:[assembly: NeutralResourcesLanguage("en-US")]
This will save a separate look-up for satellite assemblies when that particular language is the current locale and language. This is especially important if you're deploying your managed code via touchless deployment over the web. I architected a solution using this concept, though I didn't use VS.NET because it's rather inefficient for enterprise applications. This will be greatly improved in Visual Studio 2005 using the
ComponentResourceManagerinstead of theResourceManagerat design-time. Both classes have been defined since .NET 1.0, but the designer - up until VS 2005 - has been using theResourceManagerwhich can bloat your codebase by localizing every property attributed with theLocalizableAttribute, which is quite a few. Even after compiling, either you or your clients can use theHi Heath, Thank you very much for replying to my post, I really appreciate it. Do you have any thoughts on whether it is better to put cultural resource strings for each language into 1 xml file? I haven't written a multi-lingual app yet, but I would imagine it would be easier to send 1 xml file per language to a translater rather than 1 form resource file that .NET normally uses.... However if this was done then it would be more work and a custom resource load routine would be required for each form. The normal .NET way is to set the form localizable property to true and then select the language and go off and enter all of the labels for that language... To me that seems problematic because: 1. The same caption might be used on more than one form. If one developer has to update all of the "Name" captions on every form, then the chances of them missing one or more could be high for an application with many forms. 2. How does that work in practice for a translater? Does the translater need a copy of VS.NET installed and they go through each and every form in the designer? Or do you set the default language for each form. And if your application has 50 forms, then you send 50 resource files to a translater? Did you face any of these issues when you did your multi-ligual application? Cheers, Daffrey
-
Hi Heath, Thank you very much for replying to my post, I really appreciate it. Do you have any thoughts on whether it is better to put cultural resource strings for each language into 1 xml file? I haven't written a multi-lingual app yet, but I would imagine it would be easier to send 1 xml file per language to a translater rather than 1 form resource file that .NET normally uses.... However if this was done then it would be more work and a custom resource load routine would be required for each form. The normal .NET way is to set the form localizable property to true and then select the language and go off and enter all of the labels for that language... To me that seems problematic because: 1. The same caption might be used on more than one form. If one developer has to update all of the "Name" captions on every form, then the chances of them missing one or more could be high for an application with many forms. 2. How does that work in practice for a translater? Does the translater need a copy of VS.NET installed and they go through each and every form in the designer? Or do you set the default language for each form. And if your application has 50 forms, then you send 50 resource files to a translater? Did you face any of these issues when you did your multi-ligual application? Cheers, Daffrey
Normally you should have one resource file for each language. So when having three languages, you should have 3 resource files. For your other question, I think (but I'm not sure) you can use the same caption for more than 1 form. So this should be no problem. For the translator, you don't have to send 50 resource files but only the number of your languages. In these resource files everything is kept together for that language and as far as I know, your translator doesn't need a copy of VS.Net. As long as you give him the not compiled resource files, because these are XML files.
-
Hi Heath, Thank you very much for replying to my post, I really appreciate it. Do you have any thoughts on whether it is better to put cultural resource strings for each language into 1 xml file? I haven't written a multi-lingual app yet, but I would imagine it would be easier to send 1 xml file per language to a translater rather than 1 form resource file that .NET normally uses.... However if this was done then it would be more work and a custom resource load routine would be required for each form. The normal .NET way is to set the form localizable property to true and then select the language and go off and enter all of the labels for that language... To me that seems problematic because: 1. The same caption might be used on more than one form. If one developer has to update all of the "Name" captions on every form, then the chances of them missing one or more could be high for an application with many forms. 2. How does that work in practice for a translater? Does the translater need a copy of VS.NET installed and they go through each and every form in the designer? Or do you set the default language for each form. And if your application has 50 forms, then you send 50 resource files to a translater? Did you face any of these issues when you did your multi-ligual application? Cheers, Daffrey
What you send to the translators doesn't necessarily have to be what you compile into resource files, so do whatever makes it easier. Since they are XML files (and you can also use plain text files using key=value pairs, but then you can only localize strings and not any Type that is attrbuted with a specific
TypeConverter), you can do just about whatever you want. When you compile the resource files, however, they must be compiled into separate satellite assemblies. These satellite assemblies are identified by a specific culture. Take a fully-qualified assembly name:System, culture=neutral, version=1.0.5000.0, publicKeyToken=b77a5c561934e089
Notice the neutral? Primary assemblies (those assemblies that contain the IL module(s)) must always be neutral (but can contain your neutral language, which is why I mentioned using the assembly-level attribute
NeutralResourcesLanguageAttributefor faster look-ups). Satellite assemblies replace "neutral" with whatever locale/language for which they were compiled. Both theResourceManagerand theComponentResourceManager(which extends the former) look-up resources in satellite assemblies using this information. You could create your own resource manager classes to look for resources in a single assembly, but there's so many problems with that. It's inflexible and bloats the size of your assemblies when N-1..3 languages are necessary for any particular user (1..3 denotes cases when have locale-specific resources, which fallback to language-specific resources, which fallback to neutral resources). You also loose the ability to integrate with visual designers, unless you plan on implementing your own plugins for each designer instead of making the designers work for you (which is how the ComponentModel currently works). Be sure to read-up on the classes I've mentioned as well as the links I gave you. It explains a lot of information. Just going through an example of localizing a simple sample application and examining the code really helps, too. Create a new project, throw some controls on the form, assign some text, then localize it using the steps I've mentioned. Examine the source, compile the project, and examine the output. You can learn a lot from such an example. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft