I've noticed several posts throughout the forums (especially in feature requests) talk about the resources file and how Nick Gammon doesn't want to change it. What is this file and why not change it? Is it not like any other piece of source code?
Resources file
Posted by damccull on Mon 26 Feb 2018 08:46 PM — 6 posts, 26,849 views.
The resources are not exactly code. They are more like a database. They are publicly available (in English) here:
https://github.com/nickgammon/mushclient_resources
Example of it:
The reason I don't want to change the resources is because of the considerable effort put into internationalization of the code, starting here:
http://www.gammon.com.au/forum/?id=7953
As described in that post, the resources (menus, dialog boxes, pop-up boxes etc.) were removed from being bundled inside the MUSHclient.exe file, and moved into a separate DLL. The English version (EN.dll) ships with the client.
The idea was that if someone wanted to localize the client they could recompile the resources file, changing, for example, "Offer to save world if only &Variables have changed" to be what that would be in French ("Offrir de sauver le monde si seulement les variables ont changé" maybe?).
There is also another file (en.lua) which maps text in the C++ code to other languages. For example, the message "This field may not be blank" might be changed as follows:
This file can be used to change the text of messages and warnings internally generated by the client.
Right now, since these files are distributed with the client, but ones for the other languages are not, then if someone in (say) China wanted to make a Chinese version, they just have to do the translations in the resource file, and also en.lua. The new resource file would be CN.dll and the text file cn.lua.
When new versions of MUSHclient are released they will automatically pick up the resource file based on the current locale, so bug fixes in the client will still keep the Chinese text in menus, etc.
However if I change the resource file layout (eg. adding a new menu item) then all those other resource files would have to be changed too. Possibly the people that did them are no longer working on them.
So, for backwards consistency, I make it a rule to never change the resource file.
Since the code and the resource file are open source, you are welcome to change them yourself if you want to.
https://github.com/nickgammon/mushclient_resources
Example of it:
IDD_GLOBAL_PREFSP3 DIALOG DISCARDABLE 0, 0, 262, 201
STYLE WS_CHILD | WS_DISABLED | WS_CAPTION
CAPTION "Closing"
FONT 8, "MS Sans Serif"
BEGIN
CONTROL "Confirm before closing &World",
IDC_CONFIRM_BEFORE_CLOSING_WORLD,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,15,10,106,10
CONTROL "Offer to save world if only &Variables have changed.",
IDC_CONFIRM_BEFORE_SAVING_VARIABLES,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,15,28,176,10
CONTROL "Confirm before closing &MUSHclient",
IDC_CONFIRM_BEFORE_CLOSING_MUSHCLIENT,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,15,46,125,10
CONTROL "Offer to save MXP &debug windows",
IDC_CONFIRM_BEFORE_CLOSING_MXP_DEBUG,"Button",
BS_AUTOCHECKBOX | WS_TABSTOP,15,64,125,10
END
The reason I don't want to change the resources is because of the considerable effort put into internationalization of the code, starting here:
http://www.gammon.com.au/forum/?id=7953
As described in that post, the resources (menus, dialog boxes, pop-up boxes etc.) were removed from being bundled inside the MUSHclient.exe file, and moved into a separate DLL. The English version (EN.dll) ships with the client.
The idea was that if someone wanted to localize the client they could recompile the resources file, changing, for example, "Offer to save world if only &Variables have changed" to be what that would be in French ("Offrir de sauver le monde si seulement les variables ont changé" maybe?).
There is also another file (en.lua) which maps text in the C++ code to other languages. For example, the message "This field may not be blank" might be changed as follows:
-- DDV_validation.cpp:41
["This field may not be blank"] =
"Blank, this field may not be",
This file can be used to change the text of messages and warnings internally generated by the client.
Right now, since these files are distributed with the client, but ones for the other languages are not, then if someone in (say) China wanted to make a Chinese version, they just have to do the translations in the resource file, and also en.lua. The new resource file would be CN.dll and the text file cn.lua.
When new versions of MUSHclient are released they will automatically pick up the resource file based on the current locale, so bug fixes in the client will still keep the Chinese text in menus, etc.
However if I change the resource file layout (eg. adding a new menu item) then all those other resource files would have to be changed too. Possibly the people that did them are no longer working on them.
So, for backwards consistency, I make it a rule to never change the resource file.
Since the code and the resource file are open source, you are welcome to change them yourself if you want to.
See http://www.gammon.com.au/forum/?id=10430 for a list of options added into the client which you can change through a simple script command, but not the GUI interface.
This is a great explanation. I think it's a very interesting approach to localization.
I doubt you'd be interested in making such a change, but why not bring the actual UI components back into the main EXE, and instead of using a compiled dll file, just read a strings.xml (or similar) file for localization? The xml file would be comprised of string IDs and translations:
<strings>
<string id="world_name">World Name</string>
</strings>
In your code, parse the xml into variables (on an object, for instance) and then reference the variable instead of directly including the string.
Then the client can read the xml file and render strings in place. It would ignore any extra strings that it doesn't know about, and use everything it does. In situations where it's missing a translation, render the English default so there isn't just a missing string.
The XML would make it trivial for anyone to make language changes themselves, even if a particular xml translation stops being worked on, and would still translate most of the UI even when not 100% complete.
Lastly, what advantages does your resource file approach have over the strings.xml approach I suggested? Honestly I'm not a fantastic programmer, but I do like to learn.
I doubt you'd be interested in making such a change, but why not bring the actual UI components back into the main EXE, and instead of using a compiled dll file, just read a strings.xml (or similar) file for localization? The xml file would be comprised of string IDs and translations:
<strings>
<string id="world_name">World Name</string>
</strings>
In your code, parse the xml into variables (on an object, for instance) and then reference the variable instead of directly including the string.
Then the client can read the xml file and render strings in place. It would ignore any extra strings that it doesn't know about, and use everything it does. In situations where it's missing a translation, render the English default so there isn't just a missing string.
The XML would make it trivial for anyone to make language changes themselves, even if a particular xml translation stops being worked on, and would still translate most of the UI even when not 100% complete.
Lastly, what advantages does your resource file approach have over the strings.xml approach I suggested? Honestly I'm not a fantastic programmer, but I do like to learn.
Look at the size of the file. It would be a massive task. Also, it has a visual editor (you get that with the Visual Studio IDE). Trying to line up buttons and boxes with just numbers would be tedious to say the least.
The fact that it is separately available at least makes it possible for you to install Visual Studio (hopefully the free edition supports it, I haven't tried) and tweak the user interface to how you want it. If the changes are not too massive it should still interface with the code OK.
The fact that it is separately available at least makes it possible for you to install Visual Studio (hopefully the free edition supports it, I haven't tried) and tweak the user interface to how you want it. If the changes are not too massive it should still interface with the code OK.
Ahh...I didn't realize it gave the ability to tweak the layout and everything. How interesting. Thanks for taking the time to explain all this!