Externalization of strings for localisation

[Tirs]

Hello! This is an "ideas exchange" rather than a question -I'm explaining "how I do it" and I would like to know if someone came with a better idea.

After switching to version 5, I have noticed that I can have "included" files with code (the ones added via the "Tools-->Components" option).

I want to take advantage of this to write my programs in several languages, externalizing the strings much like it's usually done in Java with .properties and in many Linux programs with .po files.

What I'm doing is to put a subroutine called loadLang inside an additional code file (added via "Tools --> Components"). This subroutine contains just variable assignments, like:

lang_Welcome="Welcome to my program!"
lang_SureQuit="Are you sure you want to quit?"

...and then call this subroutine from App_Start. Of course I need to previously define all the language variables inside SUB Globals.

It's not a very elegant solution, especially because it only works at compilation time (to create executables for two different languages I have to compile for language 1, remove the additional file for language 1, add the file for language 2 instead, and compile again). That's why I throw this question to the forum:

Any better idea?

Thanks in advance!

_____
|!rs

[Cableguy]

Hi
Iin the old forum I used a diferent solution for your Idea!
Here it is, since i couldn't find it int the old forum salvage....

[Tirs]

Nice idea! And then you can store the selected language in some small file or configuration parameter, and next time the user will automaticaly get the same language selected last time. Just let's add some button or menu option to allow to change it!

Hum... still, this option will leave some unneeded textfiles lying around. For a more compact solution, we can use the additional files "my style" (with variable assignment inside functions) and then select the language "your style", but instead of getting the name of the file to load, we just get a parameter to be passed to a "wrapper" function:

SUB loadLang(lang)
    IF lang='en' THEN loadLangEn
    IF lang='pt' THEN loadLangPt
    IF lang='es' THEN loadLangEs
   'etc... (fortunately there won't be that many, most of the times)
END SUB

The wrapper function would be inside the main source file, and each loadLangXX would be in its own additional file.

Why not just one big loadLang function directly loading the required language depending on the parameter instead of calling wrapped functions? Easy: because, in order to localise correctly, each language-dependent code must be in a separate file. You cannot put (for example) Portuguese and Spanish in the same file, because managing both languages simultaneously (for example, sending them for the translators to update something) is a pain. Even worse, imagine the nasty things a Western translator can accidentally do to a Japanese file, especially if he never installed the double-byte support...

Another suggestion: How about reading the default language from the registry? Now we have a nice library for that. Unfortunately, the contents of the key HKEY_LOCAL_MACHINE --> nls are quite cryptic

Well, obrigado for your idea! For sure I will use it.
_____
|!rs