My main concern and ask is that language support not be dependent on a compiled DLL which is accessible to a very limited FEW individuals who will bother to download Visual Studio or whatever excessively complicated and outdated development environment. But that the common man be able to make and edit translations from the comfort and familiarity of a PLAIN TEXT (.txt) file in Notepad. DLL is out of reach.
It most definitely will be a DLL and it will require a resource editor to edit. It should only be accessible to those who have some technical knowledge, understand resources and resource editors, undertand the importance of maintaining sprintf() parameters such as %s %d etc. in strings, and so on.
The format of the resources in mIRC can affect how it works. No one should simply change the resources on a whim. I haven't looked into it yet but it may even be possible that this could open up security issues once it becomes a feature. Someone could potentially create a custom resource file that they have changed in order to create an exploit. This is one of the reasons why I searched for code that parses resources at a low level (which is something I would have rather avoided because it is beyond the standard Windows API and involves custom code that might break in future) in order to compare and validate external resources against internal resources, eg. check that strings contain the correct _sprintf() % parameters to mitigate crashes. This does make me wonder whether all language DLLs should be approved, digitally signed, and distributed only through the mIRC website.
Apart from that, what you are suggesting would require implementing custom low-level routines to recreate resources from text, something which is complex and so rarely done that it would be a project in itself. It was hard enough finding code that low-level reads resources correctly in order to perform validation checks. Your suggestion would add a whole other layer of complexity - loading the text file, parsing it for resources, recreating resources from it on demand, and so on. Thanks but I am going to stick to using the standard Windows APIs :-)
