Hi Leo,
» Question: Is normal the the 'stable' version (not the 'trad' version), also makes a 'locale' folder by default? (because if the user wants to edit the language, he can use the yellow button to extract the translation files). I see no point on extracting the files by default on that version, since that's the function of the 'yellow button'. If the 'locale' folder is found, then the program would use it, but if not, then it could use the 'internal' embedded files. What do you opine?...
The "locale" folder is necessary for the operation of this location system under Windows.
The language files must be extracted (or exist on hfs.exe folder).
The "locale" folder and especially the files that come with it are only created if they don't already exist in the hfs.exe folder; it's the option I've chosen to "open" for users the ability to edit / translate / add as they see fit.
Incidentally, if it can prevent me from maintaining several versions of the program ... it's a little time saved.
Previous releases rewrote the files / folders each time HFS was launched.
It was a good choice to be always up to date ... but a little limiting for other uses, like translation.
The "yellow button", therefore, is not only for translators, but it also allows to have the translation files "up to date".
I'm thinking of a way to update the files more easily (without rewriting them systematically), for now I only find ideas that are complicated (for me) to implement.
» Small idea: On the 'stable' version, the 'yellow button' could show a 'yes/no' warning message (similar to the SSL button), and if the user answer 'yes', then all the translation files are extracted. It could be a message like: "Do you want to enable the 'translator mode'?. If you answer yes, then you could translate the locale files using 'Poedit' (which you can download from poedit.net). If you already had a 'locale' folder, clicking on 'yes' will overwrite those files. Do you really want to extract the files?...". It's much nicer that way, and more informative.
Mmmm .... I put a "hint" on the button, it seemed enough ... I'll think about your suggestion.
» Another very, very small detail found > Steps to reproduce it:
Set language to English, then press the yellow button. This extracts the locale files (that's OK), but then all the program sets the text to French (but still showing 'English' on the language selection menu), and that's wrong. But if the user restarts the program, the English selection is remembered (that's OK), and everything is back to normal again. I don't know if there is a solution for this or not. Anyway, is not important.
This is because "locale Windows" is not set to English on your system; the program does not find the language that corresponds to the locale Windows ... it put in the language of the source code (my fake French de-accented), not the true French language of the /fr/default.po file.
So you have to manually change/choose the language, or, restart the program.
The ability to choose another language is an additional comfort that I implemented, the "classic" operation, normally, is the use of the default language of the user (Windows OS), if this language exists in the translation files.
If the source code were in English, your test would have seemed have worked, but your interpretation would have been wrong.Take the test with the "trad" version (which includes Spanish files) ... normally the language is fixed on the correct locale language.
You can also put the "es folder" in "locale" folder of the "stable" version (- it works -).
For the correct displayed "flag", I will look at what I can do.
With "captions" of this size, you will be able to put all the HFS user manual on one line. 
Yes, I know... 
(but all that free space can now be used, and not to worry about not having space to translate) 
It was just a joke ... I know that ... My first post on this forum was about a French translated HFS rejetto's release (translated with ResHack
), which I was putting online.
Olivier