mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: May 2018
Posts: 221
eahm Offline OP
Fjord artisan
OP Offline
Fjord artisan
Joined: May 2018
Posts: 221
Hi Khaled, I just read the changelog of the latest beta and I am worried too many things will be added just for the languages feature and other things will eventually break when people start translating.

Shouldn't we get a stable release with all the 100% IRCv3 compatibility additions and maybe start a new let's say 8.x alpha/beta version that will add translations?

Thank you.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
I agree.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
I'm not sure how you can comment on how translation support is going to be implemented let alone how it would break things. I mean, what is the speculation founded on?


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: May 2018
Posts: 221
eahm Offline OP
Fjord artisan
OP Offline
Fjord artisan
Joined: May 2018
Posts: 221
From the official beta changelog. He's concerned too this feature may break things if I read correctly.

Last edited by eahm; 11/11/18 08:48 AM.
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
I think what you are asking for is "a new mIRC 6.35". I don't think that's a route or crutch that any of us really desire. We don't like people who use 6.35 :P (roll with the punches).

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.

If a DLL is technically necessary, then let a helper DLL read from .txt files.

Last edited by Raccoon; 11/11/18 01:40 PM. Reason: let a helper DLL

Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I agree, adding language support has turned out to be far more complicated than I expected. That said, the plan was to make gradual changes to the code in preparation for language support, so not all of the changes described in the changelog were intended to be made in this beta cycle. The "pending changes/issues" section lists some of my observations in case someone wants to make comments or suggestions:

Quote
6.In preparation for external language DLL support, hundreds of internal
changes have been made:

1) Changed the way resources such as dialogs, menus, accelerators, and
strings, are loaded. Centralized the loading routines so that a
specific language DLL can be used.
2) Added routines that parse resources at a low level in order to compare
and validate external resources against internal resources, eg.
check that strings contain the correct _sprintf() % parameters
to mitigate crashes.
3) Changed resource file to Unicode. This also required updating a custom
application, that writes to the resource file during the build process,
to read/write unicode.
4) Removed all non-printable characters from string resources and placed
them in code.
5) Removed spaces at the start and end of all resource strings, and
placed in code, to mitigate translator errors.
6) Removed other types of non-alnum characters from the start and end of
strings and placed in code.
6) Removed a number of ambiguous single word strings and changed some
partial strings into whole sentences.
7) Changed resource strings that use /command and $id in the form /%s
and $%s to use actual command/id name to improve context.

Pending changes/issues include:

1) Update all resource strings that use multiple % sprintf parameters
to use positional parameters, as parameter order can change depending
on the language. This will also require updating hundreds of sprintf
calls that load these strings to use sprintf_p.
2) Change or remove strings that do not provide enough context for
translators, where possible.
3) Add language dialog that allows selecting language DLL.
4) Find a way of not requiring a restart when a new language DLL is
selected. Due to the many different resources that are loaded/used
while mIRC is running, this does not currently seem possible and
mIRC will need a restart.
5) The scripting language uses english. It ties in with many GUI
features. This means that for non-english users there will be a
disconnect between the translated GUI and scripts.
6) Some words, such as window names, eg. "Status Window", are used
for scripting and in the GUI. These need to be separated in some
way and may require that windows, and other similar features,
have two different names - a consistent internal name and a
translatable GUI name.
7) Many words are used when saving settings to INI files. These need
to be separated from translatable resources as the INI file section
and item names need to be consistent and independent of language.
8) Some words are used by scripts/DLLs to identify windows, dialogs,
errors, etc. A method needs to be added to make these identifiable
independent of language-specific wording. Existing scripts may need
to be updated to cater for different languages.
9) All dialogs need to be redesigned to allow translators to translate
text without needing to resize/reposition dialogs/controls/etc.
10) Many server messages are parsed and rephrased by mIRC using english
words. This means that some messages will be partially translated
due to mIRC's wording and partially not translated due to using the
server message.
11) Some strings, such as Window names, eg. "Urls List" must be checked
to ensure they have a space separating two words, in exactly that
format, since this is used in many functions to extract the
Window name. Other strings may need similar checks, since the code
might assume a certain format, which will be broken if the string
is changed.

The current beta includes code changes such as adjusting string resources, some re-wording, removing some start/end characters and placing them in code, etc. For the most part, I am fairly comfortable with these changes. The beta does not include any of the code relating to loading a language DLL or low-level parsing of resources to perform checks, etc.

The next stage will involve adding positional parameters to resource strings and converting all associated sprintf()s to sprintf_p()s. This will be a slow, time-consuming process as hundreds of string/code changes will be needed that require careful checks. I am going to leave this for the next version.

For now, I am going to go back to focusing on other changes for this beta cycle and hopefully release a new version later this month or next.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
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 :-)

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Originally Posted By: Khaled
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.

I don't know if I agree that tool access necessarily denotes technical knowledge. I trust that most mIRC users, scripters and tinkerers who would edit a string containing %s and %d can understand their meaning from context alone, and make those changes without further aid or fitness testing. And if they do make a mistake and cause mIRC to crash, that's how they learn, improve and grow.

Don't name the files .txt but leave them with a blank or .lang extension if you wish to discourage accidental whoopsy-doodles.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I am afraid it has to be a DLL. The idea of writing custom code that low-level creates accelerator, dialog, menu, and string resource templates, that works consistently across different Windows versions, from text files, in other words... my own resource compiler, is just too mind-numbing to even contemplate :-]

Joined: May 2018
Posts: 221
eahm Offline OP
Fjord artisan
OP Offline
Fjord artisan
Joined: May 2018
Posts: 221
Originally Posted By: Khaled
For now, I am going to go back to focusing on other changes for this beta cycle and hopefully release a new version later this month or next.

Awesome! Thank you.

Last edited by eahm; 11/11/18 05:22 PM.
Joined: Sep 2015
Posts: 7
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
Joined: Sep 2015
Posts: 7
I'm not a programmer, but I've been using mIRC for more than 10 years because I really find it the best IRC client for Windows.

Probably not the best solution, but to expose all strings in a file called en_EN.pot via gettext and then upload to Crowdin.com could be an idea?

This lightens the long and hard work of translation, also because, with respect, I don't think you know all the languages ​​of the world. Also, many other people could help out.

In this way, translating the main en_EN.po file with simple software such as notepad ++ or even better with PoEdit or through the crowdin.com site would be a job for everyone. Many users use programs like "Resource Hacker" to translate mIRC, but it is certainly not the best way because they risk compromising the proper functioning of mIRC.


Link Copied to Clipboard