Resource Strings

[asmfan]

I would like to hear your opinion on using Strings in Resources. When and Why it is more useful to use strings in resources than strings in < .data > or < .const > sections? Is this question of localization of an application?
Thanks.

[Tedd]

Supporting different native languages would be my first idea :wink

[James Ladd]

When you want to change the strings without recompiling the application.
When you want to load all the strings into a map or look them up as needed.

[P1]

It is simply an option for storing data, with some language usage benefits thrown in.  With that said, there are pros and cons to it, as with any decision a programmer needs to make about data and it's use.

Regards,  P1  :8)

[asmfan]

P1, that's why i started this - because i would like to hear there "pros and cons" about using resource strings...
Regards,
asmfan.

[stanhebben]

I never found any benefit of using the resource strings. If you want to translate the program, you have to rebulid it anyway.

If I want to add internationalization in my programs, I write a small text file parser and a simple string localization system. Then if you want to translate the program, you translate the string file. (and no need to rebuild the program - so anyone can do it)

Stan.

[P1]

I believe Stan is mostly right here.

Most big time developers, have language versions, even M$, who came up with it in the first place.

It might still be usefull for smaller programs to be multi-lingual.  But it needs to be coded unicode throughout.  Plus having translators to generate the different strings and documentation needed.

Regards,  P1  :8)

[asmfan]

Actually it's much convenient and easier to use unicode strings in resources because as i remember "L" specifyer makes string be unicode.
Also can we overwrite localized resources over the basic main ones? Or can we write RES files directly to EXE over old ones not using linker?
I need more pros:) i see only cons;)

[hutch--]

Igor,

I have very rarely ever used them becuase there are few advantages in doing so and the data is stored as unicode which increases the file size. About the only factor is being able to edit the resources with a resource editor but tha is not a common usage these days. For internationalisation issues, seperate files are a much better proposition and a lot easier to manage.

[asmfan]

Thank all of you guys for trying to help me to find out strong and weak sides of using resources.

[KSS]

Mr. Hutch,
When used lang-files this slow down application speed?
Maybe for their speed I liked res-strings...
And code to manage lang-files has its own size, so it increases App.exe size. (Or not?)
(I use only UNICODE, I want SPEED... I want peace all over the world :) )

[hutch--]

KSS,

If speed is a problem, load the language file at startup into memory and then it will be fast enough. There is another option which make multilingual applications a lot easier to manage, make a DLL that contains the specifics of each language then load the DLL for the preferred language at startup.

[KSS]

How I think (at this time) the best way are support many method for App-translators:

• Support lang-file
• Support manager res-strings in own exe (App-translators can add new lang to my exe!!!)
• Support manager res-DLLs

At this way user can decide what methods may be used.

[stanhebben]

Why don't you go langfile-only then? It's the most convenient method for end-users. Who wants to use a dll if he can do it with a textfile?

I have a simple language file parser which you could use. Accepts only unicode atm.

Stan

[KSS]

Stan, (I like speed)
I think that method with text file is more slow than with DLL. (But I not test this!)

I have a simple language file parser which you could use. Accepts only unicode atm.

I want look to it! (For speed-test, compare DLL and lang-file)