[Wish] Keep previous menu (language) files when upgrading...

[alm]

Hi, When upgrading to a new version of Total Commander it always just replaces the files in Language folder with new files. So all customizations that have been made are lost, unless one makes a backup... But that's easily forgotten...

So, I suggest that a backup is made of the (changed) files that are in the Language folder before overwriting them during installation, for example in a backup folder below it. Another option would be to place customized menu files in a different folder and if it does not exist the ones in Language folder will be used... But then when default menu files are changed it should be automatically placed in the customized folder.

Please give your opinion below.

[Hacker]

Hello alm,
You can also give the files the read-only attribute, AFAIK TC shouldn't overwrite them then. Or, you can simply give your custom file a new name and use that, TC will not overwrite it.

HTH
Roman

[Lefteous]

What about a cascading approach? The Language dir in TC dir would be updated just like before. But in addition TC would also search in a directory "UserLanguage" which is always the directory below the directory containing the current main settings file.
The language files in this directory would always overrule the files placed in Language. Menu files having a different name would be added to the list.

It's not a perfect solution but would solve the mentioned problem.

You can already use customized files in a customized folder but I guess such a cascading approach is a step further.

[fenix_productions]

I have voted for first option.

I think it's not really needed because menus are in most of the cases static and TC is updated once per few months only.

Other thing is: no backup of its setting for months? Seriously, why? Personally if I am creating something which takes more than couple of minutes I must have backup copy of it.

It is also possible to have your own names for almost any configuration file (no exceptions for menus) so why does anybody create his own menu with default name? I understand "cascading approach" but is it truly needed? If someone decides to have separate folder than why not separate names? Time spent on it is almost the same as renaming defaults.

Making backup of all settings could be nice but I don't consider it as must have.

[alm]

Hello alm,
You can also give the files the read-only attribute, AFAIK TC shouldn't overwrite them then. Or, you can simply give your custom file a new name and use that, TC will not overwrite it.

I didn't know that (about giving a new name), still finding options after so many years of usage. I will give it a try, but still it's good to know atleast that the files are being overwritten for when you don't rename them.

Edit: Well I tried and it works (ofcourse), but the problem is that when you switch between languages (because you might be testing something for this forum and want to write about it with the English terms) then you have to select it again. It does not remember the setting, so it has to be made specifically. Or is there an option for that in the config? So that you can say: Wcmd_Dut_menu_Choice=Wcmd_Custom.mnu for instance?

[fenix_productions]

2alm
I think you have to have MNU file named the same as LNG one to be chosen automatically (i.e. WCMD_ENG_TEST.LNG and WCMD_ENG_TEST.MNU pair).

[alm]

2fenix_productions

Yes, that works. But when something changes in TC then you're still working with the old, possible incorrect, LNG file. And what about the .inc file, it also needs to match with the name I guess?

Perhaps it is an idea to work with version numbers or so in each file, so that TC knows about it and can mention the file is an old version and must possibly be upgraded. This could be mentioned during the upgrade for example.

But, I have to say I don't know how often these files change (internally that is).

[petermad]

2alm

The files should be named after this template.

wcmd_xxxxx_yyy.lng

where xxxxx is whatever you want, and yyy is the language code. For example wcmd_alm_eng.lng

In that way plugins etc (that are written correctly) will use the same language as yyy in the .lng file name.

That also applies to .chm or .hlp files - if your language file is called for example wcmd_alm_eng.lng, then TC will look for (in the language directory) and use wcmd_eng.chm or wcmd_eng.hlp as the help file (in that order).

A complete set of language/menu specific files contains up till 4 files:

wcmd_xxx_yyy.lng
wcmd_xxx_yyy.mnu
wcmd_xxx_yyy.inc
wcmd_xxx_yyy.ini

Additionally you can have these two (customized) help files (in your language folder):

wcmd_yyy.chm
wcmd_yyy.hlp

which will work with the files mentioned above (or any other wxmd_*yyy.lng file). If both help files exist, then the .chm file will be used.

Neither of these 6 files will be overwritten at TC updates, and will be used after an update.


You can find the official English files in my Extended menu (see signature) or here: http://madsenworld.dk/tcmd/wcmd_eng_750.zip


I HIGHLY recommend that you do NOT use the names suggested by fenix_productions:

(i.e. WCMD_ENG_TEST.LNG and WCMD_ENG_TEST.MNU pair).

but rather use WCMD_TEST_ENG.LNG and WCMD_TEST_ENG.MNU

[Clo]

2petermad

Hi Peter !

…but rather uses WCMD_TEST_ENG.LNG and WCMD_TEST_ENG.MNU

• I agree strongly, this is the right style where the 3-character language ID must be just before the dot, here I use :

WCMD_clo_FRA.INC
wcmd_clo_fra.lng
Wcmd_clo_fra.mnu

- Or else, a lot of problems in sight, especially with some plug-ins…

 KR
Claude
Clo

[StatusQuo]

Support++ for

What about a cascading approach? The Language dir in TC dir would be updated just like before. But in addition TC would also search in a directory "UserLanguage" which is always the directory below the directory containing the current main settings file.
The language files in this directory would always overrule the files placed in Language.

This way updating TC would add new strings automatically, without resetting user-changed strings (if the "UserLanguage" files contain only changed strings instead of all).