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 :sign0148:
Well, obrigado for your idea! For sure I will use it.
_____
|!rs