Localization based on namespace
-
Hey guys recently I've been wondering about which would be the best way to implement a localization system based on namespaces. Let's say that for some reason I wanted to use a few source code files in many different projects, and for some other reason I don't want or cannot build a DLL out of them (which of course would be the "right" way to do this). Let's also say I need to localize that code in a few different languages. Also, the files I'll be sharing all use the same namespace. Now, the standard localization technique in Visual Studio works real fine and is very easy to maintain and update within the IDE, but it's all tied to the project's main assembly name. So, while I could just copy and paste over all the necessary localization strings for my shared files each time, and prefix all the relevant localized string names with my namespace ID, that would be clumsy and error prone. I was wondering if there was a way to build up some DLL or resource files and just bundle them up with the source code to be shared. I've been considering for example building up a few resource files within the IDE, using file names that include the namespace and the different culture IDs, and then implementing a custom resource manager using
ResXResourceReaderor something similar. Any other ideas ? :) P.S.: we are talking C# here.In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
-
Hey guys recently I've been wondering about which would be the best way to implement a localization system based on namespaces. Let's say that for some reason I wanted to use a few source code files in many different projects, and for some other reason I don't want or cannot build a DLL out of them (which of course would be the "right" way to do this). Let's also say I need to localize that code in a few different languages. Also, the files I'll be sharing all use the same namespace. Now, the standard localization technique in Visual Studio works real fine and is very easy to maintain and update within the IDE, but it's all tied to the project's main assembly name. So, while I could just copy and paste over all the necessary localization strings for my shared files each time, and prefix all the relevant localized string names with my namespace ID, that would be clumsy and error prone. I was wondering if there was a way to build up some DLL or resource files and just bundle them up with the source code to be shared. I've been considering for example building up a few resource files within the IDE, using file names that include the namespace and the different culture IDs, and then implementing a custom resource manager using
ResXResourceReaderor something similar. Any other ideas ? :) P.S.: we are talking C# here.In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
You are trying a really weird way of code re-use. In my opinion, you have to update your tool which you use for your current code sharing such that it can handle the resources also.
-
Hey guys recently I've been wondering about which would be the best way to implement a localization system based on namespaces. Let's say that for some reason I wanted to use a few source code files in many different projects, and for some other reason I don't want or cannot build a DLL out of them (which of course would be the "right" way to do this). Let's also say I need to localize that code in a few different languages. Also, the files I'll be sharing all use the same namespace. Now, the standard localization technique in Visual Studio works real fine and is very easy to maintain and update within the IDE, but it's all tied to the project's main assembly name. So, while I could just copy and paste over all the necessary localization strings for my shared files each time, and prefix all the relevant localized string names with my namespace ID, that would be clumsy and error prone. I was wondering if there was a way to build up some DLL or resource files and just bundle them up with the source code to be shared. I've been considering for example building up a few resource files within the IDE, using file names that include the namespace and the different culture IDs, and then implementing a custom resource manager using
ResXResourceReaderor something similar. Any other ideas ? :) P.S.: we are talking C# here.In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
Moreno Airoldi wrote:
but it's all tied to the project's main assembly name
How so? You can add a *.res file to a project, and name it as you like. You can then add resources there. You could name it after your class, having a *.cs and .res file for it (and optionally a .xaml/.cs.Designer file).
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Hey guys recently I've been wondering about which would be the best way to implement a localization system based on namespaces. Let's say that for some reason I wanted to use a few source code files in many different projects, and for some other reason I don't want or cannot build a DLL out of them (which of course would be the "right" way to do this). Let's also say I need to localize that code in a few different languages. Also, the files I'll be sharing all use the same namespace. Now, the standard localization technique in Visual Studio works real fine and is very easy to maintain and update within the IDE, but it's all tied to the project's main assembly name. So, while I could just copy and paste over all the necessary localization strings for my shared files each time, and prefix all the relevant localized string names with my namespace ID, that would be clumsy and error prone. I was wondering if there was a way to build up some DLL or resource files and just bundle them up with the source code to be shared. I've been considering for example building up a few resource files within the IDE, using file names that include the namespace and the different culture IDs, and then implementing a custom resource manager using
ResXResourceReaderor something similar. Any other ideas ? :) P.S.: we are talking C# here.In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
Moreno Airoldi wrote:
but it's all tied to the project's main assembly name
I kind of doubt that. I would suspect that although that is one way to use it there are others.
Moreno Airoldi wrote:
Let's also say I need to localize that code in a few different languages.
You don't localize code - you localize applications. There will be differences otherwise little point in having different applications. If you have common blocks that need to be translated then keep them in their own files and then, if necessary, write a tool that merges them in the build process as a pre-build step.
-
Moreno Airoldi wrote:
but it's all tied to the project's main assembly name
I kind of doubt that. I would suspect that although that is one way to use it there are others.
Moreno Airoldi wrote:
Let's also say I need to localize that code in a few different languages.
You don't localize code - you localize applications. There will be differences otherwise little point in having different applications. If you have common blocks that need to be translated then keep them in their own files and then, if necessary, write a tool that merges them in the build process as a pre-build step.
-
You are trying a really weird way of code re-use. In my opinion, you have to update your tool which you use for your current code sharing such that it can handle the resources also.
I'm not discussing the way to re-use code here. As I said, I'm perfectly aware the "right" way to do this is by using DLLs to share code. I'll take your answer as "I don't think what you propose can/should be done". :)
In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
-
Moreno Airoldi wrote:
but it's all tied to the project's main assembly name
How so? You can add a *.res file to a project, and name it as you like. You can then add resources there. You could name it after your class, having a *.cs and .res file for it (and optionally a .xaml/.cs.Designer file).
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Of course you can andd a .res file to a project and name it as you like. What I'm asking is a whole different thing. I'll try to be more specific. :) In a Visual Studio solution, the standard way to add localization is by creating a set of resource files named "Localization" plus the culture ID. So for example you will have "localization.resx", "Localization.it.resx", "Localization.de.resx" for your default language, Italian and German, and so on. Then, you can use a
ResourceManagerto get your localized strings:ResourceManager LocalizationResourceManager = new ResourceManager(Assembly.GetExecutingAssembly().GetName().Name + ".Localization", Assembly.GetExecutingAssembly());
...
string LocalizedString = LocalizationResourceManager.GetString(ResourceName, Culture);Now this is perfectly fine and of course does not stop me from doing what I need to, even if I share code by copying over source files. But as you see clearly in the
ResourceManagerconstructor, it's tied to the assembly name, simply because the resource file is compiled together with the project's main assembly. I was simply wondering if there was a way to somehow change this so that the DLLs compiled from the resource files will be tied to a different namespace. What I'm asking basically is: can I have VS compile a resource file in a project and not automatically assign the resources to the project's main namespace ? Hope it's more clear now. :) EDIT: Just to be even more clear - nothing stops me from naming my resource files "Localization_MYNAMESPACE" or something similar, that's actually what I would most likely do (haven't actually tried this but I'm pretty sure there is no reason why it should not work). I'm just wondering if there are different approaches, and found it quite interesting to investigate how one can configure the way the compiler acts on resource files.In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
-
Moreno Airoldi wrote:
but it's all tied to the project's main assembly name
I kind of doubt that. I would suspect that although that is one way to use it there are others.
Moreno Airoldi wrote:
Let's also say I need to localize that code in a few different languages.
You don't localize code - you localize applications. There will be differences otherwise little point in having different applications. If you have common blocks that need to be translated then keep them in their own files and then, if necessary, write a tool that merges them in the build process as a pre-build step.
jschell wrote:
write a tool that merges them in the build process as a pre-build step
You kind of put the finger on exactly what I was thinking of. :thumbsup: However, it's most likely not worth it to develop a specific tool for that, since it would still be easier to manage the localized resources semi-manually instead of having to keep the tool up to date and so on. :)
In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson