Localization - market possibilities vs. custom tool
-
Hi all, again I wan't to come up with a rather theoretical question. This time regarding localization of a winforms project. I read some articles on the topic and checked whats available on the market but I am not really satisfied with what I have found. My project consists of a main-frame app that loads plugins (mainly Forms), displays them and handles the communication of the plugins. I found several tools that handle resource file localization. While I think that this will work in normal winform apps I am pretty sure that this will result in duplicate translations (Imagine a Save-Button label - this will be needed in nearly every plugin so the developer of a plugin will have to deal with this in the plugin on his/her own). I also found database related solutions that I like a little better than the resource file solution. Unfortunately those solutions look pretty "fat" and will maybe trouble me with their licences. So I thought about it a little while and here is what I came up with: I thought about having a central class that should handle the translations for me globally. The corresponding DLL will be given to the plugin developers too, so they can implement it within their plugins. I want to send every string through a static function that accepts the string and reads the UICulture in the background. It should then check if the string is already in the database, translates and returns if so, or creates "placeholder entries" and retruns the default value (the passed string). The Placeholder entries can then be read by a little app that visualizes the missing translations, allowing a transslator to go through them and translate whats missing. This way the "save" translation will not be duplicated and administered in a single place. Additionally the mainFrame can extend it's languages without having to deal with the plugin resources. The drawback for now is that the plugin developer will not be able (so far) to submit his/her translations together with the plugin, but I do not think that this is really necessary. I also haven't thought heavily about images, but there will be a way. So what do you think? Is this a screwed up idea? What tools do you use for such requirements? Is it even necessary to think about duplicate translations? I am looking foreward to hear your thoughts about this, any input is kindly appreciated cheers and have a great day Andy
-
Hi all, again I wan't to come up with a rather theoretical question. This time regarding localization of a winforms project. I read some articles on the topic and checked whats available on the market but I am not really satisfied with what I have found. My project consists of a main-frame app that loads plugins (mainly Forms), displays them and handles the communication of the plugins. I found several tools that handle resource file localization. While I think that this will work in normal winform apps I am pretty sure that this will result in duplicate translations (Imagine a Save-Button label - this will be needed in nearly every plugin so the developer of a plugin will have to deal with this in the plugin on his/her own). I also found database related solutions that I like a little better than the resource file solution. Unfortunately those solutions look pretty "fat" and will maybe trouble me with their licences. So I thought about it a little while and here is what I came up with: I thought about having a central class that should handle the translations for me globally. The corresponding DLL will be given to the plugin developers too, so they can implement it within their plugins. I want to send every string through a static function that accepts the string and reads the UICulture in the background. It should then check if the string is already in the database, translates and returns if so, or creates "placeholder entries" and retruns the default value (the passed string). The Placeholder entries can then be read by a little app that visualizes the missing translations, allowing a transslator to go through them and translate whats missing. This way the "save" translation will not be duplicated and administered in a single place. Additionally the mainFrame can extend it's languages without having to deal with the plugin resources. The drawback for now is that the plugin developer will not be able (so far) to submit his/her translations together with the plugin, but I do not think that this is really necessary. I also haven't thought heavily about images, but there will be a way. So what do you think? Is this a screwed up idea? What tools do you use for such requirements? Is it even necessary to think about duplicate translations? I am looking foreward to hear your thoughts about this, any input is kindly appreciated cheers and have a great day Andy
Thanks for moving this to the appropriate forum. :thumbsup: Cheers!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
-
Hi all, again I wan't to come up with a rather theoretical question. This time regarding localization of a winforms project. I read some articles on the topic and checked whats available on the market but I am not really satisfied with what I have found. My project consists of a main-frame app that loads plugins (mainly Forms), displays them and handles the communication of the plugins. I found several tools that handle resource file localization. While I think that this will work in normal winform apps I am pretty sure that this will result in duplicate translations (Imagine a Save-Button label - this will be needed in nearly every plugin so the developer of a plugin will have to deal with this in the plugin on his/her own). I also found database related solutions that I like a little better than the resource file solution. Unfortunately those solutions look pretty "fat" and will maybe trouble me with their licences. So I thought about it a little while and here is what I came up with: I thought about having a central class that should handle the translations for me globally. The corresponding DLL will be given to the plugin developers too, so they can implement it within their plugins. I want to send every string through a static function that accepts the string and reads the UICulture in the background. It should then check if the string is already in the database, translates and returns if so, or creates "placeholder entries" and retruns the default value (the passed string). The Placeholder entries can then be read by a little app that visualizes the missing translations, allowing a transslator to go through them and translate whats missing. This way the "save" translation will not be duplicated and administered in a single place. Additionally the mainFrame can extend it's languages without having to deal with the plugin resources. The drawback for now is that the plugin developer will not be able (so far) to submit his/her translations together with the plugin, but I do not think that this is really necessary. I also haven't thought heavily about images, but there will be a way. So what do you think? Is this a screwed up idea? What tools do you use for such requirements? Is it even necessary to think about duplicate translations? I am looking foreward to hear your thoughts about this, any input is kindly appreciated cheers and have a great day Andy
hoernchenmeister wrote:
So what do you think? Is this a screwed up idea?
Yes. That's the kind of idea that gave us Dutch and German exception-messages in .NET. It means that the context will be determined during translation, not during design - and that might give some very strange effects.
hoernchenmeister wrote:
Is it even necessary to think about duplicate translations?
I don't see the problem with the redundancy. Is it consuming a lot of space that it's an issue here? Take in account that I (as a Dutch user) probably wouldn't be interested in having the Arabic language-pack on my harddisk. The only "problem" is that the word "Save" has to be translated twice, as you suggest. Once in Application A, once in Application B. Perhaps you could share those resources over both projects.
hoernchenmeister wrote:
What tools do you use for such requirements?
Did this twice; once using my own classes, indeed with a string-lookup, similar like you would HtmlEncode and decode. Once using the VS-IDE[^], which was easier than I expected.
Bastard Programmer from Hell :suss:
-
Thanks for moving this to the appropriate forum. :thumbsup: Cheers!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
You are wellcome... thanks for pointing it out ;) cheers from Munich Andy
-
hoernchenmeister wrote:
So what do you think? Is this a screwed up idea?
Yes. That's the kind of idea that gave us Dutch and German exception-messages in .NET. It means that the context will be determined during translation, not during design - and that might give some very strange effects.
hoernchenmeister wrote:
Is it even necessary to think about duplicate translations?
I don't see the problem with the redundancy. Is it consuming a lot of space that it's an issue here? Take in account that I (as a Dutch user) probably wouldn't be interested in having the Arabic language-pack on my harddisk. The only "problem" is that the word "Save" has to be translated twice, as you suggest. Once in Application A, once in Application B. Perhaps you could share those resources over both projects.
hoernchenmeister wrote:
What tools do you use for such requirements?
Did this twice; once using my own classes, indeed with a string-lookup, similar like you would HtmlEncode and decode. Once using the VS-IDE[^], which was easier than I expected.
Bastard Programmer from Hell :suss:
Thanks a lot for your honest contribution, it is very much appreciated. I understand your points so far and will take them into concern. The main reason for thinking about this problem in the first place is the plugin-mechanism. The MainFrame does not know what languages it should support, neither does the developer of the plugin... Normally a bunch of dlls is copied into the appropriate directory to make the MainFrame pick it up. So I thought that translation should be up to the MainFrame which leads me into the belive that a custom, database related tool should do the job. So if I have five plugins all using a save button, I would need 5 translations for exactly the same thing... thas where my concern about dulicate translations came into play... Also thanks a lot for mentioning the VS-IDE approach, I'll go digg into this :) cheers Andy
-
Thanks a lot for your honest contribution, it is very much appreciated. I understand your points so far and will take them into concern. The main reason for thinking about this problem in the first place is the plugin-mechanism. The MainFrame does not know what languages it should support, neither does the developer of the plugin... Normally a bunch of dlls is copied into the appropriate directory to make the MainFrame pick it up. So I thought that translation should be up to the MainFrame which leads me into the belive that a custom, database related tool should do the job. So if I have five plugins all using a save button, I would need 5 translations for exactly the same thing... thas where my concern about dulicate translations came into play... Also thanks a lot for mentioning the VS-IDE approach, I'll go digg into this :) cheers Andy
hoernchenmeister wrote:
The MainFrame does not know what languages it should support, neither does the developer of the plugin...
They don't need to know. Windows knows what culture the user is using, and both can "ask" Windows.
hoernchenmeister wrote:
So if I have five plugins all using a save button, I would need 5 translations for exactly the same thing...
Yes/no. You could opt to put the shared resources in an external library, and share that among the projects. That way you'd need to localize the resources only once. Like putting the "OK" and "Cancel" button in their own assembly, and reference that from multiple forms/projects. You're welcome, and good luck :)
Bastard Programmer from Hell :suss:
-
hoernchenmeister wrote:
The MainFrame does not know what languages it should support, neither does the developer of the plugin...
They don't need to know. Windows knows what culture the user is using, and both can "ask" Windows.
hoernchenmeister wrote:
So if I have five plugins all using a save button, I would need 5 translations for exactly the same thing...
Yes/no. You could opt to put the shared resources in an external library, and share that among the projects. That way you'd need to localize the resources only once. Like putting the "OK" and "Cancel" button in their own assembly, and reference that from multiple forms/projects. You're welcome, and good luck :)
Bastard Programmer from Hell :suss:
Hi Eddy Vluggen, thanks a lot for the clarification. There is just one thing that I maybe missexplained:
Eddy Vluggen wrote:
They don't need to know. Windows knows what culture the user is using, and both can "ask" Windows.
This is totally correct, but I was actually referring to the language the customer wants the application to run with. I do not know wether they want a dutch, german, english or whatever language, neither does the plugin developer know, so it has to be possible to adjust it after deployment. Anyway, this doen't make an actual difference :)
Eddy Vluggen wrote:
You could opt to put the shared resources in an external library, and share that among the projects. That way you'd need to localize the resources only once.
I like this idea and honestly I already use such an approach for sharing image resources over multiple projects. Thanks Eddy for sharing your ideas/knowledge, I appreciate this very much!!! Have a great day and best regards Andy
-
Hi Eddy Vluggen, thanks a lot for the clarification. There is just one thing that I maybe missexplained:
Eddy Vluggen wrote:
They don't need to know. Windows knows what culture the user is using, and both can "ask" Windows.
This is totally correct, but I was actually referring to the language the customer wants the application to run with. I do not know wether they want a dutch, german, english or whatever language, neither does the plugin developer know, so it has to be possible to adjust it after deployment. Anyway, this doen't make an actual difference :)
Eddy Vluggen wrote:
You could opt to put the shared resources in an external library, and share that among the projects. That way you'd need to localize the resources only once.
I like this idea and honestly I already use such an approach for sharing image resources over multiple projects. Thanks Eddy for sharing your ideas/knowledge, I appreciate this very much!!! Have a great day and best regards Andy
-
Hi all, again I wan't to come up with a rather theoretical question. This time regarding localization of a winforms project. I read some articles on the topic and checked whats available on the market but I am not really satisfied with what I have found. My project consists of a main-frame app that loads plugins (mainly Forms), displays them and handles the communication of the plugins. I found several tools that handle resource file localization. While I think that this will work in normal winform apps I am pretty sure that this will result in duplicate translations (Imagine a Save-Button label - this will be needed in nearly every plugin so the developer of a plugin will have to deal with this in the plugin on his/her own). I also found database related solutions that I like a little better than the resource file solution. Unfortunately those solutions look pretty "fat" and will maybe trouble me with their licences. So I thought about it a little while and here is what I came up with: I thought about having a central class that should handle the translations for me globally. The corresponding DLL will be given to the plugin developers too, so they can implement it within their plugins. I want to send every string through a static function that accepts the string and reads the UICulture in the background. It should then check if the string is already in the database, translates and returns if so, or creates "placeholder entries" and retruns the default value (the passed string). The Placeholder entries can then be read by a little app that visualizes the missing translations, allowing a transslator to go through them and translate whats missing. This way the "save" translation will not be duplicated and administered in a single place. Additionally the mainFrame can extend it's languages without having to deal with the plugin resources. The drawback for now is that the plugin developer will not be able (so far) to submit his/her translations together with the plugin, but I do not think that this is really necessary. I also haven't thought heavily about images, but there will be a way. So what do you think? Is this a screwed up idea? What tools do you use for such requirements? Is it even necessary to think about duplicate translations? I am looking foreward to hear your thoughts about this, any input is kindly appreciated cheers and have a great day Andy
I did the localization for our applications some 2 years ago. Texts shown on forms/lables/buttons were the minor point. We do have far more messages shown in MessageBoxes (or other strings changed at runtime), and it was a long work to find them all in the source code. I created my own tools for reading the source code line by line, looking for literal strings, display them, manually decide whether the string has to be localized or not (e.g. our logging is not localized - that would be too much extra work), and replace it with an appropriate call to the ResourceManager and adding the string to the appropriate resource file. And yes, the OK button's text shows up perhaps a hundred times in the resource files... If I remember correctly, with (non-managed) C++ it was possible to use Windows resources for such common texts like "OK" "Cancel" "File" "Edit" etc. But I do not know how to do that with .Net. By the way, I added an entry to the app.config file such that the user can decide to use a different locale than Windows. Here in Germany, some of our customers use an English Windows on their servers, and with that little trick our applications can be set to German. And another point to consider: a new thread inherits the language from Windows, not from the process which started the thread. The language must be set here again. The .Net resource files can be used by specialized translation offices. Their tools discover such multiple entries like the "OK". Their prices here in Germany are typically about 1 Euro per entry for most Western languages.
-
I did the localization for our applications some 2 years ago. Texts shown on forms/lables/buttons were the minor point. We do have far more messages shown in MessageBoxes (or other strings changed at runtime), and it was a long work to find them all in the source code. I created my own tools for reading the source code line by line, looking for literal strings, display them, manually decide whether the string has to be localized or not (e.g. our logging is not localized - that would be too much extra work), and replace it with an appropriate call to the ResourceManager and adding the string to the appropriate resource file. And yes, the OK button's text shows up perhaps a hundred times in the resource files... If I remember correctly, with (non-managed) C++ it was possible to use Windows resources for such common texts like "OK" "Cancel" "File" "Edit" etc. But I do not know how to do that with .Net. By the way, I added an entry to the app.config file such that the user can decide to use a different locale than Windows. Here in Germany, some of our customers use an English Windows on their servers, and with that little trick our applications can be set to German. And another point to consider: a new thread inherits the language from Windows, not from the process which started the thread. The language must be set here again. The .Net resource files can be used by specialized translation offices. Their tools discover such multiple entries like the "OK". Their prices here in Germany are typically about 1 Euro per entry for most Western languages.
Hi Bernhard, thanks a lot for sharing your experiences., it was very helpful. Good you mentioned the threadding issue, that completely fell under the table :) In my application the language is set when logging in by selecting the required language. The language is then stored as readonly in a static class, pretty much the same as using a config file. I also haven't heared about the translation offices you have mentioned. While I am pretty sure our management will use internal resources for translating this is still a good thing to know :) Thanks a lot and have a great day, Viele Grüße aus München Andy