Process Hacker Forums

Im ready to do Lithuanian translation, how do I do it?

KillSwitch is not based on PH anymore.

Hello. How Comodo added in their KillSwitch (which based oh PH) multi-language support? Maybe this solution fit to PH?

Argument: multi-language support attract new (non-english speaking) users of the program and will bring additional donations. How about trying? :)

P.S. I am very want to see PH in Russian, and ready for help to translate. I already have russian PH (with translated resources), but it's too hard to translate again and again, when you release newer builds.

Thanks for the offer, OrdiFacil. I'm not experienced with i18n, so I really don't know how to manage translations in PH.

Hi,
I'm a new Process Hacker user and I'm just happy for having replaced ProcessExplorer on my system. My first words on this forum just have to be as thankful as this app is useful to me, so... Thank you so much! ;)

I'm not a developer so I don't understand everything in this localization related topic :thinking:
Anyway I'm ready to work on the French translation of PH.

[quote="scorpion007"]I don't think loading languages at runtime is a necessary thing to have. (That is, extensible via new DLLs while the app is running).[/quote]
I'm also currently working on the [i]Explorer++[/i] freeware translation right now and the dev made it easy for contributors to translate (I guess it's what scorpion007 means) : the developer shares each language in a [url=http://www.explorerplusplus.com/software/explorer++_multi-lang.zip]separate DLL[/url], and a [url=http://www.explorerplusplus.com/software/explorer++_translate.zip]Translation Pack[/url] containing the corresponding RC files. Their current translation files are outdated as new versions have been released (that's why I'm working on it), but I think it's a good example. I just have to update the existing translation file and to send the translated RC file to the author on the forum. Then he compiles it to DLL before sharing it on its site (or I can translate the DLL directly from any resource editing app).

I don't know if this example would be possible with PH architecture in future releases. When I open your sources files, I can see many *.c files but there's so much important code lines inside that I'm afraid to make mistakes. But what if I translate the right strings in the [i]ProcessHacker.rc[/i] file? Is this the best way to translate PH? Not sure anyway about how easy it will be to update for future versions without separate languages resources...

The only thing I'm sure is that your application would become more popular with a user ability to easily contribute translating Process Hacker in their own language (thanks to the magic of open-source communities :p: ). I also hope that you could make it work a way that wouldn't be too much time consuming for you when you'll add and update translators contributions.

I'm not full of knowledge but at least full of motivation to contribute my best.
Have all a good day. Bye.

[quote="scorpion007"]Can you explain the reasoning for the first point? Isn't the very core of PH tied both conceptually and technically to Win32 at a fundamental level? Why would we want to avoid the use of Win32? It's not like you're going to port PH to Linux?[/quote]

He means avoid the Win32 API, Instead only use something like the RTL or Native API ;)

PH is tied to the native API since Win32 is badly designed and bad for performance.

Can you explain the reasoning for the first point? Isn't the very core of PH tied both conceptually and technically to Win32 at a fundamental level? Why would we want to avoid the use of Win32? It's not like you're going to port PH to Linux?

If you can build something that

1. Avoids Win32 where possible
2. Is extremely fast
3. Is easy to maintain
4. Doesn't use up additional memory, at least for English mode
5. Allows for separate language pack files

I would include it.

Well, fundamentally for any i18n based design, you'll need to decouple the string's content from its semantics.

So any time you need to display a publicly visible string, you'll need to pull it from your i18n abstraction layer. E.g. something like GetLocalString(IDS_SOMETHING), which should look at the active language and fetch the right string.

After this base is established, this process of obtaining a language independent string needs to be applied to dialogs.

One thing to consider is the fact that dialogs have a locale ID associated with them, so it's possible to have several versions of a dialog for several languages, though that might also be painful from a maintenance POV. Though it's probably the most powerful solution, as strings can vary significantly in length and no longer "fit" correctly in a one-dialog-fits-all approach.

Ideally we probably want some way of having the dialogs be automatically processed on creation to have the right localised strings... That would require some way to identify the static controls and figure out which string ID they correspond to...

Presumably that means we need metadata associated with the static controls. One possibility is using their window-text to tell us the ID we need to look up and replace them with.

Doesn't sound very good for maintenance. Are there any other options?

[quote]Should I support adding languages dynamically (without recompilation)?[/quote]

I would say: you don't have to. I don't think loading languages at runtime is a necessary thing to have. (That is, extensible via new DLLs while the app is running). Instead, the app shipping with several string tables baked into the .exe sounds sufficient to me.

[quote]Even if I used string tables, how would I handle dialog box localization?[/quote]

The way I imagine it working is: You have placeholder static (text) controls in a dialog with a particular ID, then at dialog creation time, before you display it, you apply a "language filter" pass that does a WM_SETTEXT (SetDlgItemText) to the value obtained from LoadString for the current PH-locale (which probably defaults to what the system locale is set to, and can be overridden by the user via a settings dialog).

Is that sane?

[quote="scorpion007"]Question: Does PH use string table resources for UI-strings currently? If not, does that plus LoadString() sound like a reasonable design choice to support several languages?[/quote]

No. Even if I used string tables, how would I handle dialog box localization? Should I support adding languages dynamically (without recompilation)?

Just thought I'd make a thread to discuss the i18n stuff.

Question: Does PH use string table resources for UI-strings currently? If not, does that plus LoadString() sound like a reasonable design choice to support several languages?

AFAIK string tables use full (windows native) utf-16 strings, and you can have several such tables, on a per-language basis, making them seemingly ideal for i18n.