|
Can't program without VS.NET? You should be careful. If you use the multilingual designer interface in VS.NET by setting the designer's "Localizable" property to true and setting a new "Language" property value, you're in for a big surprise (and a much larger application). The designer will automatically add every property of the controls in your form that contain LocalizableAttribute(true) to your source file and ResX files, whether you use (or plan to use) them or not. Your executable will be much larger because of the (possibly) extraneous property setters in the code and the large amount of values (especially base64-encoded binary property values like ImageLists) in your ResX files.
Best way around this - don't use VS.NET's designer for your localization. Design your form initially in VS.NET and then handle your own localization by instantiating a new ResourceManager instance and keeping a refernece to it in your class to use in later methods - or use a singleton resource class like is commonly done in the .NET BCL (which I use for ease and for centralized maintainence). If the ResourceManager you use is not instantiated in InitializeComponent(), it will break your designer and you can no longer use VS.NET to design your forms without it complaining (perhaps this is a bug on their part), but you don't need the designer to write .NET apps anyway, right?
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Thanks for warning us!
"Don't judge each day by the harvest you reap, but by the seeds you plant." -- Robert Louis Stevenson
FLUID UI Toolkit
|
|
|
|
|
It's kinda funny: I just got done hosting a meeting to my coworkers and employees about string resources in ResX files (both to serve as common string banks and to support future localization) and was explaining to them the dangers of using the designer-supported localization properties. Then I saw this poll.
I started supporting localization a long time back and only needed to try this approach once. Once I saw that my assembly increased in size by a factor of 2, I started doing it Microsoft's way (in all the .NET BCL assemblies) - just having a singleton class dolling-out string resources (and any other types that can be serialized to strings). Just dig into any one of the BCL assemblies and look for the SR class.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Did I miss something, or nobody mentioned CListCtrl issue yet ?
i'm only pointer to myself
|
|
|
|
|
|
I vote that we should just put a permanent CListCtrl as an option. It would just save us the hassle of actually typing it in.;)
|
|
|
|
|
I chose the CInternationalizationCtrl option myself. 
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Okay, this is off-topic, but I gotta say...
Your signature is hilarious! I was in stitches for quite some time! 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
*How* do you do it? For instance, do you have a separate EXE for English, German, French, etc.? Do you use resource DLLs and load them at run-time? Or do you use external data files (e.g., XML, text files) for strings and other transalted data?
We tend to go with method 3 (external text/XML files.) We tried resource DLLs but that became very cumbersome. Any time the UI changed, some poor soul would ahve to check out x number of RC files and make the change. And one would always be forgotten, and your app would crash or not compile in, say, German.
We now have all our strings separated from the dialogs. WE have one set of dialogs that works for all languages. This works well 99% of the time, the only issues is that you have to size the dialogs carefully so that they look good in all languages.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
We have multiple languages in our .RC files. We have an in-house tool that we give our translators for editing the files. The tool ensures that the translator doesn't modify things they shouldn't, as well as validating the translation. It also ensures that each language is kept up to date in comparison to the English and language-neutral resources.
This approach works well for us, since we have a small number of languages (five at last count). In the future, we plan to have the option of connecting our translation tool to one or more dictionaries to help ensure the consistency of the translation across applications and product lines.
Software Zen: delete this;
|
|
|
|
|
I am using an externall DLL.
To avoid crashes when upgrading, each application knows with which version of the resource DLL it is compatible. For instance when I release version 3.0.0 I tell that it should be compatible with DLL versions 3.0.x. If 3.0.1 is released with a new resources then I tell that it is compatible with versions 3.0.X where X>=1. If no resources are updated then 3.0.1 is stil compatible with 3.0.x whatever x is. Before loading a resource DLL I read its version and check if is compatible with the executable. If not then I switch back to English which is included in every installation so I am sure that it exists at least one compatible resource DLL.
For the upgrade issue, I have a modified version of Smart Translator (available on codeproject) that makes the iterative process very easy. I have always been looking for someone who would like to take over the project and make it available to the community but without a chance. In the current state it is OK for internal usage and with my translators but not quite ready to be released anywhere else 
Now some questions: what tool do you use to create the text files with all your strings? How do you dynamically update all the controls and menus and so on... You probably have to add a line in all InitDialog and after all LoadMenu?
Regards,
Nicolas
|
|
|
|
|
Nicolas Bonamy wrote:
Now some questions: what tool do you use to create the text files with all your strings? How do you dynamically update all the controls and menus and so on... You probably have to add a line in all InitDialog and after all LoadMenu?
The tool is called Notepad. Althoug you can use Word or what-not, but then you have to be careful of code-page conversions and such. For instance, if a Japanese translator sends us a Word file, you save the Word file as text using the right charset (shift-JIS) and then put the strings in the file.
Since they are Ini files, we do also have some utilities to merge two files, etc. They are in progress.
As for dialogs, we have* a class that we derive all our dialogs from that handles this autmoatically. We put in "string tokens" (e.g., @SomeMessageString) in the RC file for any control that needs transalted text. The base dialog class then looks up that text at run-time from whatever language is loaded, and replaces it on the OnInitDialog handler.
We don't yet have controls that dynamically size themselves based on their content... but that would be cool, so it's on our wish list. 
* Most new stuff is written without dialogs and RC files per se - we are generating them at runtime using XML, and so the string tokens are in the XML in that case.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
We're doing this with XML, just for fun, our original effort was simple formatted text files.
For the UI stuff, we've developed UI classes that allow end-user/installer customization, so the screens can be re-arranged however fits the locale conventions. It also makes things nice, since controls can be removed from the screens, so for example if you don't need half of the fields in the customer record, just drag them off the screen in the designer. Depending on the app, layouts can be centrally controlled for a given customer, or each user can have their own layout.
|
|
|
|
|
It's the way of the future, man!
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Actually, there's much easier ways than what's posted below, but it depends on the minimum platform you can support (Win2K and up):
Similar to how .NET apps use satellite assemblies (containing the default - or neutral - language in the EXE or DLL itself), Win32 can do the same. Ever heard of the MUI (Multilingual UI) packs for Win2K and WinXP (probably Win2K3, too)?
Basically, you make sure that all your strings and what-not are in RC files. Then you make a resource-only DLL with a copy of that RC file, only localized for whatever language you want. Then you either put that DLL in %WINDIR%\MUI\FALLBACK\(Locale ID such as 0407 for de-DE) as MyFile.MyExt.mui, or in your app directory (or whatever path it checks for files) as MyFile.MyExt.(Locale ID).mui. The executable loader checks for these files automatically and uses them depending on the current language pack installed (or default on the systme).
Using this approach, however, doesn't let you switch languages, although - since these .mui files are nothing more than executables - you could probably use the same tricks as previous apps by using LoadLibrary and your various LoadResource-type APIs.
There is documentation for this buried in MSDN. The only references I could find in my local library was with WinCE .NET, but I know I've seen them for Win2K+ (they're just hard to find).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Should make things slightly more efficient for NT, 2000, XP etc as its what the OS uses inside, when speaking to the OS Api's.
Doing things in ASCII means an extra translation step on behalf of the OS.
Its just funny that people will psend ages tweaking for speed here and there and then ignore something like this, that at the same time leaves the code to be used from multiple langauages and character sets.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table.
Shameless Plug - Distributed Database Transactions in .NET using COM+
|
|
|
|
|
I agree. The only disadvantage to Unicode is that 95/98/Me doesn't support it natively. However Unicows.dll has helped out a lot.. although I will still find the occasional API that is broken or not implemented.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
I've consistently worked to make my apps translation-friendly for the past 8 years or so.
But none of the companies that I have worked for have expressed the slightest interest in internationalizing the programs.
In the app I'm working on now; we're using Unicode. Marketing has decreed that the app itself will not be translated, but that the documentation will. (At one point they considered translating only the tooltips, nothing else. Boy, that would have worked well!)
|
|
|
|
|
This may be true for an app written in the united States, where internationalization means writing an app that gets marketed to the whole world (east coast and west coast). But, if you plan to market to Europe, or Asia, or potentially Africa, then it really is an issue. Have you ever noticed that when you buy an electrical appliance, if it is from the united states, all the instructions are in English. If you buy a European one, the instruction manual is written in a dozen languages. This is a successful strategy.
Here in Australia we are in a similar boat to the united states, we don't tend to produce in multiple languages, altho we are more aware of other language needs, especially Indonesian and Japanese.
Good luck
Buena Suerte
Noroc
Being in a minority of one, doesn't make you insane
(George Orwell , I think)
|
|
|
|
|
The next poll should be: What other languages do you want to see The Code Project in?
That should keep Chris busy... 
Us English speakers are becoming a minority on the net.
We can do internationlisation, but don't build it in by default. We do bespoke products though, not shrinkwrap so any future internationlisation (bugger that is hard to type) work we can charge to the client. 99% of the time though the cost puts them off.
Recently I have learnt to put strings into a resource file though. Having had to go through a thousand pages changing error/warning/information messages was not fun.
regards,
Paul Watson
Bluegrass
South Africa
Miszou wrote:
I have read the entire internet. on how boring his day was.
Crikey! ain't life grand?
|
|
|
|
|
I think Chinese would be easy... just convert everything into random skwiggly hieroglphics ... well it'll look chinese to me!
|
|
|
|
|
Paul Watson wrote:
Recently I have learnt to put strings into a resource file though. Having had to go through a thousand pages changing error/warning/information messages was not fun.
Having a few 1000 strings in a monolithic resource files isn't my idea of "joy" either.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
sighist | Agile Programming | doxygen
|
|
|
|
|
Tis better than having them scattered amongst those 1000 files. Means you can edit them in one place and have multiple versions for different copies of the project etc.
How do you do it?
regards,
Paul Watson
Bluegrass
South Africa
Miszou wrote:
I have read the entire internet. on how boring his day was.
Crikey! ain't life grand?
|
|
|
|
|
Moving all String const defs to the top of the file, and praying that my clever scheme I plot works out once I have to internationalize.
I agree that the one place is better - but that the one place is unstructured is a real pain.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
sighist | Agile Programming | doxygen
|
|
|
|
|
peterchen wrote:
Having a few 1000 strings in a monolithic resource files isn't my idea of "joy" either.
I agree - we use text/INI files for our strings. The INI style is nice because you can group related strings into sections. We could even split them over multiple files, but we haven't really had a use for that yet. It is nice to have the strings separated from everything else - we can just send them to translations and there you go.
Resource DLLs are evil. There are better ways of doing things.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
