Forums Developers Stable release before adding the languages?

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.