Settings window not localized

[LaurentGrenet]

Even if Start Menu is localized (and localization depends on chosen language in settings. That's OK), settings panel itself is NOT localized and is always in english, whatever the chosen language. It was not the case (and localization of settings panel was OK) in ClassicShell 4.3.1

Version:

• Open-Shell: 4.4.142
• OS: Windows 10 Pro 1909 - 64bits

[LaurentGrenet]

Actually, I've seen that the fr_FR.dll was missing in C:\Program Files\Open-Shell directory. Copying file from ClassicShell 4.3.1, localization of Settings panel is there....

On the other hand, switching to another language do NOT download any new "language" dll, and CheckForUpdate button raises an error. While in ClassicShell 4.3.1, language change propose to download the corresponding dll.

[LaurentGrenet]

Closed by error.

[Ibuprophen]

Just to clarify...

The issue regarding the "updates" feature has been stated (many times) before that this is currently a "broken" feature.

This specific feature was brought over from this software's predecessor (Classic Shell) that looks for updates via a location that is no longer maintained/exists.

~Ibuprophen

[LaurentGrenet]

via a location that is no longer maintained/exists.

I don't know if it is maintained, but it's clear it still exist. With Classic Shell, it is still now feasible to download Dll for most of the languages.

[terr72]

It would really be helpful for many foreign speakers if this could be fixed.

@Ibuprophen: You stated in a different issue that it would require a lot of work to fix the integrated locale updater and the dev team simply doesn't have the time resources for it. But if I understand LaurentGrenet correctly copying the language file from ClassicShell basically fixes the problem. Wouldn't bundling those locales be a much more time effective solution than trying to fix the whole user choice and remote download process?

WinSCP has also a very similar approach. It's English by default and if you want to localize it you need to download a simple ZIP file in your language, extract it into its folder and that's it.

[coddec]

The language download option etc. is great and cool! But for now, I reckon if we bundle all of the language dlls with the setup file/program as a fall back solution, it may help in this situation.

1 They are not huge, thus won't increase the setup binary dramatically. 2 Users can carry the binary and install it and change the language straight way with or without internet doesn't matter. 3 We don't need to spend a lot of time on the language downloading function for now, but there will be almost 0 impact on user experiences (language perspective.) (4) Only issue I can think of is the dll permission/copy right etc. etc. Since users can download them easily without any notice, I presume it should be to be included with the setup binary?

@Ibuprophen @XenHat @ge0rdi What do you guys reckon?

[ge0rdi]

@coddec Looking at translation DLLs, each DLL has cca 150kB and there are 19 of them. That's about 2.5MB. Sounds quite a lot to me :(

I'd rather pack them together and offer as separate package on Releases page. So anyone interested in localized version could download them.

Also it will be great to have sources for them. AFAIK they are not part of source repo, we cannot compile them. Will be great to ask Ivo about sources for those DLLs.

[RegisStGelais]

or offer a package that include them (a multilanguage package) and another that does not.

[RegisStGelais]

And yes, it would be grate to have a repo for them.

[coddec]

@ge0rdi

Rely from Ivo,

Not sure what you mean by “source”. The translation content is in the DLLs. Most of the time I would send the DLL to the translators and they would use a resource editor to update the text and dialogs. Sometimes I would convert it to a CSV file to let them edit it, but ultimately the text ends up in the DLL.

Bottom line, there is no .RC file for them. There never was.

[ge0rdi]

@coddec If we'd like to maintain these localization DLLs, we should have .RC files and be able to compile DLL from them.

It should be possible to decompile existing localization DLLs using Resource Hacker. Then we can create simple VS project for them and establish compilation.

[coddec]

@ge0rdi I've saved them in RC format and RES format (Just in case). :)

RC.zip RES.zip

[coddec]

Just in case, we also have a mirror for http://www.classicshell.net/translations/ at https://coddec.github.io/Classic-Shell/www.classicshell.net/translations/index.html

Which can be used to download original .dll files

[ge0rdi]

@coddec

I've saved them in RC format and RES format (Just in case). :)

Thanks. Though there will be some more work needed on this.

Numeric IDS (that identify dialogs, strings) should be replaced by symbolic names (defined in resource.h).

Also many strings contain escaped characters (e.g. xED) and these should ideally be unescaped, so that those strings are human readable.

Anyways, I think it may be good idea to track this (conversion of binary translation DLLs to source) in Projects. So that it is clear what needs to be done.

Current issue (with missing localizations) can be solved quickly by packing existing DLLs to archive and putting it (along with instructions) to Releases page (or some other appropriate place).

[coddec]

Temporary Translation/Language Solution Added to Release page

Release page https://github.com/Open-Shell/Open-Shell-Menu/commit/4f46134f100737474f47dc4d4a0313000695ba8f

https://github.com/Open-Shell/Open-Shell-Menu

Home page https://github.com/Open-Shell/Open-Shell-Menu/commit/e151c693eff2d795414dd4fbb369b152fc154684

https://open-shell.github.io/Open-Shell-Menu/

[ge0rdi]

... either in the Classic Shell's install folder or in the %ALLUSERSPROFILE%\ClassicShell\Languages folder ...

I guess it should mention Open-Shell instead of Classic Shell.

[coddec]

@ge0rdi You are right, sorry, I just copied it from the page 😂 Should be fixed now

Thanks!