[Discussion] How to change the system of languages ?

[Clo]

If you simply want to change the on-screen language of XnView, please have a look at topic How to configure XnView properly..

___

Hello All !

• Currently, the interface-languages are provided by XnView in two ways :
1. Embedded in the EXE for English, that's the default whether not any DLL exists in the «Language» sub-dir,
2. As DLLs in the aforesaid sub-dir, for all other languages.

• Even if that DLL-system remains beloved by a handful of authors, it's quite out of date, and not handy at all to translate, update, modify. These inconveniences are multiplied by several dozen languages, so I think that another handier / simpler system might be studied and applied, sooner or later { I would much prefer sooner }.

• Hence, from that I experienced with many programs for a long while, I think that text files are the best way to get good localizations.

How to switch to such a system for XnView ?

• In the outlines, I would propose a process like :

1. As a first step, we could have a standalone English DLL; it could be patched / fixed up by some competent English native speakers; currently, there is none English DLL, this puts the English-speaking users at a disadvantage, so they are rightly requesting improvements daily or almost in the forum…
2. Improving the built-in English stuff should allow to place any language strings in the actual embedded dialogues, since they would remain the only when suppressing the DLLs. Each DLL contains all dialogues actually, that increases a lot the global size of the distributed programme.
   
   - That needs to set a more convenient internal font first; currently, Pierre is still using the MS Sans Serif, in which 29 characters are missing, that complicates the translations, especially in French and some other languages. Indeed, an option to choose a font for the dialogues could be a must, like this exists elsewhere…
   
   - I guess that the Polish / French and also German strings are among the longest. So, Pierre et alter could use the longest as a template to fix all rooms for the controls, also with regard to the work of the English-speaking users in the temporary English DLL.
3. English templates might be made for the future language-files translations, it's indispensable, I think.
4. The menus might be moved in (three?) ANSI TXT plain text files; usually, such files have the *.MNU extension.
   - I guess that we need one file per menu-type, I mean for each main view mode : View and Browser, plus the local menus (right-click contextual menus).
   - If needed, a fourth one for some small menus here and there which are not in the previous main categories. I think to a real “Favourite...” menu, for instance...
   - English menu-templates must be made for the translators, of course.
5. All other strings might be moved in a *.LNG file, also built as an ANSI TXT file.
   - Indeed, some languages request UNICODE or UTF8, but it is not a big deal to support both formats when needed.
   - Of course, each string must have an ID-number in decimal ! This is the simplest and best way to get handy files, easy to create and to update. For this too, an English template is needed for the translators. For example :

   Code: Select all

   0=""
   1="OK"
   2="Cancel"
   3="Help"
   4="......"
   

6. Finally, in addition, a file containing the whole internal commands for the menus (and for future additional buttons) might be provided as plain text, i.e. «xnview.inc» like :

   Code: Select all

   Command-name#1=1; short description...
   Command-name#2=2; ditto...
   Command-name#3=3; ditto... 
   and so on...

   - Such a file allows to change the menus if needed, or to create customized ones, that is impossible currently
7. Also, all the INI variable entries might be set and described (for short) in another text-file, any name is convenient : «xnv_ini.txt» or so…Some entries could be planned for special cases, when the program doesn't add any appropriate entry. This exists for example in Total Commander, especially for advanced users, but not only…

Well ! Sorry for the lenght, but this is an issue that bothers me for a long while, and I wish mainly a better XnView first, like everybody here !

Kind regards,
Claude
Clo

[marsh]

I hope language 'text' files or English DLL could save some time for Pierre in the future. Perhaps language 'INI' configuration files could be updated without needing to release a new version of the program.

Would the ability to change font and text would make windows fit better at lower resoltions also? I did not know that some languages require more room than others until reading this forum.

[Xyzzy]

OK, here are my 0.02$:

Currenty I extract .rc files from XnView executable, translate them and create .dll. This is a cumbersome process, but it makes it possible to instantly test the translation! I do not use the files Pierre distributes to translators at all.

- Strings to translate should be grouped by dialogs. For all dialogs there should be information on how to display them.
- Contents of menus, list items, column headers, tooltips should be grouped together, with exact indication as to where to find them.
- Only the most frequently used items (like OK or Cancel buttons) do not need to be duplicated for each place they are used.
- The following fact should be considered: one English string can be translated differently, depending on GUI element it names (fe. Print as window title and button name.)
- Option names (I mean Options dialog) should be definitely more descriptive, especially considering the fact, that there is absolutely no help for them, neither in help file nor as tooltips or status bar tips!
- There should be a possiblity to instantly test a translation (f.e. change .lng file and rerun XnView to see changed translation.).

X.

[Clo]

Hello All !
- Thank you for your replies !

marsh

I hope language 'text' files or English DLL could save some time for Pierre in the future…

- Indeed, it's also the goal of such a project, even if it isn't formally expressed in the start posting above…

I did not know that some languages require more room than others until reading this forum.

OMG ! Much more room than for English in the most cases !
- Choosing the font(s) could help certainly for low resolutions, etc. With the programming used by XvView actually, the dialogue-size is auto-adjusted following the stated font for that dialogue. A font change should be more efficient whether that feature could be disabled / locked…

Xyzzy

Currenty I extract .rc files from XnView executable, translate them and create .dll.

In fact, before to translate anything, you get a standalone English DLL ?

Strings to translate should be grouped by dialogs. …

- Like you can see in the language-file of Total Commander, this is very useful. Originally, groups of strings were under commented titles like :

Code: Select all

{Colors}
1552="Lister:"
1553="Text color"
1554="Background color"
1555="Selected text"
1556="Selected background"
.........

I kept this in the French files, though the author has simply put an empty line to separate the sections now in the template…

- Only the most frequently used items (like OK or Cancel buttons) do not need to be duplicated for each place they are used.

- Indeed, that shortens the file !

- Option names (I mean Options dialog) should be definitely more descriptive, especially considering the fact, that there is absolutely no help for them, neither in help file nor as tooltips or status bar tips!

- Right. A long time ago, I proposed a contextual help feature to Pierre, since I have written the very first Help as HTML… *Peanuts*

- There should be a possiblity to instantly test a translation (f.e. change .lng file and rerun XnView to see changed translation.).

- Absolutely ! It's an advantage with text files too ! In T.C., I do this often. Just close / restart the program, and the change is applied …

Kind regard to All,
Claude
Clo

[Xyzzy]

In fact, before to translate anything, you get a standalone English DLL ?

What I really get and use are pure-text .RC (resource) files- but there's no problem with creating English DLL. A matter of running a few commands. BTW, translating .RC files without specialized tools is generally no-go, but the process I use makes it possible to generate my own language DLLs and test translation, which is very impoprtannt considering little space for many strings!

A propos dialogs- info on how to display them is also important!

I think that much longer descriptions (even 2 lines) can be given for options, if needed. There's enough space, and if space is limited, another options page can be added.

X.

[Clo]

Well, I can get *.rc files from a DLL too. This could be useful to prepare future text-files… This needs an editor supporting long lines (no wrapping), so unpleasant to use

- It should be great that you present a complete standalone English DLL, asking for the Pierre's agreement, of course. So, users like "marsh" could perform some tests, using simply a resource editor (easy to use with the needed font…). Such a DLL might be recognized by the program, so Pierre only could define and state what name could work, i.e. ‹xnviewen_st.dll› or something like this…

K R
Claude
Clo

[Icfu]

As a natural born translator Clo knows best what is needed to make translators happy, so I can only support his request.

Sure, I can resource hack DLLs to adjust strings to my needs but editing plain text files is just more comfortable. Using WinMerge for example one can easily see what has changed in new releases.

Regarding the used font:
MS Sans Serif is completely outdated. Even Total Commander has "already" switched to Microsoft Sans Serif and usually it is as conservative as an application can be.

Icfu

[Clo]

icfu

Hi Jeff !

As a natural born translator Clo knows best what is needed to make translators happy…

I turn red ! Maybe some remaining genes from English ancestors who occupied the region here during four centuries… ?
I appreciate especially from a real native bilingual guy
• Thank you for the support!

…Even Total Commander has "already" switched to Microsoft Sans Serif and usually it is as conservative as an application can be.

- And it's only the release default font! Fortunately, it can be changed in the options … that we can't do actually in XnView.
- The wanted charset might be stated too, that could avoid “squeaks” in some special cases.

…but editing plain text files is just more comfortable.

• It's obvious ! Also faster, easier, with less risks to mistake, and using any ordinary text-editor. Many users could be good translators, but useless at complicated tools using… Hence, more languages could be provided.

Friendly,
Claude
Clo
To be continued…

[ouistiti]

Just a look here
Friendly
Paul

[EgoSun]

Also faster, easier, with less risks to mistake, and using any ordinary text-editor. Many users could be good translators, but useless at complicated tools using… Hence, more languages could be provided.

And all this in cost of performance. DLLs are the easiest way for multilingual support. Ask Pierre what does a text parser represent for a programmer.

What do I really miss, is a standalone English DLL, because built-in strings doesn't satisfy me.

[xnview]

Also faster, easier, with less risks to mistake, and using any ordinary text-editor. Many users could be good translators, but useless at complicated tools using… Hence, more languages could be provided.

And all this in cost of performance. DLLs are the easiest way for multilingual support. Ask Pierre what does a text parser represent for a programmer.

What do I really miss, is a standalone English DLL, because built-in strings doesn't satisfy me.

Perhaps my english translation is not so good...

[Clo]

Ego Sun

Hello !

…DLLs are the easiest way for multilingual support. …

- I disagree totally. If you look for how many programs use DLLs and how many others use text-files, there is no finish photo !!!
- For example, Total Commander (60 languages or so…) began the very first versions with DLLs, twelve years ago… for two versions only… !

- You might give a glance in that program, and see how easy it's to correct / change any string / menu entry /create supplemental menus and so on…

- What is faster ? To load a DLL 170 KB, or text-files for the half ? And you have already the whole default English embedded stuff loaded, since it's in the EXE, and useless when using another language…

- You complain that the Russian and Ukrainian translations are bad, rightly certainly. With text files, you could have fixed this by yourself already, and Pierre would have already fixed up these languages…

- Like told above in another posting, good translators are not necessarily programmers, I'm not… Handling source-files is not so easy, and needs appropriate editors…

- Indeed, as a first step, a standalone allowed (official) English DLL is desirable. But it should be only a tool to advance to a better system.

Kind regards,
Claude
Clo

To be continued…

[ouistiti]

I'm neither a translator nor a programmer... just a user who hate typos, misspellings, barbarism and faulty syntax... a .mnu or .lng is not a SMS !!!!

A text file is easy to correct for everyone... but I din't found a spelling and syntax corrector for text into DLL files directly...

Friendly

Paul

[EgoSun]

Perhaps my english translation is not so good...

Menus are mainly OK, but the options dialog...

What is faster? To load a DLL 170 KB, or text-files for the half?

Just ask Pierre. DLL and text file are very different things. DLL stands for Dynamic Linking Library and is always ready for use by application because of its nature. On the contrary, to link (or use) strings from a text file you have to parse it at first and then load the result into memory in another way than DLL. This "another way" uses more processor time than native DLL routines.

And you have already the whole default English embedded stuff loaded, since it's in the EXE, and useless when using another language…

Here you are right. Embeded default skin and langauge-dependent resources (like menus, dialogs and string table) have to be moved outside of the EXE to standalone English DLL.

You complain that the Russian and Ukrainian translations are bad, rightly certainly. With text files, you could have fixed this by yourself already, and Pierre would have already fixed up these languages…

I'm already doing that with resource editor.

Like told above in another posting, good translators are not necessarily programmers, I'm not… Handling source-files is not so easy, and needs appropriate editors…

Sorry, this is translators hard job.

Indeed, as a first step, a standalone allowed (official) English DLL is desirable.

Confirm.



And the last word: DLLs are good but text files are more flexible, since language DLLs contain not only localized strings but menus and dialogs, thus data doubles.

[Xyzzy]

And the last word: DLLs are good but text files are more flexible, since language DLLs contain not only localized strings but menus and dialogs, thus data doubles.

No, they don't. Believe me, I prepare Polish language DLL from ground up (starting from empty DLL with DLL header only). There is nothing more there than strings for dialogs, menus and stringtables only (and IDs for them).

I think we could adopt Total Commander approach both to language support (text ini files) and translation cycle (strings for translation are released once, with detailed info on their location in GUI).

Parsing a file with 'key=value' pairs is trivial and a negligible load.
Also, English strings and basic toolbar should remain embedded (in case they cannot be loaded from disk), but also there should exist possibility to choose 'external' English strings source.