Language support

[nierewa]

Hi,

are there other language files for this great software. German for me. Or can I translate it by myself?

[zigm]

Hi, Appreciate if you can clarify what language files you refer to. Do you refer to User Guide, Help Files or text in windows panes?

[nierewa]

Hi,

I mean the text in windows pane. The menus and so on. In principle the whole program 😄

[zigm]

Hi,

That is what I suspected you meant -:). It is not a small task in general. And the current code was not written to make the task easier. I will take a look what would be involved. There is probably standard way to support different languages in standard UI objects. There is plenty of other error text or information text messages generated by MBox Viewer that would have to be placed in some sort of resource files, etc. I suspect it is not a small task. I will provide an update.

[mvldebian]

I can collaborate with the translation into Brazilian Portuguese and Spanish, I just need guidance on where to get the texts to translate them.

[zigm]

@mvldebian Thanks for the offer, I appreciate. Text translation is obviously important step but translation is only one of the steps that are required to support multiple languages. The first step is to decide on the framework to support multiple languages. Standard Microsoft way is to create separate per language DLL from provided resource data. There are a number of challenges which I didn't fully explore. One is the text support in dialogs. Issue is that the size of text differs depending on the language. One approach is to allocate the extra space for each text in the dialog. The approach is simplest but the result is not great as you would expect. Better approach is to create dialog template per language but requires much greater effort. I have to admit I didn't yet fully explore what is required and all pros and cons.

There are some tools/libraries that translate text in English for example to other language on the demand. The advantage I suppose is that the text can be changed in one place if necessary without changing translation for all other languages. Again, I didn't explore all challenges using such approach. Using transitional standard approach is probably simpler. Standard approach requires that all text is carefully reviewed to avoid any changes in the future that would create inconsistent text across different languages.

I am not ready to commit yet to support multiple languages by the MBox Viewer. It is a big effort. But I can start playing to better understand challenges.

I have a question to you. What language is supported by your desktop. I was wondering whether some of the text is shown already as not ASCII or corrupted? I may need to reconfigure one of my systems to French or German or ? some other Code Page/language.

[mvldebian]

If it is an external file that can be loaded even if the translated texts are missing, we will adjust it even with abbreviated phrases and words so as not to exceed the limits of the screens.

Find a way that is easy for you, the translations community will find a way. The viewer is super complete, it just needs to be friendly to the end user.

Regarding your request, I have not noticed any problems with the application display so far.

[zigm]

PNG looks exactly as on my laptop. Code Page on my desktop is 1252 ANSI Latin1. You can use the following command to find ACP:

REG QUERY "HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage" | findstr /I "CP.*REG_SZ" ACP REG_SZ 1252 - (1252 ANSI Latin1) the ANSI code page used when calling the non-Unicode (ANSI) versions of the Windows API OEMCP REG_SZ 437 - (IBM437 OEM United States) , the OEM code page to make active by default in console windows MACCP REG_SZ 10000

I will provide an update on my progress.

[mvldebian]

C:\Users\Administrador>REG QUERY "HKLM\SYSTEM\CurrentControlSet\Control\Nls\Code Page" | findstr /I "CP.*REG_SZ"

ACP    REG_SZ    1252
OEMCP    REG_SZ    850
MACCP    REG_SZ    10000

[zigm]

Thanks. OEM CP 850 corresponds to ibm850 | Western European

[nierewa]

The viewer is super complete, it just needs to be friendly to the end user.

Thats right :-)

[zigm]

I did spend some time trying to better understand what is required to support multiple languages by MBox Viewer. Recommended solution by Microsoft and experts is to develop a separate per language DLL. I found a few solutions that rely on loading per language text files. Use of the text files has known limitations such as same dialog templates for all languages.

DLL solution assumes that all application resources are defined in so called resource file ( ProgramName.rc file). I attached mboxview.rc file. The resource file defines language, dialogs, menus, all strings, etc  used by  the program. To create a new per language DLL, the baseline .rc file (for example English version) is copied into a new per language .rc file and all text strings need to be translated and other specifications updated. DLL is built using the language specific .rc file. There are some challenges even with the standard DLL approach.

Per language text files solutions typically expect that all resources are defined in the resource file. Strings are retrieved from the resource file and saved in the text file in some format. Language specific text file is later loaded by a program and UI elements (buttons, window titles, etc) are updated on the fly.

Current mboxview.rc file doesn't contain all resources used by MBox Viewer. It is missing all static and dynamically formatted strings passed to MessageBox. Currently there is 231 MessageBox invocations that show errors, warnings, choices, etc. The resource file is  also missing all dynamically created Menus specific to mails, folder, mbox file. When I started contributing to MBox Viewer, I was completely new to the Microsoft environment and MFC desktop UI in particular. At that time I didn't think about support for multiple languages.

Both DLL and text files solutions require large initial effort and long term commitment to support changes. Experts prefer DLL solutions using professional tools to machine translate text and to minimize effort required to manage future changes. Creation of language specific DLL can  be outsourced to clients. Client gets for example an english version of  the resource file and script to build DLL. Client is responsible for translation, build and testing.

I don't think I will commit to implementing a DLL  solution. That would require significant code changes to creation of Menus. Language text files solution is a possibility but I am not sure that imperfect solution would satisfy users. Also, I need to consider the short and term effort required to support the solution. I will keep prototyping parts of the solution to better understand required effort and limitations. In addition to code changes, Help, README and CHANGE_LOG files  would have to be translated to target languages. In the final solution, English would not be fully eliminated.

I am interested in your views on what is important and what tradeoffs are acceptable. I would guess most users understand English but obviously MBox Viewer version using local language is always proffered. mboxview.rc.txt

[zigm]

@mvldebian @nierewa I released v1.0.3.45 of MBox Viewer. The release resolves Print To PDF failure due to changes to the command line arguments to Chrome and Edge. Also, this release implements partial support for multiple languages.

This new feature is covered in the User Guide. In order to select new language you need to select "File-->Development Options-->Select Language" option. You need to restart MBox Viewer after selecting new language in order for the change to take effect. You can select one of the following: spanish, italian, french, portuguese and english.

The english2XXX translation files are located under Language folder. I have created these files using Google Translator web page. I am not sure about the quality of translation. I am sure translation is suspect since no proper context can be provided to Google Translator. I don't speak any of these languages.

At this point I am looking for general feedback about the result. Note that many of non English text instances are truncated. As a work around you can move mouse cursor on top of the text to trigger Tool Tips with the full text. Currently in phase one only the text of dialogs and menus is translated. Non trivial effort was required to accomplish phase one. Most of the code had to be touched. I had to implement number of help functions to minimize changes to the core code.

None of text shown by popup Message Boxes is translated. Much of the text shown by Message Boxes is dynamically created which poses greater challenge for translation.

I released the partial implementation to receive early feedback. At this stage there is no need to update the translation files. That can start after the phase one is completed.